Skip to content
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

Enqueue block custom CSS only when block renders on the page. #58991

Merged
merged 3 commits into from
Feb 28, 2024

Conversation

tellthemachines
Copy link
Contributor

What?

Follow up from WordPress/wordpress-develop#5892.

Global styles per-block custom CSS should respect the wp_should_load_separate_core_block_assets flag and only be enqueued when the block renders on the page if separate assets are enabled.

Ideally this work would be done core-first, but given we're currently in Beta it will have to wait a while, so it's worth trying out here in the meantime.

Testing Instructions

  1. Test with a block theme that adds custom CSS to a few of its blocks, such as TT4, or add custom CSS to blocks in global styles. Also add some base custom CSS (in the global styles sidebar, open the "More" dropdown to show Additional CSS if it's not visible in the UI).
  2. In the front end, load up a page that contains blocks with custom CSS and one that doesn't. Check that custom CSS is loaded only when blocks are on the page (custom CSS styles can be found inside <style id='global-styles-inline-css'>)
  3. Add 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

@tellthemachines tellthemachines added Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json CSS Styling Related to editor and front end styles, CSS-specific issues. labels Feb 14, 2024
@tellthemachines tellthemachines self-assigned this Feb 14, 2024
@tellthemachines tellthemachines added the [Type] Enhancement A suggestion for improvement. label Feb 14, 2024
Copy link

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/class-wp-theme-json-gutenberg.php
❔ lib/global-styles-and-settings.php
❔ lib/script-loader.php

@tellthemachines tellthemachines added the Needs PHP backport Needs PHP backport to Core label Feb 14, 2024
Copy link

github-actions bot commented Feb 14, 2024

Flaky tests detected in 7424bb0.
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/7954307106
📝 Reported issues:

@ramonjd
Copy link
Member

ramonjd commented Feb 14, 2024

This could be me, but I was just firing up this branch in the site editor and noticed that the home template is being rendered as though it were in a page template, i.e., with site title and the root container being a wp-block-post-content

Screenshot 2024-02-14 at 2 53 16 pm

In trunk:

Screenshot 2024-02-14 at 2 53 21 pm

If you can't see that then please ignore me!

Copy link

github-actions bot commented Feb 14, 2024

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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>
Co-authored-by: aristath <aristath@git.wordpress.org>

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

@ramonjd
Copy link
Member

ramonjd commented Feb 14, 2024

This could be me, but I was just firing up this branch in the site editor and noticed that the home template is being rendered as though it were in a page template, i.e., with site title and the root container being a wp-block-post-content

I rebased on trunk and it's stopped. Must've been me. Sorry!

Copy link
Member

@ramonjd ramonjd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just did a drive by test.

This change makes sense to me, and it working pretty well.

I can confirm that custom block CSS is only loaded if that block appears on the page in the frontend.

add_filter( 'should_load_separate_core_block_assets', '__return_false', 11 ); makes it load all the time. 🌮

Not sure if it needs a rebase - I was seeing some strange behaviour in site editor, but my env probably needs nuking.

lib/global-styles-and-settings.php Outdated Show resolved Hide resolved
lib/global-styles-and-settings.php Show resolved Hide resolved
lib/global-styles-and-settings.php Outdated Show resolved Hide resolved
Copy link
Member

@oandregal oandregal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks!

I've tested a few scenarios (how posts with and without quote block behave in a block theme, by default and with the filter disabled) and all work as expected. I'm looking at the code in a bit.

@oandregal
Copy link
Member

oandregal commented Feb 15, 2024

Is it feasible to deprecate gutenberg_enqueue_global_styles_custom_css() and absorb that logic as part of gutenberg_enqueue_global_styles()?

As a consumer, if I use gutenberg_enqueue_global_styles() I'd expect to have all the CSS that is needed – I shouldn't have to use a separate function for the styles.css property. In my opinion, styles.css is just another style property in the theme.json, the same as styles.typography.fontSize or styles.elements.button.border.radius. I don't understand why it needs have its dedicated set of public functions.

This is a bug that has been present in WordPress since the styles.css property landed in theme.json. The fix will land in 6.6, so I think we have plenty of time to make it right and aim to simplify.

@tellthemachines
Copy link
Contributor Author

Is it feasible to deprecate gutenberg_enqueue_global_styles_custom_css() and absorb that logic as part of gutenberg_enqueue_global_styles()?

It should be, yeah! I'm not sure why it wasn't done that way to start with. One thing I noticed is that the customizer CSS is being enqueued as part of gutenberg_enqueue_global_styles_custom_css(), and if we were to make it part of gutenberg_enqueue_global_styles() it wouldn't make sense to do that. Again, I'm not sure why it was done that way, so will try to find out more before changing it around 😅

@tellthemachines
Copy link
Contributor Author

Ok so the reason for the current system is explained in #47396: we're de-enqueuing the customizer additional CSS and adding them before global styles custom CSS so that they don't override global styles in hybrid themes.

The reason for customizer styles being attached to wp-head so late in the game is explained here: it was so that they would override any other theme styles 😅

Hybrid themes are a bit of an edge case, but in order to preserve back compat it would be good to keep the current order of customizer additional CSS followed by global styles custom CSS.

I don't think any of this is a blocker to enqueuing custom CSS as part of gutenberg_enqueue_global_styles, so I'll update this PR to do that.

@tellthemachines
Copy link
Contributor Author

OK I think all feedback has been addressed now! I moved the enqueuing logic into gutenberg_enqueue_global_styles and deprecated gutenberg_enqueue_global_styles_custom_css.

The order of loaded styles should still be the same:

  • base global styles
  • block-specific global styles
  • customizer additional CSS
  • base global styles additional CSS
  • block-specific global styles additional CSS.

Copy link
Member

@aristath aristath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

@tellthemachines tellthemachines merged commit 682fe72 into trunk Feb 28, 2024
59 checks passed
@tellthemachines tellthemachines deleted the update/custom-css-enqueuing branch February 28, 2024 04:29
@github-actions github-actions bot added this to the Gutenberg 17.9 milestone Feb 28, 2024
Copy link
Contributor

@peterwilsoncc peterwilsoncc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tellthemachines Sorry, it's easier to track commits rather than PRs so I only caught this late. Are you able to follow up?

I'm not sure how well the docs-parser copes with the comment format but better to play nice :)

Comment on lines +1335 to +1336


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Double line break


$stylesheet_handle = 'global-styles';

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be /*.

A double asterisk indicates that comments are a docblock to the various parsers for developer.wordpress.org and elsewhere.

@@ -53,6 +53,35 @@ function gutenberg_enqueue_global_styles() {

// Add each block as an inline css.
gutenberg_add_global_styles_for_blocks();

/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above re docblock/comment.

* Before that, dequeue the Customizer's custom CSS
* and add it before the global styles custom CSS.
*/
// Don't enqueue Customizer's custom CSS separately.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be move in to the existing multiline comment

$custom_css = wp_get_custom_css();

if ( ! wp_should_load_separate_core_block_assets() ) {
/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

comment v docblock, as above.

@@ -77,8 +107,6 @@ function gutenberg_enqueue_global_styles_custom_css() {
wp_add_inline_style( 'global-styles', $custom_css );
}
}
remove_action( 'wp_enqueue_scripts', 'wp_enqueue_global_styles_custom_css' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we still need to remove the wp_enqueue_global_styles_custom_css callback?

The plugin supports the latest two WordPress versions, so, assuming this is backported for 6.6, it's only when WordPress 6.7 is released that we can remove this (at that point, the plugin can assume the minimum version is 6.6, where that function is no longer relevant).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oooh good point, it'll still be in core until 6.6 so yeah, I guess it'll need removing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually checking the CSS output on the front end, I'd expect any custom CSS styles to be duplicated with this change (because wp_enqueue_global_styles_custom_css is still being enqueued in core) but they're not 🤔 I wonder why?

@@ -63,6 +92,7 @@ function gutenberg_enqueue_global_styles() {
* @since 6.2.0
*/
function gutenberg_enqueue_global_styles_custom_css() {
_deprecated_function( __FUNCTION__, 'Gutenberg 17.8.0', 'gutenberg_enqueue_global_styles' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I presume we also need to add a @deprecated 6.6 Use wp_enqueue_global_styles instead PHP doc, or something along those lines.

*
* @return string The global base custom CSS.
*/
function gutenberg_get_global_styles_base_custom_css() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we simplify further and remove this function and gutenberg_get_global_styles_custom_css in favor of gutenberg_get_global_stylesheet? The styles.custom property is still the only one that has a dedicated function.

@@ -1284,21 +1284,68 @@ protected function process_blocks_custom_css( $css, $selector ) {
* @return string The global styles custom CSS.
*/
public function get_custom_css() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as below: can we deprecate/remove get_custom_css, get_base_custom_css, and get_block_custom_css_nodes, get_block_custom_css, in favor of the generic functions? IMO, it's too much code for a single style property that should behave like any other (and be part of the general algorithm).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point! It would be better if we didn't need as many functions, but I don't know why it was done this way in the first place. I'll look into it as a follow-up, thanks for reviewing!

@ellatrix
Copy link
Member

ellatrix commented May 1, 2024

@tellthemachines Could you include this change with your backport PR? Added @return after @global in php doc

@tellthemachines
Copy link
Contributor Author

@ellatrix I'm hoping to have time to address André's feedback and refactor these functions before the backport. If I'm unable to do it in time, we could also hold off on adding this to core for now because it's not an essential piece of work, more of a cleanup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json Needs PHP backport Needs PHP backport to Core [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants