Global Style Variations: Changes to JSON file are not applied immediately

[mikachan]

Description

When editing a style variation's JSON file, the styles aren't immediately applied when reloading the front end. In order to see the changes, you need to reload the Site Editor, re-select the variation from within Global Styles, and then reload the front end.

Step-by-step reproduction instructions

1. Activate a theme with style variations, e.g. Twenty Twenty-Three
2. Go to Global Styles and change to a different style variation
3. Edit the chosen style variation's JSON file, e.g. change the font size of the navigation block
4. Refresh the front end and observe that the font size has not changed
5. Go back to Global Styles and refresh the Site Editor
6. Re-select the chosen style variation (you should be able to select it as if it isn't activated)
7. Reload the front end and observe that the font size has correctly updated

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 6.0.1, GB trunk, Twenty Twenty-Three

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

[colorful-tones]

This was a huge pain point when developing all the style variations in the Extendable theme.

I'm glad to see an Issue for it. 🙏

[ndiego]

Not a solution, but I found that turning debug on resolves this.

[colorful-tones]

@ndiego can you please clarify? I have define( 'WP_DEBUG', true ); and this does not resolve the issue. Perhaps you're referring to another debug?

I've tried all of the following, and none of them resolve the issue:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'SCRIPT_DEBUG', true );

[ryelle]

I think WP_DEBUG helps for changes in theme.json, but the variation JSON is saved to & loaded from the database. As far as I can tell, there's no way to refresh it except going through the editor process.

[ndiego]

Ah yup, I was referring to the main theme.json file. Thanks for the additional info @ryelle, I didn't realize variation files worked like that.

[aristath]

If I remember correctly, there is a small cache (I think it was 1m or something like that) to avoid parsing things on each page-request.
The caches are bypassed when WP_DEBUG/SCRIPT_DEBUG are true 'cause the assumption is that when you're building something, you have debugging turned on to catch any errors (you do, don't you?)

[ockham]

@michalczaplinski @c4rl0sbr4v0 and I will try to repro this. Maybe this is related to #44434? 🤔

[cbravobernal]

I tried applying #3352 and also #3359 and it didn't work. So I will keep investigating.

[cbravobernal]

It is a tricky issue 😢

The styles aren't immediately applied when reloading the front end. In order to see the changes, you need to reload the Site Editor, re-select the variation from within Global Styles, and then reload the front end.

This is because selecting a style variation creates a post type wp_global_styles in the database. If there is database reference. then the editor will load always the styles based on this reference. So if you edit the JSON file and reload the editor, you will still be loading the styles retrieved from the database, and, for that reason, it won't be updated until you re-select (this gets the styles from the file) and save it again in the database.

If we try to fix this by auto-updating from the file, in that case, it would always rewrite the user's custom styling, making the file JSON the source of truth. This may cause inconsistency, as the user would never see their changes applied.

What could we do as a solution? cc @mikachan

[ryelle]

The way I hacked worked my way around this while making variations for TT3 was to create a filter to wrap around the loaded user styles, and in my theme I had a function that would explicitly load one variation's json file. Since I'd intentionally added that function, I knew the editor-based styles would not be used - but I wasn't changing things in the editor, I was writing JSON.

There are now filters in the theme.json resolver, like theme_json_user, which could probably be used for a similar, non-hacked workaround, but would require theme devs to drop a helper function into their environments.

I thought about whether we could use one of the DEBUG constants to switch the source, since it is probably only necessary for a theme dev coding a theme. But neither WP_DEBUG or SCRIPT_DEBUG make sense, and are regularly used for other debugging.

[colorful-tones]

Perhaps a proposal for a new debug constant is advisable? Maybe STYLE_VARIATION_DEBUG or GLOBAL_STYLE_DEBUG for broader considerations

[cbravobernal]

That proposal could work. But I'm afraid that would be something to experiment with in Gutenberg for a couple of releases, to get some test/feedback, rather than in the 6.1 release.

[mikachan]

I like the idea of a new debug constant 👍

I also think, at the least, we should add some sort of notice to the editor UI that the style variation needs to be re-applied when new changes have been added. Otherwise, there's no way to know why the new theme.json styles aren't being applied (unless you know the reload process already.)

I think it's OK that this can't make it into the 6.1 release, it seems like a bigger issue that needs more time to think about. Is there a style variation tracking issue we could perhaps add this to?

[cbravobernal]

For that notice, we may need help from the design team.
Regarding the tracking issue, would this one fit? #41232

[mikachan]

Yes, that tracking issue looks good, thank you!

[jasmussen]

Hey, thanks for the ping.

At a first glance of the ticket and thread, my instinct was that this issue was the same as I previously recorded in #43914 and closed in favor of this one: that selecting a style variation, saving, and viewing the frontend came with a vey long delay. However that doesn't seem to be the case — should we reopen #43914? The cause is suggested to be the same, but I would think the delay reported there is a bug, whereas this issue appears to be theme.json edit specific:

So if you edit the JSON file and reload the editor, you will still be loading the styles retrieved from the database, and, for that reason, it won't be updated until you re-select (this gets the styles from the file) and save it again in the database.

This seems to fall in theme developer quality of life territory. Which to be clear, is important, but unlike #43914 isn't an issue most people will encounter. A debug constant is mentioned, as is a notice.

Before we go to either, is it possible to be more invisible about it: can we detect that a change has been made to the theme.json file for the active theme, and just load the json file if that's the case? Or, can we show the notice only if such a change has been made? Or even, if we go with a debug constant, can we just not save to the database and always load the json file?

Mostly, it would be ideal if we could avoid showing a notice, mainly because #38333 exists already to make it visually more clear when your style has been customized vs. it being vanilla. The issue itself seems to suggest just loading the json file until you make a change.

[mikachan]

should we reopen #43914?

Yes, I think we should reopen #43914. After working with variations for an extended time, I'm pretty confident these are two separate issues. (Although I guess they might be related to similar functionality underneath - they are two different behaviours.)

Or, can we show the notice only if such a change has been made?

This sounds good to me, it's what I originally meant but I didn't expand very much. I was thinking that showing a notice after you've made changes may be a quick solution to address the UX around this, as I imagine it could be quite frustrating when new variation styles aren't applied in the same way as theme.json styles. But I don't think we need the notice if we can address this with a better solution, and I think this issue does fall more into the theme developer quality of life territory.

[Mamaduka]

Can anyone confirm if this is still an issue with WP 6.2 beta1? Make sure to set define( 'WP_DEBUG', true ); in wp-config.php.

[mikachan]

Can anyone confirm if this is still an issue with WP 6.2 beta1?

I can confirm this is still an issue with WP 6.2-beta1, and is still an issue with Gutenberg trunk. I followed the testing steps from the issue description.

[Mamaduka]

I think there's a slight misconception regarding how selecting the global style variation works.

When a user selects a variation and saves the changes in Site Editor, the variation's settings and styles are saved as changes made by the user. Therefore, WP reads changes from the user origin instead of the variations JSON files.

It is also why reselecting variation after making changes in the JSON files fixes the problem. Fixing the problem will require changing how WP loads variation settings and styles.

@youknowriad, please correct me if I'm wrong.

[youknowriad]

I think there's already another issue proposing to store a "pointer" towards the style variation instead of storing the whole content which would allow us to keep it in sync. That said, even this approach has drawbacks. I remember sharing more thoughts on that issue but I'm failing to find it now.

[Mamaduka]

@youknowriad, maybe this one #46397 (comment)?

[youknowriad]

Indeed @Mamaduka I'd probably close the current issue as a duplicate?

[Mamaduka]

@youknowriad, maybe change the title for #46397 to be more generic about storing variation origins, and then we can close this as a duplicate. What do you think?

[tresorama]

An idea could to store "user" overrides only in the database instead of whole style variation JSON.
On editor load a "deepmerge" is performed to create the live values.
Doing so, only settings that user has arbitrary choose to override will be taken from db, and other are read from the theme's style variations.

This is good for future theme updates.

[Mamaduka]

I am closing in favor of #46397.