`wp_theme_has_theme_json`: add public method to know whether the theme supports `theme.json` #3556

oandregal · 2022-11-03T09:45:53Z

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

Related Gutenberg PRs:

Lnking to Gutenberg's 6.2 backport tracking ticket.

What

Adds a new public method wp_theme_has_theme_json that checks whether a theme has a theme.json file.

Why

This offers consumers a public API so they don't have to rely on private code. Additionally, it uses the object cache under the theme_json group to maintain this data, consolidating with the changes done for settings (core PR) and settings (core PR soon, see Gutenberg PR instead).

How

Creates the new public method, substitutes usage, and deprecates the old one.

Test

Verify that automated tests pass.
Using TwentyTwentyThree (a theme with a theme.json) and then a TwentyTwentyOne (a theme without theme.json) do the following:
- Load the front-end. Verify that styles load as expected.
- Load the post editor. Verify that the presets (e.g.: color) are set correctly in the block inspector.

spacedmonkey · 2022-11-03T09:49:33Z

src/wp-includes/global-styles-and-settings.php

+ *
+ * @return boolean
+ */
+function wp_theme_has_theme_json( $clear_cache = false ) {


The fact you have to have a clear cache param to function is bad. This is why the use of static variables should be avoided. Why not just use a global instead?

If the choices we have are polluting the global namespace vs making cache part of the APIs, none is good in my book.

I'm inclined to avoid global as much as possible for scalability (creating a global for every method that needs a run-time cache is too heavy-handed). Additionally, this pattern is in use in WordPress core (example) and plugins (example). It does not matter that the code uses static or an object cache, that's an implementation detail.

Does this clarify my thinking and unblock this conversation?

No. Boolean based flags are a bad pattern. See PHPMD . The example you shared does not link to an example of where a static variable was used. Here is an example of use of static variable made it a real problem to write unit tests. There are other examples of theme based globals like themes_allowedtags ortheme_field_defaults and $_wp_theme_features. I don't see how this would be different.

BTW, I am also aware that global in general, it is how WordPress works I am not here to fix that.

Jonny, going back to this other thread about using object cache and wp_cache_add_non_persistent_groups.

We could update these methods to:

wp_theme_has_theme_json(): no cache parameter. It uses WP_Object_Cache within and wp_cache_add_non_persistent_groups to signal data should not be cached across requests.

wp_theme_clean_theme_json_cached_data(). It clears the object cache instead of calling wp_theme_has_theme_json.

Would that be a good compromise?

I only have one concern with this approach: whether object cache plugins have good support for wp_cache_add_non_persistent_groups. The docs say they may not, although major plugins (memcached, redis, w3 total cache, litespeed) seem to implement it.

The scene of object cache plugins is out of my expertise. So, as long as others confirm this is a good approach that won't be problematic (data won't be cached across requests), I'm fine trying it.

@oandregal What is the reasoning for not caching this data across requests? Whether the theme (or parent theme) has theme.json rarely changes, so I'd like to understand why we need to detect this in every request. Based on my understanding, it would make more sense to:

Use wp_cache_get() and wp_cache_set() here, using a persistent cache group.

Use wp_cache_delete() to wipe this cached data whenever the active theme changes or when a theme has been updated.

Long story short, I would agree with your suggestion to use WP_Object_Cache, wondering though why this should not be persistently cached.

I agree with @felixarntz. Object caching is the way forward. I put together a POC of using object caching. See this commit. e99fd77

What is the reasoning for not caching this data across requests?

I've seen many issues with caches, so my confidence in how we've done caching so far is low. Concrete examples are: transients for the global styles stylesheet have gone through a few iterations, the last one is that people are asking to disable them because it's not working well. Another example is the cache for user data: it had to be reverted during the WordPress 6.1 RC cycle. And so on.

I want us to succeed. I feel part of it is to not repeat the same mistakes. My suggestion is to work in small steps that focus on solving one thing. By making isolated changes, they can be better tested and are easily reverted without affecting unrelated things that are good on their own (such as migrating a private method to a public one). We gain clarity.

