Global Styles: Load block CSS conditionally

[scruffian]

What?

This is an alternative to #40513. We should only load the Global Styles CSS for blocks that are used on the page, rather than loading it on every page as we do presently.

Why?

This means sending less data on each page load, so it should improve performance. This is is a pre-cursor to #34180, which will add a lot more CSS to each page load unless we improve the performance.

How?

The basic premise is that if we are loading separate block assets, we move the block specific Global Styles CSS from the global-styles inline CSS block to the inline CSS portion of the block's CSS. The loading of this inline CSS is handled by wp_common_block_scripts_and_styles which enqueues the inline CSS for each block, so this just builds on top of that existing logic.

The changes we need to make are:

1. Don't add block specific CSS to the global styles inline CSS
2. Add add the block specific CSS to the individual block styles inline CSS

This differs from the approach in #40513 by introducing a new filter for get_style_nodes which allows us to filter blocks from the style nodes used to generate the global styles, keeping WP_Theme_Json ignorant of the details of how assets are loaded.

Testing Instructions

1. Switch to TT2
2. Go to a page without a quote block on
3. Check that this CSS isn't in either the global-styles-inline-css or wp-block-quote-css:
   .wp-block-quote {
   border-width: 1px;
   }
4. Go to a page with a quote block on
   Check that this CSS is not in the global-styles-inline-css but is in wp-block-quote-css:
   .wp-block-quote {
   border-width: 1px;
   }

Note

The CSS for the blocks is doubled up - this is because its being enqueued in both core and by Gutenberg. This happens in trunk.

@WordPress/block-themers

[scruffian]

This function is copied from the parent class except this line and the one above.

[draganescu]

Why do we filter out filter_out_block_nodes later and not right here? Since we can override the entire function can't we just change it?

[scruffian]

This isn't new code, it's just extracted to a new function.

[adamziel]

Where is it extracted from? This PR doesn't delete any code.

[scruffian]

It's in the definition of get_style_nodes in the parent class.

[scruffian]

This new function gets styles for the given block.

[scruffian]

Aside from this block, this whole function is copypasta.

[adamziel]

Let's add a comment explaining this code branch.

[draganescu]

If this is merged we won't need this anymore, right?

[scruffian]

we need it in a filter for the case where loading separate assets is disabled.

[draganescu]

So the script loader filters the output of the class that handles "processing of structures that adhere to the theme.json spec". Why not instantiate with a config?

[scruffian]

The want the WP_Theme_Json class to be ignorant of the implementation details of how the CSS is being used - so passing a config which determines whether or not to include blocks goes against that principle.

There's more context here: #40513 (review)

[adamziel]

Let's leave a note in the code here so that it's immediately clear to future readers.

[draganescu]

Took me a while to figure out that the inline style exists at this stage and this only adds to the 'wp-block-' . $block_name handler name :) These block inline styles are added on block_render and this is how we only get the ones that are actually on page, right?

[adamziel]

Let's add a comment to that effect here as it took me a while to figure out as well.

[draganescu]

I think this is good and makes a lot of sense to me. My only confusion is about the necessity for the gutenberg_get_style_nodes filter.

[adamziel]

@scruffian quote/style.css seems to be getting enqueued twice:

(Curl just for brevity, I checked in the actual HTML)

Also, when I set $separate_assets to false as below:

/lib/init.php
add_filter('should_load_separate_core_block_assets', function() { return false; }, 10000);

The only bit of CSS that's getting loaded for the quote block is .wp-block-quote{ border-width: 1px; }. On trunk, it loads all the styles (and appends them to the global styles). The same thing seems to be happening on trunk. Is that expected?

[adamziel]

Both issues I mentioned above are present on trunk and therefore I don't think this PR introduces either of them.

The idea sounds brilliant to me: let's remove the block styles from global CSS and add them to their dedicated inline CSSes that only happen to be rendered when the actual blocks are used. The PR works and I don't see any major issues so I'm approving.

[mcsf]

In unrelated testing in Core, I'm seeing notices coming from here:

Notice: Undefined index: button in /var/www/html/wp-includes/class-wp-theme-json.php on line 1482

@scruffian: can someone follow up here to not assume $element exists on the table? Otherwise this will happen whenever someone is using a recent theme with a less recent Core installation, for example.

[ramonjd]

I've run into similar things a few times (here and here).

In Core, with Gutenberg activated, this line calls get_block_editor_settings() which calls wp_get_global_stylesheet(), and the subsequent chain of methods.

<b>Notice</b>:  Undefined index: button in <b>/var/www/src/wp-includes/class-wp-theme-json.php</b> on line <b>1489</b><br />
#0  WP_Theme_JSON::get_style_nodes() called at [/var/www/src/wp-includes/class-wp-theme-json.php:712]
#1  WP_Theme_JSON->get_stylesheet() called at [/var/www/src/wp-includes/global-styles-and-settings.php:140]
#2  wp_get_global_stylesheet()) called at [/var/www/src/wp-includes/block-editor.php:404]
#3  get_block_editor_settings() called at [/var/www/src/wp-admin/post.php:187]

So it looks like it's running the Core methods/classes which may not have the latest checks ?

I've added a check in Gutenberg:

• Elements: check value and whitelist before building style nodes #43622

I tried to find an "in-plugin" work around and discovered the following:

Removing the call to WP_Theme_JSON_Resolver_Gutenberg::get_merged_data() in gutenberg_register_webfonts_from_theme_json removes the error. I don't know why 🤷

The WP_Theme_JSON constructor is called twice where static:ELEMENTS refers to the Core const, that is, without the new elements button et. al., from the WP_Theme_JSON_Gutenberg class.

This is why we see the error where theme.json contains unsupported elements.

If, in the constructor, we referred to self::ELEMENTS we'd avoid this error, but it'd also mean we'd have to overwrite the constructor every time ELEMENTS was updated.

[draganescu]

If, in the constructor, we referred to self::ELEMENTS we'd avoid this error, but it'd also mean we'd have to overwrite the constructor every time ELEMENTS was updated.

This looks like the way to go. Some copy pasta is a small price to pay for better consistency of how things work!

Also @ramonjd does #43622 solve @mcsf 's potential issue with recent themes/older core - starting WP 6.1?