-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Update custom CSS handling to be consistent with block global styles. #62357
Conversation
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core GitHub repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/block-editor-settings.php ❔ lib/class-wp-theme-json-gutenberg.php ❔ lib/global-styles-and-settings.php ❔ lib/script-loader.php ❔ phpunit/class-wp-theme-json-test.php |
677acb2
to
453c9e6
Compare
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
@@ -2855,6 +2866,11 @@ static function ( $pseudo_selector ) use ( $selector ) { | |||
$block_rules .= static::to_ruleset( ":root :where($style_variation_selector)", $individual_style_variation_declarations ); | |||
} | |||
|
|||
// 7. Generate and append any custom CSS rules. | |||
if ( isset( $node['css'] ) ) { | |||
$block_rules .= $this->process_blocks_custom_css( $node['css'], $selector ); |
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.
I think this line allows adding custom CSS declarations to the root selector in theme.json
"styles": {
"css": "background-color:purple;"
},
I can see the background color on the frontend but not in the site editor
Whereas in trunk only this works:
"styles": {
"css": "body{background-color:purple;}"
},
Should Gutenberg allow both? Or is it a regression?
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.
Hmm that's a good question. This is how it was before #47396, but given that PR is over a year old it might be best to keep things as they were more recently. I'd expect to have to write complete rules in the top level custom CSS control and not necessarily for loose properties to be attached to the body element.
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.
Oooooh this is interesting; I think we've detected a bug in the existing behaviour. Testing in trunk, the loose properties are output outside any rule, so they don't apply because they're invalid, both in editor and front end:
Whereas in this branch, those properties are nested under the root selector in the front end, though they're still invalid output in the editor. I think ideally we should fix things so they aren't output at all. I'll look into it!
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.
Ok I fixed things so that this branch behaves like trunk (no valid CSS output if only properties are added to the top level custom CSS control) but the loose properties are still being output (just like they are on trunk).
The problem with this is that any rule output straight after a loose property won't work. I can repro this in core trunk, and it's also a problem with the customizer additional CSS (which may not manifest in classic themes because additional CSS is enqueued after everything else, but on hybrid themes we're adding it before global styles custom CSS, so it can also break stuff)
We could maybe just check that there aren't any loose properties at the end of the custom CSS string? Checking the whole string is valid CSS might be overkill as site admins should be responsible for the validity of their CSS. We could also Do Nothing 😄 and leave things as they are.
If we do want to do anything though, it's probably better as a separate PR.
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.
If we do want to do anything though, it's probably better as a separate PR.
For sure. Thanks for looking into it.
We could maybe just check that there aren't any loose properties at the end of the custom CSS string?
Or maybe some light-weight parsing where the styles are added?
gutenberg/lib/class-wp-theme-json-gutenberg.php
Line 1361 in 01a0e42
$stylesheet .= _wp_array_get( $this->theme_json, array( 'styles', 'css' ) ); |
Other than the question above, this PR tests well for me. I tested in site editor and via theme.json 👍🏻 |
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.
Tested again. LGTM
Styles loaded only when the block is present on the page 👍🏻
Otherwise behaves as it does on trunk.
Thanks!
@@ -1421,6 +1428,7 @@ public function get_custom_css() { | |||
* @return string The global styles base custom CSS. | |||
*/ | |||
public function get_base_custom_css() { |
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.
So these never made it to Core, right? Should we remove the @since
annotations and maybe add a "don't backport note"?
Doesn't have to be here, just wondering if it'll help later.
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.
Oh good point, we should remove the @since
on these!
…WordPress#62357) Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org> Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
What?
Addresses several concerns on the PR that added conditional loading of block custom CSS.
wp_should_load_separate_core_block_assets
is true;get_custom_css
function with two different tests.Testing Instructions
wp_should_load_separate_core_block_assets
is true (which it is by default in most block themes);add_filter( 'should_load_separate_core_block_assets', '__return_false', 11 );
to the theme's functions.php and check that custom CSS for all blocks always loads in the front end.Testing Instructions for Keyboard
Screenshots or screencast