Add backward compat shim for WP_Theme_JSON_Data::get_theme_json

[joemcgill]

This checks for cases where extenders are returning an object other than WP_Theme_JSON_Data from filters and regenerates the WP_Theme_JSON object if so to avoid issues like this one or #6271 (comment).

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

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props joemcgill, adamsilverstein, oandregal, ryelle, ocean90, pbearne.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[joemcgill]

Updated the PR to address merge conflicts

[adamsilverstein]

nicely solved

[oandregal]

Hi, is anyone able to reproduce this error?

I cannot repro the issue reported using latest WordPress trunk and Gutenberg 14.8.1 (the last release prior to updating WP_Theme_JSON_Data_Gutenberg). I'd like to understand this better before jumping into implementation.

The only way I can think to reproduce the issue is by not using the provided structure to update the data as a consumer of this filter. This is, instead of doing:

add_filter( 'wp_theme_json_data_*', function( $theme) {
  $new_data = array( /* ... */ );

  return $theme->update_with( $new_data );
});

Your plugin does something like:

add_filter( 'wp_theme_json_data_*', function( $theme) {
  /* your plugin code */
  return  $your_custom_structure;
});

Note that this is not supported or recommended. The update_with method is a requirement to use these filters, as stated in the devnote, because it makes sure everything works correctly (data migration, sanitization, etc.). This is what happened to @ryelle, as she reported.

Is there any other use case?

[oandregal]

To be clear, I'm not against doing it, but I'm reluctant to given that it only happens if a plugin provides their own structure, which is not supported or recommended.

[ryelle]

The issue can be reproduced using the Blocks Everywhere plugin, which does the following, basically:

add_filter( 'wp_theme_json_data_theme', function( $theme) {
	$theme = new \WP_Theme_JSON_Data_Gutenberg( /* ... */ );
	return $theme;
} );

(full code here)

Which I suppose is incorrect according to the dev note, but it did work before the recent change.

[joemcgill]

@oandregal I believe this was only reproducible prior to WP_Theme_JSON_Data_Gutenberg::get_theme_json being added in version 18.3.0, which shipped after the core change. If we don't need to worry about WP 6.6 compat with any Gutenberg versions prior to 18.3.0, then we can probably close this issue as wontfix.

However, I think this use case is instructive for us as we consider better ways of managing the WP_Theme_JSON_ classes between the GB repo and the WP-dev repo to avoid these types of conflicts.

[joemcgill]

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.

[pbearne]

This looks good :-)

[ocean90]

This should use the instanceof keyword, see https://core.trac.wordpress.org/changeset/56352.

[joemcgill]

Thanks! I had a sense that we preferred instanceof but couldn't remember the context. Do we not have a sniff for this?

[joemcgill]

Addressed in 544d762

[oandregal]

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]

Committed in 58443.