Add blocks to the list of valid origins for theme.json

[oandregal]

What?

This PR updates the name of the blocks origin from core to blocks and adds it to the list of valid origins for theme.json.

Why?

• We were missing this new origin from the list.
• The core name is not reflective of what it does (see existing comment), as this data origin is related to block styles, whether they come with WordPress/Gutenberg or third-party blocks.
• The existing filter for this piece of data is called theme_json_blocks, to reflect it filters "block" data.
• We used core in the past for default, and reverted because it was confusing and want to use names that communicate what part of the pipeline are processing (default > blocks > theme > custom).

How?

• Rename the string, from core to blocks.
• Add blocks to the list of valid origins.
• Verify that the $theme_json->get_stylesheet call uses the proper $origins at all times.

Testing

Classic theme

Using a theme without theme.json (for example, Canape):

• Verify that the styles for the pullquote and navigation blocks are still present in the global-styles-inline-css. These blocks are the only ones that use the __experimentalStyle API in its block.json. It should look like this:

.wp-block-pullquote{font-size: 1.5em;line-height: 1.6;}
.wp-block-navigation a:where(:not(.wp-element-button)){color: inherit;}

Block theme

Using a theme with theme.json (for example, TwentyTwentyTwo).

Test that the styles are enqueued when the blocks are in use:

• Create a page that uses the pullquote and navigation blocks and publish.
• Go to the front and
  • verify that the styles for the pullquote and navigation blocks are not part of the global-styles-inline-css.
  • verify that there's a wp-block-pullquote-inline-css stylesheet and contains .wp-block-pullquote{border-width: 1px 0;font-size: 1.5em;line-height: 1.6;}.
    • Note that the stylesheet contains a lot more CSS than expected and the rule generated by the __experimentalStyle API also content border-width, which is also unexpected. This is an issue in trunk that needs to be investigated separately. If you want to go the extra mile and verify that this works as expected, edit the values found in __experimentalStyle of the block.json of pullquote, recompile and reload the front. The values should be the ones you set.
  • verify that there's a wp-block-navigation-inline-css embedded stylesheet whose content is .wp-block-navigation a:where(:not(.wp-element-button)){color: inherit;}.

Test that the styles are not enqueued when the blocks are not in use:

• Create a page that does not use the pullquote and navigation blocks and publish.
• Go to the front and verify that the styles for the pullquote and navigation blocks are not part of the global-styles-inline-css and aren't loaded separately either.

Test that themes can opt-out from loading blocks separately even if the post uses the blocks:

• Add add_filter( 'should_load_separate_core_block_assets', '__return_false' ); to the functions.php of the theme.
• Go to the front (any post/page) and verify that styles for all blocks are part of the global-styles-inline-css stylesheet.

[oandregal]

blocks was missing

[oandregal]

Changing this name here does not have any effect because it was not being used anywhere. It has started to be used when it was added to the VALID_ORIGINS list.

[oandregal]

By using an unregistered origin this is what was happening:

• The WP_Theme_JSON_Resolver loaded the blocks origin (named core).
• In the WP_Theme_JSON constructor, because it was not one of the origins registered it'll be changed to theme.
• The WP_Theme_JSON_Resolved loaded then the theme origin, updating any instance.

This was working as expected. But only by coincidence. If the blocks origin was able to define presets this won't work. The reason is it'll work this way:

• the presets of the blocks origin would be stored in the theme key
• when the actual theme origin was loaded, its presets would be also loaded in the theme key, hence, overriding the previous blocks' presets that should have been stored elsewhere.

Essentially, this is the sort of tricky dormant bug waiting to happen.

[scruffian]

I tested in a classic and block themes, and also applied the filter and everything works as expected. Thanks for handling this.

[jorgefilipecosta]

Given that the styles are output in other parts of code, isn't there the risk that priority 'default', 'block, 'theme', and 'custom' is not respected? How do we ensure this order?

[oandregal]

I've looked for every usage of this function (including core) and all instances have been updated.

[oandregal]

Let me expand this.

The $origins only affect presets, they do not affect the styles in the styles key. Because the blocks origin cannot declare any preset, not providing the origins (hence using all of them, including blocks) would not matter in practice. Though I still think it is good practice to be explicit. Maybe, in the future, blocks can declare presets by themselves.

Note that a filter gutenberg_theme_json_get_style_nodes was introduced to remove the styles entirely from the global styles stylesheet and process them separately.

[jorgefilipecosta]

The change look good, but I left a question of do ensure the expected styles order of default, blocks, theme, and user.

[oandregal]

I've found an issue that I'd like to investigate before merging this.

[oandregal]

Done. This is ready to land, was investigating this and this.

[oandregal]

I'm backporting this in WordPress/wordpress-develop#3313

Not sure how this needs to be dealt with in Gutenberg land at this point (we've already released 14.1, the last Gutenberg version to be bundled with WordPress?). Happy to help if someone provides direction. cc @ockham @michalczaplinski

[ockham]

I'm backporting this in WordPress/wordpress-develop#3313

Thank you @oandregal!

Not sure how this needs to be dealt with in Gutenberg land at this point (we've already released 14.1, the last Gutenberg version to be bundled with WordPress?). Happy to help if someone provides direction. cc @ockham @michalczaplinski

So if it's a bug, we can still merge the fix. As for the GB PR, adding the "Backport to WP Beta/RC" label is enough; this brings it on our radar when we triage (planned for Monday) and cherry-pick fixes for a new round of npm releases prior to the next Beta (Tuesday).

As for the backport PR, we'll need to get that approved and find a Core committer to commit it -- ideally also before Tuesday 😊

Edit: I just noticed that this PR doesn't touch any JS at all -- it's all PHP code in lib/compat/wordpress-6.1/ and lib/experimental/. In this case, the npm publishing is of course irrelevant, and WordPress/wordpress-develop#3313 is all that matters for Core 😄

[ockham]

We've removed the "Backport to WP Beta/RC" label since it's not needed technically -- cherry-picking this PR to the wp/6.1 branch and publishing npms from there won't include those files. Instead, they're covered by WordPress/wordpress-develop#3313.