Customizer eats backslashes when sanitizing (including updates for nav menus and some widgets)

[westonruter]

This is a follow up to #35869.

I found that the Customizer will drop backslashes from several locations where they are entered, including:

• Site Title (try saving a title with “\o/”)
• Site Description
• Nav Menu Name
• Custom Menu widget title (also on widgets admin page)
• Tag Cloud widget title (also happens on widgets admin
• Text widget body if can't unfiltered_html (also happens on widgets admin page)

The first two settings use WP_Customize_Setting::sanitize() which includes as its first line of code:

<?php
$value = wp_unslash( $value );

This, however, is unnecessary because the value being passed in originates from the incoming $_POST['customized'] JSON blob which is unslashed as a whole:

<?php
$this->_post_values = json_decode( wp_unslash( $_POST['customized'] ), true );

So this is why any intentional slashes are getting stripped.

For nav menus, the problem is that wp_update_nav_menu_object() and wp_create_nav_menu() expect pre-slashed input, and the WP_Customize_Nav_Menu_Setting was not ensuring this.

For the widgets, a few are calling stripslashes() unexpectedly, resulting in backslashes being dropped both in the Customizer and on the widgets admin page.

[westonruter]

35898.0.diff​ fixes the issues.

@azaozz can you speak to the stripslashes() used in some widgets, and if they are just some vestiges that should indeed be removed?

Note that nav menus and nav menu items also get their backslashes dropped on the nav menus admin page, but this due to a recent regression introduced. See https://core.trac.wordpress.org/ticket/14134#comment:203

[azaozz]

The slash/unslash strikes again... Everything that is in $_POST and $_GET gets slashes. As far as I know that has been there since the b2 fork, ~13 years ago.

Because of this every function that deals with $_POST and $_GET directly has to run wp_unslash(). The only way to call such functions from other parts is to use wp_slash() as you're doing in the patch.

As each widget is saved individually from the Widgets screen, it seems the few stripslashes() calls are indeed left over from before 2.7 when that screen was redesigned. It's strange that hasn't been noticed and fixed for so many years...

[westonruter]

@azaozz thanks for confirmation.

I'll commit this later today unless any other feedback comes in to the contrary.

[westonruter]

In 36622:

Customize: Prevent dropping backslashes from input on general settings and settings for nav menus and some widgets.

Ensures that intentional backslashes (e.g. "\o/") can be used in:

• Site title
• Site description
• Nav menu name
• Custom Menu widget title
• Tag Cloud widget title
• Text widget body if can't unfiltered_html

The latter three are also fixed on the widgets admin page.

Fixes #35898.

[westonruter]

In 36645:

Docs: Use markdown instead of HTML for code formatting.

Fixes phpdoc usage in [36622], [36608], [35724], [35307].

See #35898.
See #35869.
See #34738.
See #33552.