Global Styles: Don't remove Custom CSS for users with the correct caps

[Mamaduka]

What?

Related #46815.

PR updates WP_Theme_JSON::remove_insecure_properties to skip custom CSS sanitization when a user has edit_css capabilities.

Why?

When KSES filters are registered, the remove_insecure_properties remove the custom CSS values without checking the right capabilities.

Testing Instructions

1. Enable the KSES filters with add_action( 'init', 'kses_init_filters' );
2. Enable Custom CSS via Gutenberg > Experiments
3. Go to Appearance > Editor
4. Open the Styles sidebar
5. Select "Custom CSS"
6. Add some CSS code
7. Confirm CSS code is saved

[github-actions]

Flaky tests detected in 11b9a75.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3900135614
📝 Reported issues:

• [Flaky Test] should move the blocks up #39782 in specs/editor/various/block-editor-keyboard-shortcuts.test.js

[Mamaduka]

Can anyone confirm if the PHPUnit tests are failing locally as well?

They are passing without an issue for me but failing on CI.

npm run test:unit:php

[ironprogrammer]

@Mamaduka, the singled-out test from CI succeeds locally in my environment as well. The following was performed with a fresh set of Docker images:

$ npm run test:unit:php -- --testdox --filter test_allows_custom_css_for_users_with_caps
...
Runtime:       PHP 8.0.27
Configuration: /var/www/html/wp-content/plugins/gutenberg/phpunit.xml.dist

WP_Theme_JSON_Gutenberg_
 ✔ Allows custom css for users with caps  30 ms

Time: 00:00.064, Memory: 46.50 MB

OK (1 test, 3 assertions)
...

[Mamaduka]

Thanks for testing, @ironprogrammer!

Do you get a failure when running the entire test suite?

P.S. I've destroyed and rebuilt my local wp-env a few times but couldn't reproduce the CI failure.

[ironprogrammer]

Reply to @Mamaduka:

Do you get a failure when running the entire test suite?

No, the entire suite succeeds as well.

[Mamaduka]

Found the source of the failure. The multisite unit tests fail - npm run test:unit:php:multisite. This is because the administrator roles on MS don't have unfiltered_html or edit_css roles.

I will try to get this resolved tomorrow. Meanwhile, PR is ready for manual testing.

[Mamaduka]

Resolved the failing tests by explicitly granting capabilities to the administrator users. PR is ready for review.

[hellofromtonya]

Instead of this, in the set_up_before_class() fixture, you can add this code which grants this specific admin Super Admin access.

if ( is_multisite() ) {
	grant_super_admin( self::$administrator_id );
}

Let me push an update to see if it resolves the issue.

[hellofromtonya]

Done in 35eb041 and f05482f. PHPUnit tests are passing ✅

[Mamaduka]

Thank you, @hellofromtonya 🙇

[hellofromtonya]

Hey @Mamaduka, I'm sorry for my delay in helping with the failing PHPUnit tests. Pushed commits that removed your changes in favor of granting the defined admin Super Admin access. This approach is consistent with other Core tests.

[mmtr]

Thanks! This tests well for me, and it matches the behavior provided by the Additional CSS feature in the classic Customizer (where the custom CSS is always saved even if it's invalid, as long as the user has the edit_css capability).

[glendaviesnz]

@Mamaduka do you want me to port these changes as part of the main custom-css port, or do you want to handle it separately?

[Mamaduka]

Thank you, @glendaviesnz. I think migrating these two together makes sense.