CSS color variables are generated even if the defaults are disabled in theme.json

[webexpr-dhenriet]

Description

Would it be possible to clarify the solution to use only what is needed and not load/write

• color
• gradients
• duotone
• CSS variables (:root)

This was mentioned here #43385, #40183, #56180

I think it's not very clear today, in the theme.json, for example, set settings.color.defaultPalette to false doesn't prevent the generation of css variables and CSS .has-** helpers, just like "settings.color.defaultGradients": false or "settings.color.defaultDuotone" : false.
Currently, the only solution I've found is this one

add_filter('wp_theme_json_data_default', function ($theme_json)
{
    $data = $theme_json->get_data();

    $data['settings']['color']['palette']['default'] = [];
    $data['settings']['color']['duotone']['default'] = [];
    $data['settings']['color']['gradients']['default'] = [];

    $theme_json->update_with($data);

    return $theme_json;
});

Step-by-step reproduction instructions

1 Add theme.jon
2 Add settings.color.defaultPalette, settings.color.defaultGradients, settings.color.defaultDuotone to false
3 Inspect DOM

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[carolinan]

I am not sure I understand. You are correct that adding a custom color palette to theme.json does not disable the default color palette.
If this was changed, and the default palette would be disabled, then that would be a breaking change to every live site that uses both.

But it seems that you have a solution that works for you? I am not sure what the question is.

[webexpr-dhenriet]

Let me explain, I don't understand why setting settings.color.defaultPalette to false doesn't disable default colors and all that goes with them ?
The same goes for defaultGradients and defaultDuotone ?
If they're set to false in theme.json, why do we find all the style loaded on front end ?
Yes, I've found a solution, but I don't understand why I have to go through the wp_theme_json_data_default filter to deactivate all this on the front end when the declaration exists in the theme.json ?

Currently, without using the PHP filter, all default styles (color,gradients,duotone) are loaded, even though I don't want any.

My question should be :
why do these settings.color.defaultPalette, settings.color.defaultGradients and settings.color.defaultDuotone declarations in the theme.json file only serve to hide these things but still load the logic even when set to false ?

If this was changed, and the default palette would be disabled, then that would be a breaking change to every live site that uses both.

yes, it could change the way things work, although I can't see who's using this color palette ?

[hanneslsm]

I don't understand why setting settings.color.defaultPalette to false doesn't disable default colors and all that goes with them ?

Quoting from the issue #36834 (comment) :

Unfortunately, this has been decided to be included within Core Gutenberg regardless if you don't use the gradients, because there's the assumption that other themes and plugins may rely on though css variables.
More information is at #24684 and you can share your reaction in there as well.

[carolinan]

To my knowledge this is for compatibility reasons. For example, a block a pattern may be using these colors to be compatible with all themes. Such is the case with some of the patterns provided by core. A plugin may also be using them.

[webexpr-dhenriet]

I see, I've never come across any of these cases.
Patterns are editable, and we could possibly define color or gradient variables that would be used by a plugin or pattern in the theme.json with the same names, slug and values.
In any case, thank you both for the explanation ;)
The main thing is that we can completely disable all this with the PHP filter.

[carolinan]

It would be of great help to have a complete and detailed issue, since the issue description says something different, it is quiet confusing.

declaring settings.color.palette with new colors doesn't prevent the generation of css variables

I believe you meant disabling the color palette doesn't prevent the generation of css variables

Currently, the only solution I've found is this one

In the comment you are saying that this does not solve the problem?

[webexpr-dhenriet]

I updated the description

[Sisanu]

I am facing the same challenges in version 2 and 3 for theme.json. The main confusion arises from the documentation around the theme.json configuration, which suggests that setting any of the mentioned defaults to false will completely disable that feature. This implies that it would no longer generate CSS tokens or appear in the editor for any components using it. However, if all core patterns are turned off, any settings we attempt to disable have no effect, as explained by @webexpr-dhenriet.

When starting a new project or theme, where backward compatibility isn’t a concern (there are no blocks or patterns registered), disabling settings in theme.json should work as expected (and as documented) and reflect those changes throughout the project.

[carolinan]

Where does the documentation say that the CSS variables are not output if you disable the options?
As far as I can tell, the documentation says:

It’s important to note that, even if these settings are disabled, WordPress will still generate the CSS custom properties for its presets. This is for backward-compatibility and so that users do not lose colors, gradients, or duotone filters that they have previously chosen when using another theme.
https://developer.wordpress.org/themes/global-settings-and-styles/settings/color/#default-wordpress-presets
https://developer.wordpress.org/themes/global-settings-and-styles/settings/color/#enabling-and-disabling-user-customizations

https://developer.wordpress.org/news/2024/07/04/15-ways-to-curate-the-wordpress-editing-experience/
https://developer.wordpress.org/block-editor/how-to-guides/curating-the-editor-experience/theme-json/

Please let me know were you are reading this so that the documentation can be corrected.

[Sisanu]

@carolinan, I am not the only developer misreading the same documentation, I am just saying that it might be easier to make it super obvious that the theme.json settings are only turning off pickers options (or controllers) in the editor, and for those that want to remove on purpose the core presets from being output or available in the store to use the PHP filters.

[carolinan]

The documentation already uses a notice, I am not sure how to make it more obvious than that. I think the problem is that many people don't read documentation.

Also, I am unsure of if the PHP filter shared here removes the CSS variables, since the replies are unclear.

[Sisanu]

I tested and the PHP filter works, at least for the palette, duotone, and gradients. We might have to increase the hook priority, then it works for the color defaults, but not for spacing/spacingSizes or typography/fontSizes defaults.