Section Styles: Switch away from using init for variation registration

[aaronrobertshaw]

What?

Switches away from using init action to register block style variations.

This PR is a backport to Gutenberg of changes proposed in WordPress/wordpress-develop#6844.

Why?

The init hook has proven problematic, because it's also fired during installation, see slack conversation

How?

The main advantage of this approach is that the block style variations are registered when the data is read, so we don't have to do any extra data reads or any more theme.json processing than we already do:

• theme & custom origins: WordPress/wordpress-develop@5d18c8c
• theme.json partials: WordPress/wordpress-develop@762b802

The disadvantage is that these block style variations are not registered everywhere, so we have to do that in the specific places that are not yet covered:

• In the global styles endpoint: WordPress/wordpress-develop@3ea8e91

Context

Initially, this feature worked by registering the block style variations using the wp_theme_json_data_* filters, see https://core.trac.wordpress.org/changeset/58264. This approach proved problematic for this flow: the user updates the styles of any of them via the global styles sidebar.

This feature was updated to use the init hook at https://core.trac.wordpress.org/changeset/58394 The rationale was that this hook is what themes currently do to register the block styles variations via the functions.php (example from TwentyTwentyFour). This approach raised issues: the init hook is called during installation, hence the database is not set up — which this feature requires, as it retrieves the existing global styles for user data.

The approach in this PR is similar to how it initially worked, but with a couple of tweaks:

• It doesn't use the wp_theme_json_data_* filters. Instead, this registers the variations directly in the WP_Theme_JSON_Resolver, saving the extra processing required by the filters.
• It also registers the block style variations in the global styles endpoint, so user updates are reflected immediately in the UI without requiring a page reload.

Testing Instructions

Test

1. Register style variations in all the places the theme is allowed to (use TwentyTwentyFour, aka TT4).

In the theme.json file of the theme, paste the following under styles.blocks.variations:

"theme": {
   "title": "Theme",
    "blockTypes": [ "core/group" ],
    "color": {
            "background": "crimson"
    }
}

In the styles/ember.json (theme style variation) file, paste the following under styles.blocks.variations:

"theme": {
   "title": "Theme",
    "blockTypes": [ "core/group" ],
    "color": {
            "background": "darkseagreen"
    }
}

Create a new file called styles/partial.json (partial theme.json), and paste the following:

{
        "$schema": "https://schemas.wp.org/trunk/theme.json",
        "version": 2,
        "title": "Partial",
        "blockTypes": [ "core/group" ],
        "styles": {
                "color": {
                        "background": "deepskyblue"
                }
        }
}

2. Go to the post editor, add two group blocks. Verify the "Theme" and "Partial" variations are present:

3. Apply them to each of the blocks and verify colors are reflected properly everywhere (editor & front):

4. Go to the site editor and apply the "Ember" style variation. The expected result is that the block with the "Theme" block variation has now the "darkseagreen" background color:

5. Verify that user changes to the block style variations defined are reflected immediately in the site editor:

Gravacao.do.ecra.2024-06-17.as.18.12.25.mov

[github-actions]

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: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>

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

[andrewserong]

This is testing nicely for me, and like I mentioned on the core PR, I think it makes good sense to move this logic to be a side effect of resolving the data.

✅ Theme and Partials are working nicely in the post editor and site frontend
✅ Style variation applies correctly in the site editor and saves and is output by user global styles correctly

LGTM! 🚀

[ellatrix]

Good to merge? I'm cherry-picking for Beta 3 in a bit.

[aaronrobertshaw]

Good to merge? I'm cherry-picking for Beta 3 in a bit.

✅ Done.

Thanks Ella. Just confirmed the core PR should be committed shortly as well.

[ellatrix]

Oh sorry, this is only PHP backports right?