-
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
Theme Export: Add missing properties to theme.json #39590
Conversation
I'm a bit concerned not just that the abstraction 'appearanceTools' was missing from theme.json but that all that it represented was also added. This breaks the abstraction since now things like If the export tool is explicitly aware of the 'appearanceTools' attribute then it (or get_data() from whence it gets the details) may need to keep out of the configuration the things that it represents. However, it's better to have it transition over than not... this fixes MOST of the problem (where it's understood that the author's original intent was to support all 'appearance tools' both present and future). |
Ah yeah that's a good point, maybe we should remove the added properties? I might have another idea how we can do this... |
74d03dc
to
ce5fe20
Compare
Co-authored-by: Andrei Draganescu <me@andreidraganescu.info>
@@ -14,7 +14,7 @@ | |||
* | |||
* @access private | |||
*/ | |||
class WP_Theme_JSON_5_9 { | |||
class WP_Theme_JSON_5_9 extends WP_Theme_JSON { |
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.
This is necessary as the merge function inherits some functions from the original base class.
* @param array $replacements Data to add onto $base | ||
* @return array The result of the merge | ||
*/ | ||
public static function functional_merge( $base, $replacements ) { |
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.
The idea of this function is that it will work with any 2 arrays and do the same thing, so we can use the same logic without being in context of an object.
@pbking I updated the approach here... thoughts? |
$merged_data = WP_Theme_JSON_Gutenberg::functional_merge( $theme_json_data, $user_data->get_raw_data() ); | ||
} | ||
} else { | ||
$merged_data = $user_data; |
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.
It would be super if the complexity of merging this data together into a snapshot JSON string were something abstracted in WP_Theme_JSON_Gutenberg
so that getting that could be a function call instead of repeating this logic.
I'm afraid the latest blows up for me when I switch to the branch. Not sure why, unable to evaluate fully. I definitely better like the way the bits are merged more abstractly rather than peeking and adding specific entries. I haven't been able to 100% follow everything here but even so definitely more comfortable with this direction. |
I've fixed the issue above, and also created a helper function to get the merged data, so the logic lives in the class. Ready for another review... |
Tested again and while the value
|
*/ | ||
public static function get_merged_theme_json() { | ||
// Get the user data | ||
$user_data = WP_Theme_JSON_Resolver_Gutenberg::get_user_data(); |
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.
We've been trying to make the WP_Theme_JSON
class agnostic from where the data comes from and from WordPress APIs (get_stylesheet
, etc), while the WP_Theme_JSON_Resolver
responsibilitiy is to mangle data together. I think we need to keep concerns separate.
I understand you want The core issue seems to be that
|
@oandregal sounds like a good idea. What about $schema? |
That's a tricky one. If we tap into the Options I see:
For |
That concept makes me a lot more comfortable.
In what way does it bend the rules? Could there be a standard schema location that's exported unless overridden? Would be especially helpful if the theme.json version going in was v2 and what was exported to v3. |
Allowing something we don't use or validate, just for the sake of making it part of the export.
This is interesting. Looking at the data ( |
I made a PR for this: #39775 |
I also made this for appearanceTools: #39840 Closing this one... |
What?
This changes our approach to getting and merging theme.json data when a user exports a theme.
Why?
The export should be a copy of the theme, including the user changes. We also should include everything that was in the original theme.json from the theme.
How?
This abstracts the merge function to a static function, so that it can be used by any two arrays. This gives us the freedom to call it from other contexts and reuse the same logic.
Testing Instructions
$schema
andsettings > appearanceTools
attributes are in the theme.json file.Notes
This exports theme.json with spaces not tabs. We should convert this to tabs.