Update `wp_theme_has_theme_json` to use `WP_Object_Cache` #45543

oandregal · 2022-11-04T09:52:35Z

Part of #45171
Follow-up to #45168

What?

This PR updates wp_theme_has_theme_json, so the runtime cache is WP_Object_Cache and not a static variable.

Why?

See this conversation.

There are two advantages to using WP_Object_Cache:

the cache can become transparent to the API (no argument needed to clear it in the wp_theme_has_theme_json method)
sites can convert this runtime cache to a persistent cache by using a plugin

How?

Substitutes the use of the internal static variable by the WP_Object_Cache via the wp_cache_* methods.

The cache is cleaned upon switching themes, upgrade active theme, or previewing the theme.

Testing Instructions

Front-end:

Create a post with a group block and a paragraph within. Publish.
Use a theme with theme.json (e.g.: TwentyTwentyThree). Go to the front-end and verify that the block markup is similar to (no inner div between group & paragraph):

<div class="wp-block-group">
  <p>Content</p>
</div>

Use a theme without a theme.json (e.g.: TwentyTwenty). Go to the front-end and verify that the block markup is similar to (has inner div between group & paragraph):

<div class="wp-block-group">
  <div class="wp-block-group__inner-container">
    <p>Content</p>
  </div>
</div>

codesandbox · 2022-11-04T09:52:37Z

Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

oandregal · 2022-11-04T10:02:38Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

