-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global Styles: Don't remove Custom CSS for users with the correct caps #47062
Conversation
Flaky tests detected in 11b9a75. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3900135614
|
Can anyone confirm if the PHPUnit tests are failing locally as well? They are passing without an issue for me but failing on CI.
|
@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)
... |
Thanks for testing, @ironprogrammer! Do you get a failure when running the entire test suite? P.S. I've destroyed and rebuilt my local |
Reply to @Mamaduka:
No, the entire suite succeeds as well. |
cd7fadd
to
7801eca
Compare
Found the source of the failure. The multisite unit tests fail - I will try to get this resolved tomorrow. Meanwhile, PR is ready for manual testing. |
Resolved the failing tests by explicitly granting capabilities to the administrator users. PR is ready for review. |
phpunit/class-wp-theme-json-test.php
Outdated
// Explicitly grant 'edit_css' capabilities. | ||
$grant_edit_css_cap = function( $caps, $cap ) { | ||
if ( 'edit_css' === $cap ) { | ||
$caps = array( 'edit_theme_options' ); | ||
} | ||
return $caps; | ||
}; | ||
add_filter( 'map_meta_cap', $grant_edit_css_cap, 10, 2 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @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. |
35eb041
to
a2a9aca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
@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? |
Thank you, @glendaviesnz. I think migrating these two together makes sense. |
What?
Related #46815.
PR updates
WP_Theme_JSON::remove_insecure_properties
to skip custom CSS sanitization when a user hasedit_css
capabilities.Why?
When KSES filters are registered, the
remove_insecure_properties
remove the custom CSS values without checking the right capabilities.Testing Instructions
add_action( 'init', 'kses_init_filters' );