Thinking on how to unblock this conversation. I'm happy to hold on merging this PR and introducing a persistent cache in a Gutenberg PR, test it there, and re-evaluate (either backport it here if it works well or go with a runtime cache if it does not).

Does this sound sensible as a path forward?

PR at WordPress/gutenberg#45543

@oandregal Big +1 to working in small steps, I reviewed WordPress/gutenberg#45543 and it looks solid to me.

The WP core functions around caching are very reliable and established for more than a decade, so I would question why we couldn't rely on them. Needless to say, cache invalidation is hard so potentially there were previous issues with it, but that doesn't mean we should give up on using caching. One thing we need to also account for here is that caching around code paths like we're doing here is different from the usual WordPress caching around database requests, so I'd recommend wrapping those cache lookups in ! WP_DEBUG in order to not be a pain to someone who is developing a theme for example and wants changes to be reflected immediately.

Overall I think we're working in the right direction. 👍

src/wp-includes/global-styles-and-settings.php

felixarntz

The changes in here look good to me, other than the caching approach. Specifically, see my comment in https://github.com/WordPress/wordpress-develop/pull/3556/files#r1013265755.

oandregal · 2022-11-16T14:10:57Z

WordPress/gutenberg#45543 is updating a bit the code, I need to port those changes here once they land in Gutenberg.

spacedmonkey · 2022-11-16T23:39:08Z

I think we should look at and focus on my PR here - #3604

oandregal · 2022-12-13T17:36:20Z

I've ported the last changes done in Gutenberg to this PR, so it's up to date and ready to review. Marked the old conversations as done as they no longer reflected the state of this code (nor the conversations over at Gutenberg).

Because its relationship with this other PR (both use the theme_json cache group: they need to make it persistent and offer a way to clean the data), I've ported the same changes over here at 073766e Whatever PR lands first, some changes will not be longer need it. I'm documenting them as PR comments.

cc @felixarntz @spacedmonkey @hellofromtonya @azaozz @anton-vlasenko @costdev

oandregal · 2022-12-13T17:36:55Z

src/wp-includes/default-filters.php

@@ -346,8 +346,8 @@
 add_action( 'init', '_register_core_block_patterns_and_categories' );
 add_action( 'init', 'check_theme_switched', 99 );
 add_action( 'init', array( 'WP_Block_Supports', 'init' ), 22 );
-add_action( 'switch_theme', array( 'WP_Theme_JSON_Resolver', 'clean_cached_data' ) );
-add_action( 'start_previewing_theme', array( 'WP_Theme_JSON_Resolver', 'clean_cached_data' ) );
+add_action( 'switch_theme', '_wp_clean_theme_json_caches' );


If #3712 lands first, these can be ignored, as they'd have already been ported over there.

Hmm, this change seems out-of-scope for the purpose of this PR. What is the impact of committing this PR without this change and before PR #3712 is committed?

responded at #3556 (comment)

IMO keeping this in here is okay. It's not as critical to clean caches for now, given that the cache is non-persistent, but it's still a good practice which we will be able to rely on more in the future. I also think having the _wp_clean_theme_json_caches() function itself makes sense, since we also introduce the wp_theme_has_theme_json() function, which uses that cache.

oandregal · 2022-12-13T17:37:39Z

src/wp-includes/global-styles-and-settings.php

+ * @access private
+ */
+function _wp_clean_theme_json_caches() {
+	wp_cache_delete( 'wp_theme_has_theme_json', 'theme_json' );


If #3712 lands first, this line needs to be added to the function.

Same question here #3556 (comment)

oandregal · 2022-12-13T17:38:21Z

src/wp-includes/load.php

@@ -753,7 +753,7 @@ function wp_start_object_cache() {
 			)
 		);

-		wp_cache_add_non_persistent_groups( array( 'counts', 'plugins' ) );
+		wp_cache_add_non_persistent_groups( array( 'counts', 'plugins', 'theme_json' ) );


If #3712 lands first, this would have already been ported over there (same for the other places where the group was added).

Same question here #3556 (comment).

responded at #3556 (comment)

See above, IMO this is good to keep.

costdev

Thanks for handling this PR @oandregal! I've left some thoughts below.

src/wp-includes/global-styles-and-settings.php

costdev · 2022-12-13T23:22:03Z

src/wp-includes/global-styles-and-settings.php

+		$theme_has_support = is_readable( get_template_directory() . '/theme.json' );
+	}
+
+	$theme_has_support = $theme_has_support ? 1 : 0;


Suggested change

$theme_has_support = $theme_has_support ? 1 : 0;

$theme_has_support = (int) $theme_has_support;

Might as well cast to int here right?

I guess it works, though I strongly prefer the backport PR to be exactly the same as the upstream Gutenberg code, so I rather do whatever is in Gutenberg.

tests/phpunit/tests/theme/wpThemeHasThemeJson.php

oandregal · 2022-12-14T09:46:16Z

@costdev Thanks for the suggestion to use a data provider in the tests, they're much clearer now! All your feedback was addressed.

costdev

Thanks for the updates @oandregal! LGTM 👍

felixarntz · 2022-12-16T00:42:42Z

src/wp-includes/global-styles-and-settings.php

+ *
+ * @return bool
+ */
+function wp_theme_has_theme_json() {


@oandregal See my feedback in WordPress/gutenberg#45955 (review).

I think this function is good like this, however we should also add a method fulfilling the same purpose to WP_Theme. For that method, performance is not as much of a concern, so I think it's perfectly fine not having caching in there (as other methods on WP_Theme don't have such caching either, plus the common use-case we're optimizing for is the current theme, which this function is for).

LMKWYT. We can also do that in a follow up PR, but would like to hear your thoughts.

I have that PR in my queue to re-review, but I've been AFK for a week for personal reasons and have a long backlog :) My TLDR is: I understand having the ability to check for any theme, not just the active one, is something we need. I'm not sure adding that parameter to this function is the way to go. Need to look at that.

In any case, that conversation should not block this PR, as it's a potential follow-up we can do if it comes to implement it that way.

As noted in the PR WordPress/gutenberg#45955. We need to know on EVERY request if the current AND parent theme support theme json. For that reason, this function is not fit for the requirements.

Should this logic live in a method in the WP_Theme class? See is_block_theme as a example.

wordpress-develop/src/wp-includes/class-wp-theme.php

Lines 1486 to 1506 in e27c5a3

/**

* Returns whether this theme is a block-based theme or not.

*

* @since 5.9.0

*

* @return bool

*/

public function is_block_theme() {

$paths_to_index_block_template = array(

$this->get_file_path( '/block-templates/index.html' ),

$this->get_file_path( '/templates/index.html' ),

);

foreach ( $paths_to_index_block_template as $path_to_index_block_template ) {

if ( is_file( $path_to_index_block_template ) && is_readable( $path_to_index_block_template ) ) {

return true;

}

}

return false;

}

wordpress-develop/src/wp-includes/theme.php

Lines 4209 to 4218 in e50c65c

/**

* Returns whether the active theme is a block-based theme or not.

*

* @since 5.9.0

*

* @return boolean Whether the active theme is a block-based theme or not.

*/

function wp_is_block_theme() {

return wp_get_theme()->is_block_theme();

}

As noted in the PR WordPress/gutenberg#45955. We need to know on EVERY request if the current AND parent theme support theme json. For that reason, this function is not fit for the requirements.

Different people have different views on this. @felixarntz mentioned it does not necessarily requires modifying this function. I also shared the implementation can be different. There's agreement on querying themes other than the active theme is needed, though the implementation is not clear yet. Even if that PR was the way to go: it's a future modification that does not affect the API. We should aim to ship work in small pieces to make progress.

Should this logic live in a method in the WP_Theme class? See is_block_theme as a example.

Note that there is a wp_is_block_theme as well, which is the main API for consumers, like this functions aims to be.

Whether we also have a WP_Theme->has_theme_json is something to talk about. This was brought up in the conversations we had in Gutenberg already. There was no clarity about value, so the decision was to ship the pieces that are ready and keep iterating on the parts that needed more thought.

We didn't really discuss this as part of the gutenberg PR, as that is not a gutenberg change, it is a core change. Now we are in core, we need to talk about it again.

I disagree @spacedmonkey. Smaller iterations of work can be committed into Core.

What do I mean exactly? For this particular PR's scope of work, it can be iteratively committed as separate initiatives such as:

Initiative 1: Add functionality to provide a global way to identify if a theme supports theme.json is useful for Core.

Initiative 2: Improve its performance, if needed.

Rather than blocking a backport, let the first get committed with a follow-up to improve its performance.

Hmm that's interesting thought #3556 (comment) @felixarntz. I agree.

It's common for Core to have a global convenience function that wraps around a public method.

I agree:

WP_Theme::has_theme_json() makes sense.

and can be added in a separate PR and commit, ie for smaller scopes of work.

WP_Theme::has_theme_json() makes sense.

See #3604 where I did this

@spacedmonkey The implementation from #3604 uses the WP_Theme method in wp_theme_has_theme_json() function though, which is different from what @hellofromtonya and I were referring to further above though.

Normally I would say it makes sense and we don't want to duplicate code, but what I am outlining in #3556 (comment) is a common core pattern already:

For example, get_stylesheet() does not call WP_Theme::get_stylesheet().

Instead, it implements the behavior in a simpler and less expensive way (without relying on WP_Theme).

That pattern I think we should follow here as well.

We can create the WP_Theme method in a separate PR though, it doesn't have to be the same one.

…theme_json

oandregal · 2022-12-16T10:01:01Z

Rebased from latest trunk to fix some conflicts. I guess this is ready for merging if a core committer finds the time :)

