#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
Reporter: glendaviesnz | Owner: (none)
Type: defect (bug) | Status: new
Priority: high | Milestone: 7.0
Component: Editor | Version: trunk
Severity: critical | Resolution:
Keywords: has-patch has-unit-tests 2nd-opinion | Focuses:
--------------------------------------------------+---------------------
Comment (by peterwilsoncc):
Replying to [comment:51 apeatling]:
> Will `edit_css` be a standalone capability, or does it resolve to
`unfiltered_html` via `map_meta_cap`? This materially affects whether
trusted tools and AI agents can operate on hardened hosts without
implementing questionable workarounds.
>
> **Edit**: I looked it up and it is not a standalone cap. This means all
hosts that disable unfiltered_html are going to break either way. What
about making it standalone so it's not painted with the same broad brush
as HTML filtering?
It's a bit of both...
In a default WP install they map to one another.
They can be made to be independent via the `map_meta_cap` filter, for
example this can be used to remove `unfiltered_html` without affecting the
`edit_css` cap.
{{{#!php
<?php
add_filter( 'map_meta_cap', function ( $caps, $cap ) {
if ( 'unfiltered_html' === $cap ) {
$caps[] = 'do_not_allow';
}
return $caps;
}, 10, 2 );
}}}
--
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:52>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform