-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Style variations should be another layer in the theme.json hierarchy rather than stored in the database #62661
Comments
CC: @WordPress/outreach |
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 For my own sanity, I prefer the separation that's offered currently. :) |
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. |
Yes.
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. |
Then I agree with your suggestion, that the hierarchy should be extended in order to read in any |
Related #62686 |
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 thetheme.json
hierarchy. This is problematic for a number of reasons, but primarily: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:theme.json
.theme.json
./styles/*.json
.This would solve the primary issues. A change should also not negatively impact already-saved customizations.
The text was updated successfully, but these errors were encountered: