Global Styles: Do not sanitize block style variations based on registration status

[aaronrobertshaw]

Fixes: #62303

What?

Only sanitize the properties of block style variations within theme.json instead of also omitting any that are not currently registered.

Why?

With the introduction of the Section Styles feature that leverages extended block style variations, there are a number of methods through which block style variations can be registered. This primarily happens via the theme.json data filters in the WP_Theme_JSON_Resolver class.

Unfortunately, there are several places where global styles data is processed (such as the global styles REST API endpoint) that do not apply these filters and instantiate the WP_Theme_JSON class directly. The result then is some block style variations are not registered and are incorrectly stripped during the sanitization of the theme.json data.

How?

This PR:

• Removes the sanitization of unregistered block style variations
• Maintains the sanitization of style properties within all block style variations
• Prevents any unregistered block style variations from being included in a block types node data during style generation
  • This avoids issues where a variation does not have a defined selector and invalid CSS is generated

Testing Instructions

There are some duotone support actions in Gutenberg that trigger all the theme json filters. So to test this fix fully, those actions need to be temporarily disabled.

1. Comment out the duotone support actions that masked this issue
2. Add a custom block style variation to your theme.json (see Section styles: editing a block variation in Styles doesn't reflect in the editor #62303 for snippet)
3. Navigate to Appearance > Editor
4. Select a group block and apply the custom variation
5. Navigate to Styles > Blocks > Group > dark (variation name)
6. Change the background color for the variation and confirm it is reflected in the editor
7. Save the changes and confirm the background color is still correct in the editor
8. For good measure check the frontend
9. Uncomment the duotone support actions from step 1 and repeat the process. It should still work.

Screenshots or screencast

Before	After
Screen.Recording.2024-06-05.at.6.49.43.PM.mp4	Screen.Recording.2024-06-05.at.6.50.31.PM.mp4

[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: oandregal <oandregal@git.wordpress.org>
Co-authored-by: annezazu <annezazu@git.wordpress.org>

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

[github-actions]

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
❔ phpunit/class-wp-theme-json-test.php

[aaronrobertshaw]

It turned out the deregistration of the test block before generating the stylesheet was causing this test to fail on this branch. Not 100% sure why yet but I'll look into that on Monday.

[oandregal]

Hi Aaron, after your braindump (thank you!) I took a look at this issue and realized there is an alternative way to fix it: we can register the block style variations defined by the theme on init instead of using wp_theme_json_data_* filters.

The init hook is what themes had to use until now in their functions.php. Unless I'm missing some use case, this is a safe place to register the block style variations as we can always count on them being registered. I think it's best if we do that rather than trying to patch specific paths, sanitization, etc. It's also simpler to reason about.

The proposal is at WordPress/wordpress-develop#6756 I had some issues in my environment and ended up preparing it for core.

[oandregal]

So, what this PR does is:

• do not remove the unregistered variations when we build the theme.json in memory
• but make sure we only process the registered ones when we use them

This is the kind of thing that I mentioned: we are not removing sanitization but moving it everywhere. Each time we have to work with them, we need to make sure to use the ones that are registered.

[aaronrobertshaw]

Closing this PR in favour of moving the block style registration to init as detailed above.