Block Supports: Strip custom CSS from blocks for users without edit_css capability

[glendaviesnz]

Adds capability-gated CSS stripping so that when a user without edit_css saves a post, any style.css attributes are surgically removed from block comments using WP_Block_Parser::next_token().

Trac ticket: https://core.trac.wordpress.org/ticket/64771

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props glendaviesnz, ramonopoly, shailu25, westonruter, dmsnell.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[ramonjd]

This is working according to the test steps in WordPress/gutenberg#76650 for me (minus the editor warning of course, which is part of the GB packages). Code matches the GB filters and tests.

I'll rebase for final review.

[ramonjd]

You can also test that author's can't post block CSS to the REST API :

wp.apiRequest( {
	path: '/wp/v2/posts/<YOUR_POST_ID>',
	method: 'POST',
	contentType: 'application/json',
	processData: false,
	data: JSON.stringify( {
		content:
			'<!-- wp:paragraph {"style":{"css":"color:green"}} --><p class="has-custom-css">Welcome to WordPress. This is your first post. Edit or delete it, then start writing!</p><!-- /wp:paragraph -->',
	} ),
} ).done( console.log ).fail( console.error );

[ramonjd]

I added these tests to cover that the filters are added, which I think is the core guarantee of this feature?

[ramonjd]

This is testing well for me. Thanks for the help reviewing, folks.

I believe, to allow merging and merging to 7.0 it needs some further coordination?

https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/

[dmsnell]

This comment shouldn’t be necessary as it doesn’t communicate anything particularly special about the function from the outside. We could not that round-tripping isn’t necessary, but I think the string interface should tell the story good enough.

[dmsnell]

An Examples: section with at least one illustration of how this changes its inputs would be nice. It’s easy enough to communicate that the input is unchanged when permissions are there, but it’s unclear from the summary what would be removed in practice. A block with style.css attributes going in and coming out without them would be idea.

[dmsnell]

this is not necessary with the block processor. it will be marginally faster for posts with no blocks (which should be extremely rare) but it will report false-negatives when the formatting of the block comment is unexpected (we should probably fix that too in has_blocks() some day).

[dmsnell]

it could be really helpful to require this be done before sending the content into the function. I know the story is quite a mess in WordPress with slashes, but if every function calls stripslashes() it can be hard to test with plain data. this is not a hill to die on, of course, but I find that we end up with more confusion by stripping slashes everywhere and then adding them back than we do converting the data at the point at which we load it.

[dmsnell]

I feel like we had a conversation about using this vs. using the WP_Block_Processor, and that we decided against it because we were in Gutenberg, but this is a Core PR, so am I misremembering? or would it be worth using the Block Processor interface to avoid the internal details of the Block Parser?

$processor = new WP_Block_Processor( $content );
while ( $processor->next_block() ) {
	$span = $processor->get_span();
	
	$json_at = strcspn( $content, '{', $span->start, $span->length );
	if ( $span->length === $json_at ) {
		continue;
	}

	$json_length = strrpos( $content, '}', $span->start + $span->length );

	$json = $processor->allocate_and_return_parsed_attributes();
	…
}

[dmsnell]

there is is: WordPress/gutenberg#76650

is this a backport PR then? it’s fine to merge as-is, though since this is Core we can always update it. I’m fine leaving it here if all this is is a copy from the Gutenberg work.

[ramonjd]

Thanks @dmsnell Yes this was the backport.

@glendaviesnz Since this is your PR, do you have time to address the feedback?

[dmsnell]

@ramonjd I am fine shipping this as a backport and updating. I welcome the updates to any feedback, but please know I support getting this through if those updates mean stress or holding back the work.

We can always iterate.

[ramonjd]

Thanks for the confidence check @dmsnell

In my mind, if the updates can be a follow up then, at this stage in the WP 7.0 cycle, it'd be good to get this bug fix in. At least to ensure the stripping precaution is there.

We have a bit of breathing room thanks to the release delay, but it's not been decided how long that'll go on.

[ramonjd]

Suggested change

	*
	* Uses {@see WP_Block_Parser::next_token()} to scan block tokens and surgically
	* replace only the attribute JSON that changed — no parse_blocks() +
	* serialize_blocks() round-trip needed.

[ramonjd]

I appreciate the continued help on this one, folks.

I'll commit this, then reopen the trac ticket for 3rd party backport according to https://make.wordpress.org/core/handbook/best-practices/backporting-commits/#backport-process

[ramonjd]

Committed in r62257 and 88fe6bf