WP_Theme_JSON_Resolver::get_user_data_from_wp_global_styles is incorrectly cached.

[peterwilsoncc]

This ticket is for tacking the WordPress-Develop changes required for ​WordPress/gutenberg#44946.

From the original report:

When importing demo content using WP 6.1 styles are not imported correctly although the same works fine in WP 6.0.2.

Imported content displays the theme's default colors and styling instead of the styling set for that particular demo. However, in the "Site Editor" styles are correctly displayed. Sometimes when I exit the Site Editor the styles are then correctly displayed in the front end as well, but sometimes it takes a few tries.

This issue happens with the WordPress default importer as well as our theme's built-in import system.

Please see the Gutenberg repo's ticket for further details and discussion.

During investigation, it was discovered to be a cache invalidation issue. The caching within the get_user_data_from_wp_global_styles() method was not cleared when new custom styles posts were created.

The ​linked pull request switches the caching to use the lower-level caching provided by WP_Query. This provides two advantages:

• removes duplicate caching of the same data
• cache invalidation is managed at the lower level

As noted by @spacedmonkey on the ticket: this issue has been around since the method was introduced but the switch from object caching to a transient in 6.1 means that it will affect all sites in 6.1 rather than only those with a persistent object cache.

Committers Please review ​WordPress/gutenberg#44946 when generating the props list for this ticket.

See ​https://github.com/WordPress/gutenberg/issues/44946

See https://core.trac.wordpress.org/ticket/56901

I've done some performance analysis to see how this PR fares (compared it with trunk 54678, the one without the changes from this PR). Tested by loading the "hello world" post as a logged-out user.

| Method | This PR (​data) | Trunk 54678 (​data) |
| ----------------------------------------------------------- | ------- | -------------- |
| WP_Theme_JSON_Resolver::get_user_data (99 calls) | 1.39ms | 1.49ms |
| WP_Theme_JSON_Resolver::get_user_data_from_wp_global_styles (2 calls) | 0.019ms | 0.031ms |

The data variation says this PR (removing the cache) is faster by 0,1ms. On the overall performance of the request, this PR is slower by 2ms (794ms vs 797ms). I'm inclined to think this change does not have any actual effect on performance.

I've also reviewed the PRs that introduced caching to this method: ​https://github.com/WordPress/gutenberg/pull/36584 and ​https://github.com/WordPress/wordpress-develop/pull/2414 and could not see any data, so I'm a bit blind as to what were the actual performance gains back there.

From a performance point of view, this seems fine to land.

As noted ​https://github.com/WordPress/gutenberg/issues/44946#issuecomment-1291645516, once the cache is in place, sure the caches are simple. However, with WP_Query this cache is far more likely to be invalidated and the 1.39ms call would be called many more times for public users.

As a workaround for this issue, I think we could commit this change. But I would like to look at a solution that caches global styles forever and correctly cache invalidates on change. But this would take more time than we have in this release cycle.

[spacedmonkey]

It is also worth noting that wp_get_global_stylesheet and wp_get_global_styles_svg_filters also appear to cache global style data in a transient. These too, do not seems to have correct cache invalidation.

[spacedmonkey]

Created a breakout ticket. #56910

@oandregal Question: Why is get_user_data method being called 99 times in a single page request? Is that seems like a lot?

[hellofromTonya]

For historical context, the caching logic was added in [52275] and improvements in [54186].

[hellofromTonya]

Testing Instructions

Steps to Reproduce

• Use Twenty Twenty Two (TT2) theme
• Use WordPress 6.0.3
• Log into the admin area
• Go to Appearance > Editor
• Open the Global Styles UI
• Select "Browse Styles"
• Select the red styling
• Select "Save" to save the new global styles
• Go back to the Dashboard
• Go to Tools > Export
• Click on "Download Export File" using "All content"

• Using another local site, upgrade to WordPress 6.1-RC3
• Log into the admin area
• Go to Tools > Import
• Select "Install Now" for the "WordPress" importer
• Select "Run Importer"
• Select the XML file using "Choose File"
• Click on the "Upload file and import" button
• View site in the frontend

The 🐞 bug occurs when viewing on the frontend as the site does not use the red styling.

Expected behavior:

When viewing the site in the frontend, the site should use the red styling, i.e meaning the imported global styles are used.

Expected Results

When testing a patch to validate it works as expected:

• ✅ What should happen when running the test

When reproducing a bug:

• ❌ Error condition occurs.

[hellofromTonya]

Test Report

Environment

• Server: nginx
• WordPress: 6.0.3 for generating xml and then 6.1-RC3 for testing import
• Localhost: WP Local
• OS: macOS
• Browser: Chrome and Firefox
• Theme: TT2
• Plugins: WordPress Importer

Steps to Reproduce

See the Testing Instructions.

Results

Patch: ​https://github.com/WordPress/wordpress-develop/pull/3517

Without the patch, can reproduce the issue ✅

With the patch, the issue is resolved ✅

[hellofromTonya]

Follow-up Test Report

Does it happen on WP 6.0.3?

Environment

• Server: nginx
• WordPress: 6.0.3
• Localhost: WP Local
• OS: macOS
• Browser: Chrome and Firefox
• Theme: TT2
• Plugins: WordPress Importer

Steps to Reproduce

See the Testing Instructions expect the importer site is using WP 6.0.3 instead of 6.1-RC3.

Results

No, the bug does not happen on 6.0.3.

Conclusion

This regression was introduced in the WP 6.1 cycle.

[hellofromTonya]

Status:

• Confirmed this is a regression introduced in the WP 6.1 cycle ✅
• Able to reproduce ✅

*​PR 3517 resolves the issue ✅

• PR approved ✅

Marking for commit.

[davidbaumwald]

In 54706:

Themes: Ensure custom global styles are imported properly.

This change removes caching of global styles for logged in users, allowing "wp_global_styles" custom post type to be imported completely, regardless of any previously cached data. This change now relies on the lower-level native WP_Query cache invalidation methods for the global styles post type.

Follow-up to [52275], [54186].

Props anariel-design, bernhard-reiter, andrewserong, spacedmonkey, andraganescu, peterwilsoncc, oandregal, hellofromTonya.
Fixes #56901.

Thanks everyone! Merged into core in https://core.trac.wordpress.org/changeset/54706.

[davidbaumwald]

Reopening for backport to the 6.1 branch pending a second committer's review.

[hellofromTonya]

[54706] looks good for backport to the 6.1-branch.

[davidbaumwald]

In 54707:

Themes: Ensure custom global styles are imported properly.

This change removes caching of global styles for logged in users, allowing "wp_global_styles" custom post type to be imported completely, regardless of any previously cached data. This change now relies on the lower-level native WP_Query cache invalidation methods for the global styles post type.

Follow-up to [52275], [54186].

Props anariel-design, bernhard-reiter, andrewserong, spacedmonkey, andraganescu, peterwilsoncc, oandregal, hellofromTonya.
Reviewed by hellofromTonya.
Merges [54706] to the 6.1 branch.
Fixes #56901.

[davidbaumwald]

Resetting the keywords after the backport.

Merged into Core's 6.1 branch by @dream-encode in https://core.trac.wordpress.org/changeset/54707.