mcsf

LGTM!

spacedmonkey

Blocking this commit until we resolve WordPress/gutenberg#45955.

This PR changes the cache invalidation.

mcsf · 2022-12-19T12:17:53Z

Blocking this commit until we resolve WordPress/gutenberg#45955.

This PR changes the cache invalidation.

One PR is a backport of a function introduced and validated in Gutenberg. The other is a potential improvement still in debate. Both rely on WP_Object_Cache, differing only in the details. I don't see how one should block the other.

spacedmonkey · 2022-12-19T15:25:06Z

src/wp-includes/global-styles-and-settings.php

+	// Does the theme have its own theme.json?
+	$theme_has_support = is_readable( get_stylesheet_directory() . '/theme.json' );
+
+	// Look up the parent if the child does not have a theme.json.
+	if ( ! $theme_has_support ) {
+		$theme_has_support = is_readable( get_template_directory() . '/theme.json' );
+	}


Consider WordPress/gutenberg#45831

That could be a future change, indeed. We need to measure the performance impact as well. If/when we do that, the corresponding backport should be filled. How is that a blocker for this PR?

I am saying, we are have months to go until the 6.2 release, there is no need to merge this change until ALL the PRs on the gutenberg are resolved. I am in no hurry to merge this, let's get it right instead of hurshing changes into core.

we are have months to go until the 6.2 release, there is no need to merge this change until...
...
I am in no hurry to merge this...

I'm actually trying to do exactly the opposite, the "merge early, merge often" strategy. :)

We are merging to WP trunk (6.2-alpha) so no point in delaying it. On the opposite, if there are any bugs the chances to discover them increase if they are also in core trunk, not just released as plugin. Then if something is fixed/patched "upstream" in the plugin, it can be added to trunk too, no pressure.

Merging early and having more chances to discover bugs seems a lot better than merging in the last minute, and eventually having to fix/patch bugs during RC :)

In that terms hoping to see all changes from the current Gutenberg plugin (14.7.3) in core trunk before the end of the year.

I didn't say this could not be merged. Just that is should not be backported to 6.1.2.

hellofromtonya · 2022-12-19T20:42:10Z

I'm confused why this backport PR includes caching changes as these seem out-of-scope for this initiative. Adding wp_theme_has_theme_json() and applying its changes are a specific scope of work for a single commit.

