Cached result for wp_theme_has_theme_json() is not invalided when theme is switched dynamically

[westonruter]

In #56975 the return value of wp_theme_has_theme_json() was cached unless the WP_RUN_CORE_TESTS or WP_DEBUG constants are true. (In #57487 the WP_DEBUG constant was replaced with a wp_get_development_mode() !== 'theme' check.) This workaround is needed to:

Ignore cache when automated test suites are running. Why? To ensure the static cache is reset between each test.

This is because core unit tests often switch themes, resulting in a stale cache. However, sites in the wild also can also dynamically switch themes, and plugins may switch themes during their own unit tests. It seems this check is not ideal and is masking a more fundamental problem: the cached value is not invalidated when the theme is dynamically switched.

A simple fix is to invalidate the cache whenever get_stylesheet_directory() or get_template_directory() change. This eliminates the need for the WP_RUN_CORE_TESTS entirely.

Trac ticket: https://core.trac.wordpress.org/ticket/58758

[flixos90]

Related: #58650

There is some history associated with why we went with a static for caching, so we should make sure performance doesn't degrade with this fix. I like the idea of this approach as it may address the other issues too. At the same time, it still feels cleaner to use the cache API as it supports proper invalidation.

If the added logic here doesn't cause a regression, I think it would be a good addition. But unrelated to that, we may want to find a better solution in the long term.

cc @spacedmonkey @noisysocks @ramonopoly

[westonruter]

After digging into the history a bit: originally object caching was used when this function was first introduced in [55086] by @hellofromTonya. However, the object caching was reverted in [55092] due to object cache not being available in wp-admin/load-styles.php. So then the static variable approach was settled on in [55138].

Trac ticket: https://core.trac.wordpress.org/ticket/58758

[spacedmonkey]

I agree that the current implementation is problematic. It basically guess that the stylesheet will not change in the course of a php request.

I have discussed added a parameter to the function in ​#45955. Little out of scope this, but related.

I also explored adding a method to the WP_Theme class, which would make context aware as well and would add caching. ​#3860

I think the best solution to this would be make $theme_has_support an array and use the stylesheet as a key. This would allow for themes to be switched and the key would change.

I put together a PR for review. ​#4820.

[flixos90]

@spacedmonkey I really like your solution, at least for the short term I think that's a clean approach. It would be great if you could add a unit test for it, otherwise this is good to go IMO.

[flixos90]

@westonruter Just curious why you milestoned this for 6.2.3? Is it crucial to be backported? Otherwise, I'd say this would be fine to just go into 6.3.

[westonruter]

Replying to flixos90:

@westonruter Just curious why you milestoned this for 6.2.3? Is it crucial to be backported? Otherwise, I'd say this would be fine to just go into 6.3.

Oh right. Corrected!

@felixarntz We already have a nice test suite for this in ​Tests_Theme_WpThemeHasThemeJson. There is already a test for switching themes. See ​test_switching_themes_recalculates_support.

Closing in favor of #4820

[spacedmonkey]

In 56185:

Themes: Improved caching in wp_theme_has_theme_json().

Improve logic in wp_theme_has_theme_json() to improve caching soo it takes into account that a theme can be switched. Before this function would overly cache if the current theme has a theme.json file. Now it use the value of get_stylesheet() as a key to an array. This way, if the value of stylesheet is changed, by either a filter or in a unit test, a new check to see if the file exists is run. For this reason, the workaround to check if unit tests are running by checking if WP_RUN_CORE_TESTS constant exists can be removed.

Props westonruter, spacedmonkey, flixos90.
Fixes #58758.

Committed - ​https://github.com/WordPress/wordpress-develop/commit/a92f7bf8cb52b4d00554b5888d39b6a6440f7824