Global Styles: Don't output preset classes for colors defined by the theme

[scruffian]

Description

I think this is a regression introduced in #34334.

Consider a classic theme without a theme.json file, which adds a theme support for editor-color-palette. Because these colors get included in the theme.json via get_from_editor_settings, when we call get_preset_classes , these color classes from the theme origin are being output. So for example if you are using the "Canard" theme, Global Styles outputs some CSS like this:

.has-color-red {
	color: var(--wp--preset--color--red) !important;
}

However the CSS variable isn't defined, but it doesn't get ignored, instead it seems to fall back to the broswer default.

So the root of the problem is that the CSS variables used by get_preset_classes don't match the variables output by get_css_variables. This is because get_css_variables only outputs CSS variables defined on the core origin, whereas get_preset_classes doesn't filter out origins.

This PR adds a filter to get_settings_slugs which is used by get_preset_classes to only output settings that are defined on the passed origins. The alternative approach would be to remove the filter from get_settings_values_by_slug and output the CSS variables for both the theme and core origins. In some ways this is preferable as it lightens the load for themes to opt into Global Styles, but it might create unexpected changes.

How has this been tested?

• Use this PR: Canard: Fix editor block styles Automattic/themes#4797
• Switch to Canard
• Set some colors on your blocks
• Without this PR the colors don't work. With this PR they do

Screenshots

Before:

After:

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[oandregal]

Was trying to understand how this change was different than the existing code, but then I realized I was missing the bigger picture: how get_settings_slugs was being called.

It looks like when we introduced this function from a refactoring we forgot to add the last parameter (see).

[oandregal]

This is what happened as far as I understand: we introduced the origins parameter in 11.5, at #34955 (see get_merged_preset_by_slug method), so they are working fine in 11.5 and 11.6. In #34667 slated to 11.7 we introduced a refactoring that updated the code to use a new function called get_settings_slugs which tried to replicate the later. However, we forgot to actually allow that third-parameter in the function declaration (see).

[oandregal]

I've milestoned this for 11.7 as it fixes a bug we detected during the testing period for a PR introduced in 11.7 as well.