Does adding wp_theme_has_theme_json() not work without the caching changes? Or are these truly separate scopes of work?

oandregal · 2022-12-21T17:15:09Z

I'm confused why this backport PR includes caching changes as these seem out-of-scope for this initiative. Adding wp_theme_has_theme_json() and applying its changes are a specific scope of work for a single commit.

Does adding wp_theme_has_theme_json() not work without the caching changes? Or are these truly separate scopes of work?

That's a great question. The more important thing for me is to have this method available. Not making performance worse is also something I tried to keep in mind, that's why I thought it should have some cache, as the older one also had.

However! I also want to provide a more nuanced answer based on data. I ran some numbers and this is what I found (see raw data extracted from the cachegrind files linked below):

Approach	Cost in the full request (ms)	Cachegrind files
Current status: `WP_Theme_JSON_Resolver::has_theme_support`	0.05ms	cachegrind.out.hello-world.trunk.zip
This PR: `wp_theme_has_theme_json` with object cache	2.7ms	cachegrind.out.hello-world.pr.zip
`wp_theme_has_theme_json` using static variables as cache	0.05ms	cachegrind.out.hello-world.cachestatic.zip
`wp_theme_has_theme_json` with no cache (no object cache or static variables)	1.13ms	cachegrind.out.hello-world.nocache.zip:

When looking at the numbers, you can say that using static variables is faster, and the wp_theme_has_theme_json without any cache performs faster than using the object cache 🙃

However, that's a partial picture. This is the other part of the picture:

Not using any cache is vulnerable to grow conditions (the method can be used in more places, hence the performance impact will have a linear growth). Besides, the data I've shared only shows the performance in my machine (some servers may have slower file access, different PHP versions, etc.).
Using static variables in the method for caching comes with downsides in terms of API ergonomics: the cache leaks through the method parameters. In other words, you need to have this: wp_theme_has_theme_json( $cache_clear ). I actually started with this approach (see thread).
Using the object cache has the advantage that you can swap it for a faster implementation (plugins, etc.). Also, in the future, if/when we make the theme_json group persistent across requests, the cost is minimized (~1ms less at a minimum given if would not have to recalculate support).

All things considered, even the fact that we're talking 1ms here while there are PRs such as #3789 that reduce +350ms, I think the current approach is the more future-proof.

With what I've learned, I wouldn't mind removing the cache altogether if that is preferable for core folks and provided it helps to ship this faster: it is no big impact either way. I wouldn't recommend going back to caching using static variables in the method, as it compromises the API.

felixarntz

@oandregal Overall the PR looks good to me. We can open a follow up PR to bring a similar method to WP_Theme, for parity and to allow for e.g. REST endpoints to use it to cover also other themes than the current one.

I have a few small things though that I think need to be adjusted, see comments below.

felixarntz · 2023-01-16T18:31:46Z

src/wp-includes/global-styles-and-settings.php

+ *
+ * @return bool
+ */
+function wp_theme_has_theme_json() {


@spacedmonkey The implementation from #3604 uses the WP_Theme method in wp_theme_has_theme_json() function though, which is different from what @hellofromtonya and I were referring to further above though.

Normally I would say it makes sense and we don't want to duplicate code, but what I am outlining in #3556 (comment) is a common core pattern already:

For example, get_stylesheet() does not call WP_Theme::get_stylesheet().

Instead, it implements the behavior in a simpler and less expensive way (without relying on WP_Theme).

That pattern I think we should follow here as well.

We can create the WP_Theme method in a separate PR though, it doesn't have to be the same one.

src/wp-includes/global-styles-and-settings.php

felixarntz · 2023-01-16T18:48:10Z

src/wp-includes/default-filters.php

@@ -346,8 +346,8 @@
 add_action( 'init', '_register_core_block_patterns_and_categories' );
 add_action( 'init', 'check_theme_switched', 99 );
 add_action( 'init', array( 'WP_Block_Supports', 'init' ), 22 );
-add_action( 'switch_theme', array( 'WP_Theme_JSON_Resolver', 'clean_cached_data' ) );
-add_action( 'start_previewing_theme', array( 'WP_Theme_JSON_Resolver', 'clean_cached_data' ) );
+add_action( 'switch_theme', '_wp_clean_theme_json_caches' );


IMO keeping this in here is okay. It's not as critical to clean caches for now, given that the cache is non-persistent, but it's still a good practice which we will be able to rely on more in the future. I also think having the _wp_clean_theme_json_caches() function itself makes sense, since we also introduce the wp_theme_has_theme_json() function, which uses that cache.

felixarntz · 2023-01-16T18:48:31Z

src/wp-includes/load.php

@@ -753,7 +753,7 @@ function wp_start_object_cache() {
 			)
 		);