+	function wp_theme_has_theme_json() {
+		$cache_key         = 'wp_theme_has_theme_json';
+		$cache_found       = false;
+		$theme_has_support = wp_cache_get( $cache_key, '', false, $cache_found );


How well supported is the $found parameter? I've seen some reports of it not working well and causing issues in hosts.

I had to check the code reference to see what $found does. Unfortunately, it's not apparent that the parameter is passed by reference.

I've not seen it used in the core much, but this might have changed.

My personal preference would be to avoid using it.

It is used in core here.

Thanks for the reference, @spacedmonkey.

Do you think we need to use the $found argument in this function?

Yeah we do. The default return of wp_cache_get is false if not found. We are storing a boolean value. So we need to use.

Why don't we just store 0 / 1 instead? I'm also a bit wary of using the $found parameter since, while it's part of core, is not at all commonly used to the degree that I'm afraid some cache implementations don't implement it correctly. I think not storing a boolean here and fixing it that way would be a safer call IMO.

Suggested change

$theme_has_support = wp_cache_get( $cache_key, '', false, $cache_found );

$theme_has_support = wp_cache_get( $cache_key, 'themes' );

Added group and remove cache found.

I'm going to store ints. I considered using true/false as strings, though I see how it'll be tempting for our future selves to just convert them to boolean and ignore the rationale for this. I also added a comment to make sure the rationale is documented.

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

oandregal · 2022-11-04T10:08:07Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

@@ -32,6 +30,8 @@ function wp_theme_has_theme_json( $clear_cache = false ) {
 			$theme_has_support = is_readable( get_template_directory() . '/theme.json' );
 		}

+		wp_cache_set( $cache_key, $theme_has_support );


I'm considering setting an expiration period. While cache invalidation should be well managed, this should serve as a last resort in case something goes hairy. The issue is: which would be a good expiration?

Please do not add an expiration here. Let's trust that cache invalidation works. There is no need for a expiration.

+1, we should rely on cache invalidation, not expiration for information like this, which WordPress is in control of tracking.

Suggested change

wp_cache_set( $cache_key, $theme_has_support );

wp_cache_set( $cache_key, (int) $theme_has_support, 'themes' );

ok, let's try without an expiration.

oandregal · 2022-11-04T10:13:48Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

@@ -41,7 +41,7 @@ function wp_theme_has_theme_json( $clear_cache = false ) {
 	 * Clean theme.json related cached data.
 	 */
 	function wp_theme_clean_theme_json_cached_data() {


wp_theme_clean_theme_json_cached_data is now called in the following filters: switch_theme, start_previewing_theme. Do we need any other?

What if a theme is updated and removes or adds a theme.json? How can we flush the cache at that point?

Cleaning the cache on delete_theme sounds like a good idea.

@oandregal +1, we should definitely delete the cache when the theme is updated.

If you're referring to adding/modifying theme.json during development of a theme for example, I think for that we can't properly handle cache, so we may want to wrap the cache usage here in a condition to only use cache if ! WP_DEBUG.

to only use cache if ! WP_DEBUG

Nice, I'm going to implement this.

I've seen something similar in wp_get_global_stylesheet (see), though it also includes SCRIPT_DEBUG and other stuff. I'm not really sure why it was added. It sounds more sensible to just use WP_DEBUG.

Cleaned the cache upon upgrading the theme at 13510c7

Did not added the same for the deleted_theme action because users cannot delete the active theme (manually or via the wp-cli).

felixarntz

@oandregal This looks like it's on a solid path to me, I left a few comments with suggestions below.

felixarntz · 2022-11-04T17:13:02Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

+	function wp_theme_has_theme_json() {
+		$cache_key         = 'wp_theme_has_theme_json';
+		$cache_found       = false;
+		$theme_has_support = wp_cache_get( $cache_key, '', false, $cache_found );


Why don't we just store 0 / 1 instead? I'm also a bit wary of using the $found parameter since, while it's part of core, is not at all commonly used to the degree that I'm afraid some cache implementations don't implement it correctly. I think not storing a boolean here and fixing it that way would be a safer call IMO.

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

felixarntz · 2022-11-04T17:18:45Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

@@ -41,7 +41,7 @@ function wp_theme_has_theme_json( $clear_cache = false ) {
 	 * Clean theme.json related cached data.
 	 */
 	function wp_theme_clean_theme_json_cached_data() {


@oandregal +1, we should definitely delete the cache when the theme is updated.

If you're referring to adding/modifying theme.json during development of a theme for example, I think for that we can't properly handle cache, so we may want to wrap the cache usage here in a condition to only use cache if ! WP_DEBUG.

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

spacedmonkey · 2022-11-07T08:45:22Z

@oandregal Now we are making this change, should we also remove or change the cache from wp_get_global_styles_svg_filters and wp_get_global_stylesheet. See #56910.

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

spacedmonkey · 2022-11-10T11:21:30Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

+		if ( ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) &&
+			( 0 === $theme_has_support || 1 === $theme_has_support ) ) {
+			return (bool) $theme_has_support;
 		}


Changing behavour based on debug flags is not a great idea. It can make debugging issues really hard.

There are different views on how/when to use WP_DEBUG. I'm going to remove it from this PR to unblock it. It can be revisited later in a separate PR should we need.

@spacedmonkey The point of WP_DEBUG here is that we shouldn't use a cache for data controlled by code when in "development" mode. If we don't add WP_DEBUG here, this is going to be extremely painful to work with e.g. as a theme developer who is working on their theme.json and then will never see their changes reflected.

Usually I would agree with what you're saying here about WP_DEBUG, but there is a difference in how we need to handle caching data from the DB vs caching information that is purely controlled by code.

@oandregal If there's disagreement here, I'm fine to leave this off for now to unblock the PR, but IMO we should re-evaluate this as without any extra flag here this will inevitably lead to problems during development.

I'm fine to remove it from here to unblock this from landing and re-evaluate in a follow-up PR.

In development, it's less likely that a theme changes whether it has a theme.json. For other public methods (stylesheet, settings) I feel a lot more strongly that we need that check from the beginning.

#45882 brings back this conversation, for anyone interested in following up.

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

spacedmonkey · 2022-11-10T12:47:06Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

 	 *
 	 * @return boolean
 	 */
-	function wp_theme_has_theme_json( $clear_cache = false ) {
-		static $theme_has_support = null;
+	function wp_theme_has_theme_json() {


This function should accept a theme as a param. So we can check if none active themes have theme json. Example.
https://github.com/WordPress/wordpress-develop/blob/551c3d6619b7e88742911ca2dd3aed77a71cb0dc/src/wp-includes/rest-api/endpoints/class-wp-rest-themes-controller.php#L368-L374

That could be useful, although I'm reluctant to do it in this PR. All the current use cases we have don't need it, so it adds complexity (manage invalidation of stylesheet per theme) without real needs. When/If we need that, we should implement it. It's a good follow-up PR.

I agree with both of you here, but for now I agree more with @oandregal that this can be added in a follow up PR.

Here and here are examples where we need to know if another theme that is not the current theme has theme supports json.

We can add this later, but this is something that is required.

spacedmonkey · 2022-11-16T21:33:10Z

@felixarntz Making this change in the plugin does not make any sense. This code has lived in WordPress since 5.8. Doing this in the plugin is weird and not possible, as it is too hooked into the core code.

felixarntz · 2022-11-16T21:35:42Z

@spacedmonkey The change here is touching code that's already in Gutenberg though, so that's not really the point here. Once it's merged, it'll also be merged into core afterwards, and then we can iterate on it. We shouldn't block this work here just because we can work on it in core as well.

The current Gutenberg implementation is flawed as it doesn't even use caching, and that's what this PR is addressing.

geriux · 2022-11-17T09:26:02Z

Hey there 👋 just wanted to reference this comment about an issue we have with the mobile endpoint and this PR fixes the problem.

Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com>

spacedmonkey · 2022-11-17T10:08:58Z

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

 		}

 		// Has the own theme a theme.json?
-		$theme_has_support = is_readable( get_stylesheet_directory() . '/theme.json' );
+		$theme_has_support = is_readable( get_stylesheet_directory() . '/theme.json' ) ? 1 : 0;


Related #45831

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

Co-authored-by: Miguel Torres <miguel.torres@automattic.com>

mmtr

Thanks @oandregal for your work on this (it made much easier my changes in #45679!).

They look good and test well for me. I think it makes sense to add them first to Gutenberg and backport them later to Core since, as @felixarntz noted above, Gutenberg is currently overriding the Core behavior and changes here specifically target those Gutenberg overrides.

oandregal · 2022-11-17T11:09:50Z

In the interest of making progress, I'm going to merge this PR. All the feedback has been addressed: either implemented or punted for potential follow-up PRs.

I don't think I've ever merged a PR that was blocked by a reviewer. Life is full of first-times. It's with a heavy heart that I make this decision, and I want to offer some context as to why: I was requested to add object cache to this method, and I did (what this PR does). It took two weeks to get this minimal change ready. It was heavily reviewed and everything was addressed. If anything, this PR is a small first step that help the potential follow-ups to be implemented faster and does not block them in any way. To be really candid, in these two weeks I could have focused on shipping higher impact changes (a reduction of 200ms, a 33% improvement) I shared a month ago. Instead, I decided in good faith to address the feedback first, because that's the right to do. That's the kind of trade-off we need to be mindful of: we need to focus on the right things first. Given there is no any actionable basis for the blocker, the PR has two approvals, and we need to move past this, I'm merging.

I also want to share a general note that my DMs are open, and I'll happily join whatever forum people think is best to talk about what how we work and what issues should be our focus, I feel we have some room for improvement. My view is that, to move faster, we need to work together, not against each other and be laser-focused on fixing these high-impact issues, first.

Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com> Co-authored-by: Miguel Torres <miguel.torres@automattic.com> Co-authored-by: Jonny Harris <spacedmonkey@users.noreply.github.com>

oandregal · 2022-11-18T10:02:13Z

lib/compat/wordpress-6.2/default-filters.php

-add_action( 'start_previewing_theme', 'wp_theme_clean_theme_json_cached_data' );
+add_action( 'switch_theme', 'wp_theme_has_theme_json_clean_cache' );
+add_action( 'start_previewing_theme', 'wp_theme_has_theme_json_clean_cache' );
+add_action( 'upgrader_process_complete', '_wp_theme_has_theme_json_clean_cache_upon_upgrading_active_theme' );


Follow-up #45881

GlennMartin1 · 2022-11-18T16:12:52Z

This PR breaks my site:

WordPress version 6.1.1
Active theme: Twenty Twenty (version 2.1)
Current plugin: Gutenberg (version 14.5.3)
PHP version 7.4.33

This line: https://github.com/WordPress/gutenberg/pull/45543/files#diff-cedd84c7ed1db0edc59408b4ee36590a340ed11b5c36a77732026518db0f3e7aR67

Error Details

An error of type E_ERROR was caused in line 67 of the file /home/customer/www/mysiteURL.org/public_html/wp-content/plugins/gutenberg/lib/compat/wordpress-6.2/get-global-styles-and-settings.php. Error message: Uncaught ArgumentCountError: Too few arguments to function _wp_theme_has_theme_json_clean_cache_upon_upgrading_active_theme(), 1 passed in /home/customer/www/mysiteURL.org/public_html/wp-includes/class-wp-hook.php on line 310 and exactly 2 expected in /home/customer/www/mysiteURL.org/public_html/wp-content/plugins/gutenberg/lib/compat/wordpress-6.2/get-global-styles-and-settings.php:67
Stack trace:
#0 /home/customer/www/mysiteURL.org/public_html/wp-includes/class-wp-hook.php(310): _wp_theme_has_theme_json_clean_cache_upon_upgrading_active_theme(Object(Core_Upgrader))
#1 /home/customer/www/mysiteURL.org/public_html/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters('', Array)
#2 /home/customer/www/mysiteURL.org/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#3 /home/customer/www/mysiteURL.org/public_html/wp-admin/includes/class-core-upgrader.php(219): do_action('upgrader_proces...', Object(Core_Upgrader), Array)
#4 /home/customer

The issue is when using 6.1.0+, but disappears if I downgrade to 6.0.3.

It's also only an issue when I run this snippet, which has worked for years:

add_filter('the_posts', 'show_all_future_posts');
function show_all_future_posts($posts)
{
global $wp_query, $wpdb;
if(is_single() && $wp_query->post_count == 0)
{
$posts = $wpdb->get_results($wp_query->request);
}
return $posts;
}

The purpose of this snippet is to publish future-dated posts.

Suggestion? Thanks in advance.

GlennMartin1 · 2022-11-18T17:06:26Z

This issue I mentioned above appears to be resolved by #45881.

Otto42 · 2022-11-20T16:00:48Z

This broke dotorg.

See discussion on Slack: https://wordpress.slack.com/archives/C02QB8GMM/p1668957208385369

oandregal · 2022-11-21T12:24:32Z

I'm unable to reproduce the bug locally, see https://wordpress.slack.com/archives/C02QB8GMM/p1669021968917899

My best guess at the moment is that what wordpress.org experienced is related to this other issue (that may have been made more visible due to the changes here) and that is being fixed by this core patch (it updates how WP_Theme assigns parent and template to the theme).

Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com> Co-authored-by: Miguel Torres <miguel.torres@automattic.com> Co-authored-by: Jonny Harris <spacedmonkey@users.noreply.github.com>

oandregal requested a review from spacedmonkey as a code owner November 4, 2022 09:52

oandregal mentioned this pull request Nov 4, 2022

wp_theme_has_theme_json: add public method to know whether the theme supports theme.json WordPress/wordpress-develop#3556

Closed

oandregal self-assigned this Nov 4, 2022

oandregal requested a review from felixarntz November 4, 2022 09:53

oandregal added [Type] Performance Related to performance efforts Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Nov 4, 2022

oandregal mentioned this pull request Nov 4, 2022

Code quality check for theme.json related APIs #45171

Open

oandregal commented Nov 4, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Outdated Show resolved Hide resolved

oandregal requested review from Mamaduka and aristath November 4, 2022 09:58

oandregal commented Nov 4, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Outdated Show resolved Hide resolved

oandregal commented Nov 4, 2022

View reviewed changes

felixarntz reviewed Nov 4, 2022

View reviewed changes

spacedmonkey reviewed Nov 8, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Outdated Show resolved Hide resolved

spacedmonkey reviewed Nov 8, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Outdated Show resolved Hide resolved

spacedmonkey reviewed Nov 8, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Outdated Show resolved Hide resolved

oandregal force-pushed the add/object-cache-to-has-theme-json-method branch 3 times, most recently from 835743e to de5d387 Compare November 10, 2022 00:08

spacedmonkey reviewed Nov 10, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Show resolved Hide resolved

spacedmonkey reviewed Nov 10, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Show resolved Hide resolved

spacedmonkey reviewed Nov 10, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Show resolved Hide resolved

spacedmonkey reviewed Nov 10, 2022

View reviewed changes

oandregal added 2 commits November 16, 2022 12:56

Add object caching to wp_theme_has_theme_json

0739837

Add a cache group

6003a43

geriux mentioned this pull request Nov 17, 2022

Add wp_theme_has_theme_json as a public API to know whether a theme has a theme.json #45168

Merged

3 tasks

oandregal and others added 2 commits November 17, 2022 10:31

Update lib/compat/wordpress-6.2/get-global-styles-and-settings.php

961528f

Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com>

Update lib/compat/wordpress-6.2/get-global-styles-and-settings.php

af3ecb9

Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com>

spacedmonkey reviewed Nov 17, 2022

View reviewed changes

mmtr reviewed Nov 17, 2022

View reviewed changes

lib/compat/wordpress-6.2/get-global-styles-and-settings.php Show resolved Hide resolved

Update lib/compat/wordpress-6.2/get-global-styles-and-settings.php

5268077

Co-authored-by: Miguel Torres <miguel.torres@automattic.com>

mmtr approved these changes Nov 17, 2022

View reviewed changes

oandregal merged commit dd166c1 into trunk Nov 17, 2022

oandregal deleted the add/object-cache-to-has-theme-json-method branch November 17, 2022 11:11

github-actions bot added this to the Gutenberg 14.7 milestone Nov 17, 2022

fullofcaffeine modified the milestones: Gutenberg 14.7, Gutenberg 14.5 Nov 17, 2022

felixarntz mentioned this pull request Nov 17, 2022

Global Styles: Update gutenberg_get_global_stylesheet to use WP_Object_Cache #45679

Merged

oandregal mentioned this pull request Nov 18, 2022

Fix the upgrader_process_complete hook for wp_theme_has_theme_json #45881

Merged

mmtr mentioned this pull request Nov 18, 2022

Ignore cached wp_theme_has_theme_json when WP_DEBUG is enabled #45882

Merged

oandregal commented Nov 18, 2022

View reviewed changes

costdev mentioned this pull request Nov 18, 2022

14.5.3 - Fatal Error when installing plugins/themes. #45886

Closed

oandregal mentioned this pull request Nov 29, 2022

Make theme.json object caches non persistent #46150

Merged

Mamaduka mentioned this pull request Jan 17, 2023

Plugin: Backport PHP changes for WordPress 6.2 release #47187

Closed

85 tasks

ramonjd mentioned this pull request Jan 11, 2024

Add object caching for WP_Theme_JSON::compute_style_properties WordPress/wordpress-develop#5567

Open

	$theme_has_support = wp_cache_get( $cache_key, '', false, $cache_found );
	$theme_has_support = wp_cache_get( $cache_key, 'themes' );

	wp_cache_set( $cache_key, $theme_has_support );
	wp_cache_set( $cache_key, (int) $theme_has_support, 'themes' );

Update wp_theme_has_theme_json to use WP_Object_Cache #45543

Update wp_theme_has_theme_json to use WP_Object_Cache #45543

Conversation

oandregal commented Nov 4, 2022 • edited Loading

What?

Why?

How?

Testing Instructions

codesandbox bot commented Nov 4, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spacedmonkey Nov 8, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixarntz Nov 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixarntz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spacedmonkey commented Nov 7, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

felixarntz Nov 16, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spacedmonkey commented Nov 16, 2022

felixarntz commented Nov 16, 2022

geriux commented Nov 17, 2022

Choose a reason for hiding this comment

mmtr left a comment

Choose a reason for hiding this comment

oandregal commented Nov 17, 2022

Choose a reason for hiding this comment

GlennMartin1 commented Nov 18, 2022

Error Details

GlennMartin1 commented Nov 18, 2022

Otto42 commented Nov 20, 2022

oandregal commented Nov 21, 2022 • edited Loading

Update `wp_theme_has_theme_json` to use `WP_Object_Cache` #45543

Update `wp_theme_has_theme_json` to use `WP_Object_Cache` #45543

oandregal commented Nov 4, 2022 •

edited

Loading

spacedmonkey Nov 8, 2022 •

edited

Loading

felixarntz Nov 4, 2022 •

edited

Loading

felixarntz Nov 16, 2022 •

edited

Loading

oandregal commented Nov 21, 2022 •

edited

Loading