Style variations should be another layer in the theme.json hierarchy rather than stored in the database

[justintadlock]

What problem does this address?

Currently, when selecting a style variation via the Appearance > Editor > Styles screen, the settings and styles from the corresponding /styles/*.json file are imported into the database and saved as the user customizations as the final layer in the theme.json hierarchy. This is problematic for a number of reasons, but primarily:

• Users don't benefit from updates to those style variations. For example, they may want to customize colors to their liking but not touch typography (regardless, all of the variation data and their customizations are stored in the database at the same level).
• Theme authors cannot easily test changes to their variations without selecting, saving, resetting, making their changes, and repeating the process. (Note: I had to build a script to test variations via Composer.)

The current behavior also had to be patched in order to port custom CSS when users switched variations: #61752

What is your proposed solution?

I propose that style variations simply become another layer in the overall theme.json hierarchy, like so:

• WordPress default theme.json.
• Theme's theme.json.
• Variation /styles/*.json.
• User customizations.

This would solve the primary issues. A change should also not negatively impact already-saved customizations.

[justintadlock]

CC: @WordPress/outreach

[markhowellsmead]

Is there a reason why the variations can't be part of theme.json itself?

[justintadlock]

Is there a reason why the variations can't be part of theme.json itself?

It's technically possible to go that route, adding a new property in theme.json, but style variations can be 100s or 1,000s of lines of JSON. If your theme has more than a few of them, that would make for some very large theme.json files.

For my own sanity, I prefer the separation that's offered currently. :)

[markhowellsmead]

Hm; I see your point and I already see a lot of people complaining on social media, that theme.json is already too complex. Are the variation styles not already part of the cascade you mention? Are they simply read in and saved as a user customisation at the moment? If so, then there should be the option to “discard changes”, as there is for templates and template parts.

[justintadlock]

Are they simply read in and saved as a user customisation at the moment?

Yes.

If so, then there should be the option to “discard changes”, as there is for templates and template parts.

We already have that feature of "reset styles," which does the same thing. There's no separation between what are true user styles vs. variation styles, so everything is reset/discarded.

It doesn't solve either of the two primary issues.

[markhowellsmead]

Then I agree with your suggestion, that the hierarchy should be extended in order to read in any /styles/*.json. files directly, instead of these being copied (unmodified) to the database.

[oandregal]

Related #62686