Block Style Variations: Reuse block metadata in WP_Theme_JSON::get_valid_block_style_variations() for better performance

[ramonjd]

What?

Backporting theme json performance optimizations from WordPress/wordpress-develop#7586

Props @mukeshpanchal27

Why?

Reduce unnecessary calls to ::get_blocks_metadata().

How?

Passing already-fetched data from ::get_blocks_metadata() to ::get_valid_block_style_variations(()

Testing Instructions

CI tests should pass. Smoke test a theme with style variations in the site editor.

Here's an example from #57908 that you can add under /styles.

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,
	"title": "Variation A",
	"blockTypes": [ "core/group", "core/columns", "core/media-text" ],
	"styles": {
		"color": {
			"background": "#eed8d3",
			"text": "#201819"
		},
		"elements": {
			"heading": {
				"color": {
					"text": "#201819"
				}
			}
		},
		"blocks": {
			"core/group": {
				"color": {
					"background": "#825f58",
					"text": "#eed8d3"
				},
				"elements": {
					"heading": {
						"color": {
							"text": "#eed8d3"
						}
					}
				}
			}
		}
	}
}

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: [Type] Performance, Backport from WordPress Core, [Feature] Block Style Variations, No Core Sync Required.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: [Type] Performance, Backport from WordPress Core, No Core Sync Required.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[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: ramonjd <[email protected]>
Co-authored-by: mukeshpanchal27 <[email protected]>
Co-authored-by: aaronrobertshaw <[email protected]>

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

[ramonjd]

I'm tentatively backporting this change too.

Core uses ::get_blocks_metadata() to get valid block names. See: https://github.com/mukeshpanchal27/wordpress-develop/blob/trunk/src/wp-includes/class-wp-theme-json.php#L762

It has done it this way since 5.9 😄

Then I found this Gutenberg PR from 2022, which doesn't appear to have been backported:

• Avoid calling get_blocks_metadata in WP_Theme_JSON constructor #44658

Which is correct?

I think maybe we could use what Core has since ::get_valid_block_style_variations() will now call ::get_blocks_metadata() anyway.

cc @ajlende @oandregal @aaronrobertshaw @mukeshpanchal27 for advice.

[aaronrobertshaw]

Thanks for highlighting this. It might have been a factor in why the valid variations function evolved as it did.

I think maybe we could use what Core has since ::get_valid_block_style_variations() will now call ::get_blocks_metadata() anyway.

Agreed. It saves another update in core too.

[oandregal]

mmm, perhaps something that was added in gutenberg but not backported later to core? anyway, this seems a safe change to me given blocks metadata will recalculate the blocks that are registered (if they're different).

[mukeshpanchal27]

Thanks @ramonjd, LGTM.

[aaronrobertshaw]

Thanks for wrangling this one @ramonjd 👍

✅ Code changes match #66539
✅ Block style variation registration works as before
✅ Block styles can be updated via Global Styles
✅ Updated block styles are reflected on the frontend

LGTM 🚢

[ramonjd]

Thanks for the help and reviews, everyone!