#42608 closed defect (bug) (fixed)
Allow basic inline HTML tags and attributes in sidebar description on "Widgets" page
Reported by: | flixos90 | Owned by: | flixos90 |
---|---|---|---|
Milestone: | 4.9.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Widgets | Keywords: | has-patch fixed-major |
Focuses: | Cc: |
Description (last modified by )
When registering a sidebar, it can sometimes be useful to use simple HTML in the description for it, like a link or emphasized text. For example, I wanted to add a message like the following:
__( 'In order for this sidebar to be active, you need to enable it first. You can do so <a href="...">in the Customizer</a>.', 'my-theme' )
(the link would point to the respective area in the Customizer)
However, all HTML in sidebar descriptions is currently escaped on the Widgets page in the admin, which makes this impossible (generally, anytime when using the wp_sidebar_description()
function). Using basic inline tags and attributes should be allowed. Strangely enough it is supported in the Customizer already, where this content is not escaped. So it should be similar on the admin page.
Instead of simply removing the esc_html()
call in wp_sidebar_description()
, I think a more secure way would be to replace it with wp_kses_data()
to still make sure only those valid tags and attributes pass.
Attachments (2)
Change History (15)
#5
@
7 years ago
Could we also extend this to descriptions in wp_widget_description() too? https://core.trac.wordpress.org/browser/tags/4.9/src/wp-includes/widgets.php#L401
I'd like to link to a screenshot highlighting where a a particular widget section is shown on the front end.
#6
@
7 years ago
...wait, I misread this and the original patch already does what I need. Ignore me 😁
Any chance we can push this to a 4.9 release rather than waiting for 5.0?
#7
@
7 years ago
- Milestone changed from 5.0 to 4.9.7
42608.2.diff uses a more appropriate wp_kses()
call using sidebar_description
as context which will internally ensure that tags from the global $allowedtags
are allowed in this case.
@philclothier
Any chance we can push this to a 4.9 release rather than waiting for 5.0?
I agree that makes sense.
Yeah, this makes sense to me.