#35898 closed defect (bug) (fixed)
Customizer eats backslashes when sanitizing (including updates for nav menus and some widgets)
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 2.7 |
Component: | Customize | Keywords: | has-patch commit |
Focuses: | Cc: |
Description
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.
Attachments (1)
Change History (7)
#1
@
7 years ago
- Keywords has-patch added
- Owner set to westonruter
- Status changed from new to accepted
#2
@
7 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...
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