-		wp_cache_add_non_persistent_groups( array( 'counts', 'plugins' ) );
+		wp_cache_add_non_persistent_groups( array( 'counts', 'plugins', 'theme_json' ) );


See above, IMO this is good to keep.

src/wp-includes/global-styles-and-settings.php

hellofromtonya

LGTM 👍

spacedmonkey · 2023-01-16T23:04:16Z

Everyone reviewing this PR should consider this alternative #3604.

This has number of key benefits.

You can see if ANY theme support theme json.
Reuses the theme cache group.
Cleaner cache invalidation.

azaozz · 2023-01-16T23:25:35Z

Which Gutenberg PR(s) is/are covered by this?

src/wp-includes/default-filters.php

felixarntz

@hellofromtonya Approved from my end too. My only nit-pick would be in https://github.com/WordPress/wordpress-develop/pull/3556/files#r1073175993, I think the cache cleanup function should use the suffix _cache for its name instead of _caches, for parity with other core function names.

hellofromtonya · 2023-01-18T10:47:10Z

Thank you everyone. I'm preparing the commit.

hellofromtonya · 2023-01-18T11:41:19Z

Committed via changeset https://core.trac.wordpress.org/changeset/55086.

spacedmonkey reviewed Nov 3, 2022

View reviewed changes

src/wp-includes/global-styles-and-settings.php Outdated Show resolved Hide resolved

spacedmonkey reviewed Nov 3, 2022

View reviewed changes

src/wp-includes/global-styles-and-settings.php Outdated Show resolved Hide resolved

This was referenced Nov 3, 2022

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

Merged

Deprecate WP_Theme_JSON_Resolver:theme_has_support() WordPress/gutenberg#45380

Merged

spacedmonkey mentioned this pull request Nov 3, 2022

Fix wp_head performance regression for classic themes #3536

Closed

oandregal mentioned this pull request Nov 3, 2022

Code quality check for theme.json related APIs WordPress/gutenberg#45171

Open

felixarntz reviewed Nov 3, 2022

View reviewed changes

oandregal mentioned this pull request Nov 4, 2022

Update wp_theme_has_theme_json to use WP_Object_Cache WordPress/gutenberg#45543

Merged

oandregal changed the title ~~Add wp_theme_has_theme_json public method~~ wp_theme_has_theme_json: add public method to know whether the theme supports theme.json Dec 13, 2022

oandregal commented Dec 13, 2022

View reviewed changes

costdev requested changes Dec 13, 2022

View reviewed changes

costdev approved these changes Dec 14, 2022

View reviewed changes

felixarntz reviewed Dec 16, 2022

View reviewed changes

oandregal and others added 9 commits December 16, 2022 10:59

Add new public method wp_theme_has_theme_json

752ce7d

Substitute WP_Theme_JSON_Resolver::theme_has_support by wp_theme_has_…

bb9d154

…theme_json

Add tests

5b09d4d

Port cache group management from PR 3712

3dfbad3

Substitute call to clean_cached_data by _wp_clean_theme_json_caches

04d72ee

Fix lint issue

771a347

Fix lint issues

5d5c69f

Improve tests

16b5d6c

Use data provider in tests

8841842

mcsf approved these changes Dec 19, 2022

View reviewed changes

spacedmonkey requested changes Dec 19, 2022

View reviewed changes

spacedmonkey reviewed Dec 19, 2022

View reviewed changes

oandregal mentioned this pull request Dec 19, 2022

