Save theme style variation in options instead of in the custom global styles post

[dballari]

Hi,

I have tested this using Gutenberg v18.5.0 and WordPress v6.5.4 and a theme with two style variations: a default bright and a dark one.

This issue has a lot to do with issues 43405 by carolinan and 51512 by pbking.

I start by using default theme style variation with no customization. As a result I have an empty Custom Styles post in the posts table (containing only this code: {"styles":[],"settings":[],"isGlobalStylesUserThemeJSON":true,"version":2})
I choose the dark style variation from the editor and save. Now I have the Custom Styles posts full with all the contents of the json file corresponding to the theme variation I have chosen.

This is a wrong behavior, is like if the system was lying to us. It says I have chosen some custom settings like colors etc, but I have not. I have just made an option similar to activating a new theme.

Now, let me chose a custom color, which will replace the Accent / Two color of the dark variation. I go ahead and save. Now the system is not lying to us, it’s saving my customization in the Custom Styles posts. But here we have a problem: the system has just mixed my option (the theme style variation which lives in the theme styles subfolder which is not a custom setting) with my recently modified custom setting. The problem here is big, because there is no way to separate both again, there is no way to differentiate what parts of the json stored in the Custom Styles post belongs to the theme and what parts belong to the user.

At this point I have a problem, lets imagine I want to use the Create Block Theme to save my custom setting in the theme.json file, but as I have chosen the dark variation I want this save action to modify the json of the right variation. If I do this, the create block theme plugin has no way of doing it, and does another action: replaces the color in the default variation. A color that was supposed to belong to the dark variation. Intuitively, this action should be done over the chosen variation, not the default one.

Ok, I’m not going to do this, because the plugin will not be able to do it, but I will do a last action: I click on the 3 vertical dots of the theme color setting and click reset colors. This means the system should only reset the Accent / Two color of the dark variation. But again it’s impossible to perform this action because the system does no longer know which are custom settings and which are theme styles. On the other hand, something really weird happens: I end up with a bright theme and a Custom Styles post which is a mixture of the dark variation and the default one. So the only way to fix it is to chose a different variation and save.

Solution:
When a user chooses a theme style variation, this option should be saved in the options table, like the template or the stylesheet option. We could call it theme_style_variation or something like that, and no information should be added in the Custom Styles post.
To render a theme, the system should first look at this option and then find the complete json to be used and then render the styles.
This way, custom settings would never get mixed with style variation option and the Created Block Theme would know which style variation json file to modify when the save ‘Save Changes to Theme’ is chosen with the checkbox ‘Save Style Changes’ checked.

This solution has many more advantages. For instance, when designing/developing a theme, sometimes we change the json and if we are in the development environment we just have to refresh the browser and we can see the changes. On the other hand this is not the case if we modify the json of a theme variation. The json will not be updated unless we chose another variation and save and then go back to the variation. Because the system is looking at the json saved in the Custom Styles post instead of going to the theme/style subfolder and look at the json of the variation we have just modified. That is, modifying the json of a variation (during design and development) is slower than modifying the default json because we need to reset the Custom Styles post which is not really storing custom styles at this point.

I believe it would be really great if this enhancement is applied to the Gutenberg project. I believe is a basic functionality upon which some other things would improve.