Avoid re-constructing `WP_Theme_JSON` object from raw theme_json, instead use `WP_Theme_JSON` object inside `WP_Theme_JSON_data`

[thekt12]

In many places, we have code similar to the following.

<?php
$theme_json   = apply_filters( 'wp_theme_json_data_default', new WP_Theme_JSON_Data( $config, 'default' ) );
$config       = $theme_json->get_data();
static::$core = new WP_Theme_JSON( $config, 'default' );

In the above code, we try to get the raw JSON using $theme_json->get_data() and then we try to build back WP_Theme_JSON object. Calling WP_Theme_JSON::_construct is expensive.

If we go a bit deeper we can see that class WP_Theme_JSON_Data has the following constructor

<?php

        public function __construct( $data = array(), $origin = 'theme' ) {
                $this->origin     = $origin;
                $this->theme_json = new WP_Theme_JSON( $data, $this->origin );
        }

By exposing the private attribute theme_json inside WP_Theme_JSON_Data via a public getter, we can avoid the expensive cyclic operation of creating the WP_Theme_JSON object from raw JSON data.

Some early tests ​PR 6271#issuecomment-2085982737 showed by doing this we can avoid 8 calls to WP_Theme_JSON::_construct which improves the overall server load time performance by ~2.5%.

Trac ticket: [Trac 61112
](https://core.trac.wordpress.org/ticket/61112)
Corresponding Guttenberg PR - ​https://github.com/WordPress/gutenberg/pull/61262

This was found while analysing https://core.trac.wordpress.org/ticket/59600, but it relates mostly https://core.trac.wordpress.org/ticket/57789

In this PR we are trying to avoid second call to new WP_Theme_JSON( $theme_json_data ); as the data can be obtained from WP_Theme_JSON_data class using just a line above by introducing a new public method. At the micro level call to WP_Theme_JSON constructor is expensive.

Interestingly, I can see this change also improved static calls. I wasn't expecting that as in my opinion static lines are only executed once, however, this has challenged my view about static calls and might be we need to be mindful of the performance even while using static.

The execution time of the wp_get_theme_data_custom_templates function on the home page of TT4 was evaluated. Each page had two calls to the function. The second call was static cached so it was significantly lower than the time for the first call.

{{{PHP
function wp_get_theme_data_custom_templates() {

Capture the start time
$startTime = microtime(true);
$data = WP_Theme_JSON_Resolver::get_theme_data( array(), array( 'with_supports' => false ) )->get_custom_templates();
Capture the end time
$endTime = microtime(true);

Calculate the script execution time
$executionTime = $endTime - $startTime;
echo "<pre>Execution Time of wp_get_theme_data_custom_templates: " . $executionTime . " seconds.</pre>";

return $data;

}
}}}`

The performance improvement was as noted below:
Before PR

Description	Execution Time (seconds)
Run 1
Execution Time of wp_get_theme_data_custom_templates	0.0033679008483887
Execution Time of wp_get_theme_data_custom_templates	0.00087404251098633
Run 2
Execution Time of wp_get_theme_data_custom_templates	0.003180980682373
Execution Time of wp_get_theme_data_custom_templates	0.00077509880065918
Run 3
Execution Time of wp_get_theme_data_custom_templates	0.0039951801300049
Execution Time of wp_get_theme_data_custom_templates	0.00078392028808594
Run 4
Execution Time of wp_get_theme_data_custom_templates	0.0032379627227783
Execution Time of wp_get_theme_data_custom_templates	0.00077700614929199
Run 5
Execution Time of wp_get_theme_data_custom_templates	0.003154993057251
Execution Time of wp_get_theme_data_custom_templates	0.00075793266296387
Run 6
Execution Time of wp_get_theme_data_custom_templates	0.0032570362091064
Execution Time of wp_get_theme_data_custom_templates	0.00075292587280273

Mean of first call: 0.003366
Mean of static call: 0.000787

After PR

Description	Execution Time (seconds)
Run 1
Execution Time of wp_get_theme_data_custom_templates	0.0030369758605957
Execution Time of wp_get_theme_data_custom_templates	0.0004730224609375
Run 2
Execution Time of wp_get_theme_data_custom_templates	0.0031139850616455
Execution Time of wp_get_theme_data_custom_templates	0.00047683715820312
Run 3
Execution Time of wp_get_theme_data_custom_templates	0.002918004989624
Execution Time of wp_get_theme_data_custom_templates	0.00047898292541504
Run 4
Execution Time of wp_get_theme_data_custom_templates	0.0026509761810303
Execution Time of wp_get_theme_data_custom_templates	0.00044488906860352
Run 5
Execution Time of wp_get_theme_data_custom_templates	0.0027339458465576
Execution Time of wp_get_theme_data_custom_templates	0.00045418739318848
Run 6
Execution Time of wp_get_theme_data_custom_templates	0.0029489994049072
Execution Time of wp_get_theme_data_custom_templates	0.00049400329589844

Mean of first call: 0.002900
Mean of static call: 0.000470

[joemcgill]

Thanks, @thekt12. I've added this to the 6.6 milestone and we can wait for the ​https://github.com/WordPress/gutenberg/pull/61262 to land before porting the change here.

Oh, by the way. It'd be nice if this change would have been done first in the Gutenberg codebase. The value that provides is immense to all of us, including easier synchronization and quick feedback from Gutenberg users if we've missed something. I have nothing against merging it in wordpress-develop first, though I'd kindly ask that the authors port the same PR to Gutenberg. Until we figure out something better, this is what we collectively have and need to care for.

Oh, by the way. It'd be nice if this change would have been done first in the Gutenberg codebase. The value that provides is immense to all of us, including easier synchronization and quick feedback from Gutenberg users if we've missed something. I have nothing against merging it in wordpress-develop first, though I'd kindly ask that the authors port the same PR to Gutenberg. Until we figure out something better, this is what we collectively have and need to care for.

Thank you @oandregal for your feedback. We clearly understand your feedback about Gutenberg first approach, hence we have already created a PR for Gutenberg (link in description of this PR). Once it's tested and approved on Gutenberg we can then plan to merge it for the core.

​https://github.com/WordPress/gutenberg/pull/61262

Thank you so much 🙏 I approved the Gutenberg PR.

By reviewing the Gutenberg PR I noticed that the core code is missing a check: see ​https://github.com/WordPress/wordpress-develop/pull/6271#discussion_r1589940324 and ​https://github.com/WordPress/gutenberg/pull/61262/files#r1589940214. I don't know why they have differed but that check is important and we should consolidate both codebases.

[joemcgill]

I've reached out in ​the Gutenberg repo about merging the related PR there, but intend to commit this here before the Beta 1 cutoff.

[joemcgill]

In 58185:

Editor: Remove additional calls to WP_Theme_JSON::_construct.

This improves performance of the WP_Theme_JSON_Resolver class by avoiding redundant construction of WP_Theme_JSON objects for each origin.

Props thekt12, joemcgill, swissspidy, audrasjb, oandregal.
Fixes #61112.

Merged in https://core.trac.wordpress.org/changeset/58185.

[ryelle]

I think this is going to cause trouble for anyone running WP trunk + Gutenberg— I've just updated a site and it triggered a number of Call to undefined method WP_Theme_JSON_Data_Gutenberg::get_theme_json() errors.

That should be fixed when the corresponding GB code is updated (I see it was done in ​this PR), but that won't be released for another two weeks, I believe. Is there anything that can be done in the meantime?

(I'm reopening this for that reason, but let me know if I should take this elsewhere)

[thekt12]

@ryelle Call to undefined method WP_Theme_JSON_Data_Gutenberg::get_theme_json() is a bit strange error to occur. If you see the introduction of WP_Theme_JSON_Data_Gutenberg::get_theme_json() method and related changes occur in a single PR(​PR). Can you check if changes to https://github.com/WordPress/gutenberg/blob/trunk/lib/class-wp-theme-json-data-gutenberg.php are reflected properly on that site, I can see the method on trunk?

Also, there is no fear of conflict with the core as class names are different in both places. If WP trunk + Gutenberg are active, the Gutenberg class is given priority over the core class.

[thekt12]

@ryelle I think I understand the scenario now. If I understand correctly, you have your core updated to these changes, but your Gutenberg plugin is still old.
This error in any scenario shouldn't occur given we have different class names for the same reason.

[dd32]

@thekt12 This would be with WordPress Trunk + Latest Gutenberg (Which is 18.4). The PR in Gutenberg is in 18.5 (unreleased).

This is indeed that the Gutenberg class is being preferred, but core is expecting a newer version of the class, which doesn't yet exist in the plugin.

I can't duplicate the exact error, but I can get this:

Fatal error: Uncaught Error: Call to undefined method WP_Theme_JSON_Data_Gutenberg::get_theme_json() in wp-includes/class-wp-theme-json-resolver.php on line 257

Call stack:
WP_Theme_JSON_Resolver::get_theme_data() wp-includes/class-wp-theme-json-resolver.php:598
WP_Theme_JSON_Resolver::get_merged_data() wp-includes/global-styles-and-settings.php:182
wp_get_global_stylesheet() wp-includes/block-editor.php:511

[joemcgill]

This seems to be one of the unfortunate side-effects of the way we're currently handling the WP_Theme_JSON_ related classes between the Gutenberg plugin and WP/trunk. Even though the GB plugin prefers its own versions of those classes, we have several functions, like wp_get_global_stylesheet() that reference the core versions directly, by calling WP_Theme_JSON_Resolver::get_merged_data() rather than allowing for the opportunity for the WP_Theme_JSON_Resolver_Gutenberg class to be preferred.

We've talked about the possibility of consolidating all development of the WP_Theme_JSON_* classes to a package in the GB repo that would be synced to WP with other package syncs, but we would potentially still have this problem for anyone running trunk with a previous version of the GB plugin, or when the last sync before beta is made prior to the official 18.5 release date for GB (maybe an edge case?). The other option, would be to make sure that the GB related classes were extending the core versions even thought the way that approach was previously implemented was not a great DX (​see the related ticket).

In the meantime, I think we need to add a check to make sure anything filtering the wp_theme_json_data_theme and related filters are returning a WP_Theme_JSON_Data object before calling the new method.

This adds a method_exists check for backwards compatibility for any extenders who are returning a WP_Theme_JSON_Data compatible object from filters that have not yet implemented the new get_theme_json method in order to avoid errors like this one.

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

[joemcgill]

@ryelle and @dd32, I've opened a PR that should address the issue you've both reported. Could you give it a try and confirm that this fixes the issue?

[ryelle]

I was AFK for a couple days, but now that I'm back I was able to take a look at the issue — it turns out ​there was a bug in some of my code, which used the wrong class. Somehow it worked fine before, but broke after this commit. I didn't realize in the cascade of errors I saw that it was only triggering on select Rosetta sites that use this code.

In any case, I did test with your PR and it does fix the problem — but this is maybe more my error than core's, so I'm not sure if it's necessary.

[ryelle]

I spoke too soon, and found the issue @dd32 mentioned (I didn't realize it was a separate case). In that case, there's a plugin that calls WP_Theme_JSON_Data_Gutenberg directly (it's returned from the wp_theme_json_data_theme filter, which then tries to get ...->get_theme_json(), causing the error).

While that's probably not best practice, ​there are at least two plugins doing it, so it probably is better to add the shim in case others run into this.

[joemcgill]

Thanks @ryelle. Given that we currently have cases where a plugin is using the filter to return a WP_Theme_JSON_Data_Gutenberg object that may not be fully compatible with changes in core, I think we should at least add the safety check for now.

I'll open a new Gutenberg ticket to address the larger architectural concerns for the future.

Updated the PR to address merge conflicts

[joemcgill]

Since GitHub code review comments don't come through here, I want to make ​this conversation visible.

Summary: It seems that this issue is only reproducible when this code is run alongside Gutenberg versions prior to 18.3 18.5, so we might close this and consider the bug fixed upstream.

It would be useful to have someone confirm that this issue only reproducible when running GB 18.2 or lower with the Blocks Everywhere plugin, which returns a WP_Theme_JSON_Data_Gutenberg object from the wp_theme_json_data_theme filter, and that upgrading to GB 18.3 18.5 solves the issue.

[ryelle]

The Gutenberg version where this is fixed is 18.5, which only came out yesterday, but otherwise that's correct.

In testing, updating to GB 18.5 + WP trunk + Blocks Everywhere does fix the fatal error (although Blocks Everywhere only supports up to 17.9, so we can't actually update). I've also opened ​a PR to fix the issue in Blocks Everywhere.

Overall, it does sound like a combination of "doing it not-quite-right" in plugins, and fixed upstream now that 18.5 is out.

I've updated the approach here, based on conversation in ​this thread to ensure that when an object returned from these filters that are not WP_Theme_JSON_Data objects have their data revalidated as WP_Theme_JSON objects to avoid potential compatibility conflicts.

[joemcgill]

Thanks for the update, @ryelle. I confirmed that the @since docblock tag is incorrect in that file, opened a PR to address this ​here and have updated the text of my testing instructions above.

In the meantime, I've also updated the approach proposed in the PR to address a wider range of potential compatibility issues.

This looks good :-)

I reviewed the new changes and checking for WP_Theme_JSON_Data is a good approach. In addition with concerns raised by how Gutenberg extends core, this may help with other cases as well: ​example, ​example.

[joemcgill]

In 58443:

Editor: Improve compatibility for WP_Theme_JSON_Data.

This checks that objects returned from any of the wp_theme_json_data_ filters are WP_Theme_JSON_Data objects in order to avoid incompatibilities. Otherwise, reprocess the theme.json data as new WP_Theme_JSON objects to ensure the data matches the expectations of code consuming that data.

Follow-up to [58185].

Props joemcgill, adamsilverstein, oandregal, ryelle, ocean90, pbearne.
See #61112.

Committed in 58443.