CSS encoding issue requires careful handling of user permissions and data serialization.
The issue involves block-level custom CSS breaking when edited by users without unfiltered_html capabilities. Solutions involve either encoding CSS or removing attributes with warnings, but multisite implications complicate the fix. The problem is well-documented but requires careful implementation due to security and compatibility concerns.
https://github.com/WordPress/gutenberg/pull/73959 introduced block level custom CSS.
Everything works as expected unless a user without unfiltered_html edits a page/post with existing block-level custom CSS that includes nested selectors, eg.
color: green;
& p {color: blue}
In these cases, entities like & are encoded and the CSS breaks in the editor and the frontend.
See the discussion on https://github.com/WordPress/wordpress-develop/pull/11104
Core trac ticket: https://core.trac.wordpress.org/ticket/64771
There, @sirreal pointed out that for 7.0 this needs to be fixed in GB by:
data:text/css;base64 ORunfiltered_html tries to edit/save the post - with a warning to them that this is going to happencolor: blue; & .child { color: red; } and styles do not show correctly in editor or frontend.No response
No response
Claim this issue to let others know you're working on it. You'll earn 20 points when you complete it!