[wp-trac] [WordPress Trac] #38609: REST API should honor the `unfiltered_html` capability
WordPress Trac
noreply at wordpress.org
Wed Nov 2 01:38:52 UTC 2016
#38609: REST API should honor the `unfiltered_html` capability
--------------------------+------------------------------
Reporter: jnylen0 | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: REST API | Version: trunk
Severity: normal | Resolution:
Keywords: | Focuses:
--------------------------+------------------------------
Comment (by rmccue):
I'd started on this, but there are ''so many'' kses functions that it
ended up being pretty bloated, so I'd suggest we only implement a subset
of these. The issue is that `wp_kses` takes a `$allowed_html` parameter,
which is usually the context. There are wrappers to set this to `post`
(`wp_kses_post`), the current filter (`wp_kses_data`), and slashing
variants of all of these.
I'd propose we add two more functions:
* `wp_maybe_kses`
* `wp_maybe_kses_post`
Both of this shortcircuit if the user has `unfiltered_html`.
Unfortunately, due to the highly undefined nature of the existing filters,
likely not easy to migrate these over. These filters all use the slashed
variant, and rely on the name of the current filter in `wp_filter_kses`,
which seems insane.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/38609#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list