Opened 17 years ago
Closed 17 years ago
#10563 closed defect (bug) (fixed)
Text widget adds extra slashes when edited by someone without the unfiltered_html capability
| Reported by: | jamescollins | Owned by: | azaozz |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.9 |
| Component: | Widgets | Version: | 2.8 |
| Severity: | normal | Keywords: | has-patch |
| Cc: | Focuses: |
Description
(This bug was originally identified in WordPress Mu)
In [10802], the stripslashes() call was removed from the text widget:
$text = stripslashes(wp_filter_post_kses( $widget_text['text'] ));
changed to:
$instance['text'] = wp_filter_post_kses( $new_instance['text'] );
This bug will only affect users without the unfiltered_html capability.
In WP, admins and editors have this capability by default, so this bug hasn't been noticed.
In WPMU, users don't have the unfiltered_html capability (except site admins) so this causes extra slashes to be added when editing a text widget.
Donncha has just checked in a change in WPMU, and I think this change should be applied to WP as well.
You can see here that the wp_filter_post_kses() function adds slashes. So logically whenever this function is used, stripslashes() needs to be used as well.
If you remove the unfiltered_html capability from the administrator user role (using role manager or similar), you will see that when editing a text widget, the extra slashes are added.
Attachments (1)
Change History (9)
#2
@
17 years ago
Yes, this is WPMU specific since in WP only administrators can configure widgets and they have 'unfiltered_html' cap. so kses is never run there.
#4
follow-up:
↓ 6
@
17 years ago
- Resolution fixed
- Status closed → reopened
The patch that got applied seems wrong. wp_filter_post_kses() expects slashed data, and we're feeding it unslashed data.
#5
@
17 years ago
As this affects mostly WPMU, perhaps add comment on the ticket there (referenced above).
#6
in reply to: ↑ 4
;
follow-up:
↓ 7
@
17 years ago
Replying to Denis-de-Bernardy:
The patch that got applied seems wrong. wp_filter_post_kses() expects slashed data, and we're feeding it unslashed data.
The logic for my patch was taken from [10802]. If you look this changeset, line 403 (in r10801) was effectively replaced with line 354 (in r10802).
According to http://core.trac.wordpress.org/browser/trunk/wp-includes/kses.php#L1064, the wp_filter_post_kses() function strips slashes, KSES filters, then adds the slashes again.
The change in WPMU has been running on our WPMU installs for a few weeks and it seems to have fixed the problem.
#7
in reply to: ↑ 6
@
17 years ago
Replying to jamescollins:
The change in WPMU has been running on our WPMU installs for a few weeks and it seems to have fixed the problem.
try feeding it stuff with a backslash... the correct patch is to:
stripslashes(wp_filter_post_kses(addslashes(...)))
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Patch against trunk r11784