wp_get_global_settings: add object cache #3789

Closed

felixarntz requested changes Jan 16, 2023

View reviewed changes

Make wp_clean_theme_json_caches() public

8604182

hellofromtonya requested a review from spacedmonkey January 16, 2023 21:21

hellofromtonya added 2 commits January 16, 2023 15:34

Comment improvements

901e98a

Test comment and annotation improvements

cbcd7d2

hellofromtonya approved these changes Jan 16, 2023

View reviewed changes

hellofromtonya mentioned this pull request Jan 16, 2023

Plugin: Backport PHP changes for WordPress 6.2 release WordPress/gutenberg#47187

Closed

85 tasks

spacedmonkey reviewed Jan 17, 2023

View reviewed changes

src/wp-includes/default-filters.php Outdated Show resolved Hide resolved

hellofromtonya added 2 commits January 17, 2023 14:54

Add TODO note

91d6ec6

Use todo annotation

c4a2037

felixarntz approved these changes Jan 18, 2023

View reviewed changes

Rename wp_clean_theme_json_caches

3a5b3a1

hellofromtonya closed this Jan 18, 2023

felixarntz mentioned this pull request Jan 19, 2023

Re-add caching to wp_theme_has_theme_json(), but only when not in a WP Admin request #3867

Closed

hellofromtonya mentioned this pull request Jan 19, 2023

Trac 56975 Stub functions in noop and restore caching #3872

Closed

	$theme_has_support = $theme_has_support ? 1 : 0;
	$theme_has_support = (int) $theme_has_support;

	/**
	* Returns whether this theme is a block-based theme or not.
	*
	* @since 5.9.0
	*
	* @return bool
	*/
	public function is_block_theme() {
	$paths_to_index_block_template = array(
	$this->get_file_path( '/block-templates/index.html' ),
	$this->get_file_path( '/templates/index.html' ),
	);

	foreach ( $paths_to_index_block_template as $path_to_index_block_template ) {
	if ( is_file( $path_to_index_block_template ) && is_readable( $path_to_index_block_template ) ) {
	return true;
	}
	}

	return false;
	}

	/**
	* Returns whether the active theme is a block-based theme or not.
	*
	* @since 5.9.0
	*
	* @return boolean Whether the active theme is a block-based theme or not.
	*/
	function wp_is_block_theme() {
	return wp_get_theme()->is_block_theme();
	}

wp_theme_has_theme_json: add public method to know whether the theme supports theme.json #3556

wp_theme_has_theme_json: add public method to know whether the theme supports theme.json #3556

Conversation

oandregal commented Nov 3, 2022 • edited by hellofromtonya Loading

What

Why

How

Test

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

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

oandregal commented Nov 16, 2022

spacedmonkey commented Nov 16, 2022

oandregal commented Dec 13, 2022

oandregal Dec 13, 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

costdev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oandregal commented Dec 14, 2022

costdev left a 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

oandregal Dec 19, 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

oandregal commented Dec 16, 2022

mcsf left a comment

Choose a reason for hiding this comment

spacedmonkey left a comment

Choose a reason for hiding this comment

mcsf commented Dec 19, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azaozz Dec 19, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hellofromtonya commented Dec 19, 2022

oandregal commented Dec 21, 2022

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

Choose a reason for hiding this comment

hellofromtonya left a comment

Choose a reason for hiding this comment

spacedmonkey commented Jan 16, 2023

azaozz commented Jan 16, 2023

felixarntz left a comment

Choose a reason for hiding this comment

hellofromtonya commented Jan 18, 2023

hellofromtonya commented Jan 18, 2023

`wp_theme_has_theme_json`: add public method to know whether the theme supports `theme.json` #3556

`wp_theme_has_theme_json`: add public method to know whether the theme supports `theme.json` #3556

oandregal commented Nov 3, 2022 •

edited by hellofromtonya

Loading

oandregal Dec 13, 2022 •

edited

Loading

oandregal Dec 19, 2022 •

edited

Loading

azaozz Dec 19, 2022 •

edited

Loading