[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