-
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: Restore appearanceTools when exporting a theme #39840
Theme Export: Restore appearanceTools when exporting a theme #39840
Conversation
if ( array_key_exists( 'appearanceTools', $theme_json['settings'] ) ) { // Is it safe to assume that 'settings' always exsits? | ||
foreach ( static::TO_OPT_IN as $path ) { | ||
// Remove the path. | ||
if ( ! empty( $theme_json['settings'][ $path[ 0 ] ][ $path[ 1 ] ] ) ) { |
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 really hard to read because of the $path[ 0 ] thing, but I'm not sure what would be a better approach...
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.
Maybe something like
foreach ( static::TO_OPT_IN as list( $group, $prop ) ) {
if ( ! empty( $theme_json['settings'][ $group ][ $prop ] ) ) {
Why overload |
So that it can use the new class variable - the old one just has that array hardcoded into the function. |
1d5d27c
to
ced68ae
Compare
protected static function do_opt_in_into_settings( &$context ) { | ||
foreach ( static::TO_OPT_IN as $path ) { | ||
// Use "unset prop" as a marker instead of "null" because | ||
// "null" can be a valid value for some props (e.g. blockGap). |
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.
Can unset prop
be, or ever become, a valid value? I know it's unlikely for, say, color – but still. How about an object? It should also have a unique identity.
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.
All existing opt-ins are booleans (or null).
9a5b652
to
790bbbc
Compare
I was looking into this and thought I'd push a couple of changes to:
|
Thanks @oandregal. I fixed a few linting issues... |
d289eba
to
655b216
Compare
we don't want to pass this to the block-editor store.
655b216
to
ffb8f1a
Compare
What?
When you export a theme that declares support for
appearanceTools
in theme.json we should keep this declaration rather than converting it to the properties that this maps to. Fixes #39464.Why?
This will make it easier for theme developers to use the theme export tool, and also enable them to easy opt in to more settings in the future.
How?
By overloading the
do_opt_in_into_settings
method inWP_Theme_JSON_Gutenberg
and creating a new one calleddo_opt_out_of_settings
which does the reverse.Testing Instructions
appearanceTools
property in theme.json (e.g. TT2)Notes
There are also some other settings that are opted in to (e.g. settings.color.custom, settings.color.customGradient) but this has a different cause so we should look at it in a different PR...
cc @WordPress/block-themers