Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#35898 closed defect (bug) (fixed)

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

Reported by: westonruter's profile westonruter Owned by: westonruter's profile westonruter
Milestone: 4.5 Priority: normal
Severity: normal Version: 2.7
Component: Customize Keywords: has-patch commit
Focuses: Cc:


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:

$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:

$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.

Attachments (1)

35898.0.diff (17.1 KB) - added by westonruter 8 years ago.

Download all attachments as: .zip

Change History (7)

8 years ago

#1 @westonruter
8 years ago

  • Keywords has-patch added
  • Owner set to westonruter
  • Status changed from new to accepted

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

#2 @azaozz
8 years ago

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...

#3 @westonruter
8 years ago

  • Keywords commit added

@azaozz thanks for confirmation.

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

#4 @westonruter
8 years ago

  • Version set to 2.7

#5 @westonruter
8 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#6 @westonruter
8 years ago

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.

Note: See TracTickets for help on using tickets.