-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try: bundle the WP_Theme_JSON_Resolver
class instead of inheriting per WordPress version
#46750
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YES! One file to port. Let's do this for all files going forward.
52fdc71
to
703ccaf
Compare
// BEGIN OF EXPERIMENTAL CODE. Not to backport to core. | ||
$theme_json_data = gutenberg_add_registered_webfonts_to_theme_json( $theme_json_data ); | ||
// END OF EXPERIMENTAL CODE. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm doing something similar in the (Web) Fonts API, i.e. wrapping code blocks in inline comments to alert not to backport to Core. I used:
BACKPORT NOTE: <explanation>
How to mark "don't backport" code though likely should be standardized across the codebase. For example, may want to add an annotation such as @backportNote
, @doNotBackport
, etc. Though this is likely best discussed in a separate issue and then added to the docs.
Can we do this for other classes in this repo. It could go a long way to help porting files between the repos. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested in Loudness:
✅ Changing the background and text color
✅ Using refs in theme.json
✅ Using hover in theme.json
Also
✅ Changing the core theme.json file
✅ Changing settings in Global Styles, saving and reloading the frontend.
Lets get this in ASAP to avoid having to deal with the conflicts |
I too like the idea of bundling all changes into 1 class and file. As you note, it'll ease backporting and maintaining efforts. On the Core side though, need to think about how to keep this file synchronized with what's in Core. Why? The
I don't yet have an answer of how to keep things synchronized. But flagging it here for awareness and further thinking. |
Yeah. Ideally, all changes are made in Gutenberg, first. Though I understand that this is a conversation larger than this PR and can also benefit/require some automation, in addition to clarify around flows.
Even with the previous setup, most of the methods were overridden, so most changes in core were ignored. Not inheriting also gives us peace of mind to avoid running into unexpected conflicts with some sites running the nightlies. |
Tested the TwentyTwentyThree theme in a variety of scenarios: updated user data (via global styles sidebar), updated theme data (via theme.json of the theme), and update core data (theme.json bundled with gutenberg). Everything works as expected. |
Tested TwentyTwenty, including modifying some values from the |
Going to merge this one as soon as tests pass. |
Thanks everyone for the quick turnaround on this one :) |
I'm including this in a patch release of 14.8, because it is required for compatibility with WordPress 6.0. I looked through the PR changes, and each deleted file was not modified after 14.8 was released. Assuming this PR is mostly a refactor (maintaining functionality rather than changing how the feature works), including it in 14.8 won't functionally change how 14.8 works. See #46811 for more info |
… inheriting per WordPress version (#46750) * Backport WP_Theme_JSON_Resolver from core as it is * Substitute WP_Theme_JSON by WP_Theme_JSON_Gutenberg * Substitute WP_Theme_JSON_Data by WP_Theme_JSON_Data_Gutenberg * Rename WP_Theme_JSON_Resolver to WP_Theme_JSON_Resolver_Base The goal is to use it as base to inherit from, until we are able to remove all the children. * Make WP_Theme_JSON_Resolver_6_1 inherit from WP_Theme_JSON_Resolver_Base * 6.1: remove field already defined in base class * 6.1: remove translate, it is equal to base method * 6.1: remove get_core_data, it does not have base changes * 6.1: remove get_user_data Missed core changes and does not do anything differently from core. * 6.1: remove get_user_data_from_wp_global_styles It misses core changes and does not do anything differently. * 6.2: inherit from WP_Theme_JSON_Resolver_Base instead of 6.1 This makes the WP_Theme_JSON_Resover_6_1 class unused. * 6.1: remove class no longer in use * 6.2: deprecate theme_has_support #45380 * 6.2: substitute WP_Theme_JSON_Resolver::theme_has_support by wp_theme_has_theme_json() #45168 * 6.2: port changes to get_user_data_from_wp_global_styles #46043 * 6.2: update get_merged_data #45969 * 6.2: remove get_user_data Same code as core. There's a check for detecting whether the class is an instance of WP_Theme_JSON_Gutenberg that was not ported. This check was introduced to make sure the cache of the core class didn't interfere with the cache of the Gutenberg class, so it's no longer necessary. See #42756 * experimental: make it inherit from WP_Theme_JSON_Resolver_Base * 6.2: remove class no longer in use * experimental: delete remove_json_comments It's already part of the base class. * experimental: remove get_block_data It's already part of the base class and it didn't have the changes from core. * experimental: appearanceTools Port changes to the base class that were meant to be part of 6.1. See #43337 * experimental: port webfonts (experimental API) see #37140 * experimental: use gutenberg_get_legacy_theme_supports_for_theme_json #46112 * experimental: get_theme_data, all code is in the base class * experimental: remove empty class * Rename WP_Theme_JSON_Resolver_Base to WP_Theme_JSON_Resolver_Gutenberg * Fix lint issue: rename class-wp-theme-json-resolver.php to class-wp-theme-json-resolver-gutenberg.php * Move theme.json to unversioned lib/ * Move theme-i18n.json to unversioned lib/
What?
This PR bundles the
WP_Theme_JSON_Resolver_Gutenberg
class into a single file, continuing the work done for theWP_Theme_JSON
class at #46579Why?
The existing mechanism uses an inheritance model, where Gutenberg modifies only certain parts of WordPress. This approach:
How?
This PR creates a single file under
lib/
for:WP_Theme_JSON_Resolver_Gutenberg
theme.json
theme-i18n.json
Testing Instructions
Given this moves code from one place to another, it's difficult to provide a test plan. The fact that automated tests pass gives us some certainty the main paths are working.
This is what I've done, though you may want to try things you're most familiar with:
Theme with
theme.json
(TwentyTwentyThree):Theme without
theme.json
(TwentyTwenty):Questions
What to do with experimental code
Experimental code is code that is not ready for backport yet. So far, we've only run into 1 use case I know of: webfonts. For this use case, we only need to call
gutenberg_add_registered_webfonts_to_theme_json
in two places (I've marked them as comments in the PR).In this PR, I propose we simply mark this code as experimental via comments. It's simple enough and works well for this case.
An alternative would be keeping the experimental class and override the
get_theme_data
method. This is what we did now and I'd try to avoid it. We missed a couple of things using this system (and many others in theWP_Theme_JSON
class):appearanceTools
missed the window for being backported to WordPress 6.1.