-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fix regression with theme.json settings.shadow.defaultPresets
#6295
Fix regression with theme.json settings.shadow.defaultPresets
#6295
Conversation
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 Core Committers: Use this line as a base for the props when committing in SVN:
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe 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
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
settings.shadow.defaultPresets
if ( ! isset( $theme_support_data['settings']['shadow']['presets'] ) ) { | ||
// If the theme does not have any shadows, we still want to show the core ones. | ||
$default_shadows = true; | ||
} |
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.
Just a quick comment, as I haven't looked at this change in detail, but this line stood out to me while passing by. Does this check mean that if the theme doesn't add current_theme_supports( 'default-shadow-presets' )
it'll still wind up getting the default shadow presets?
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, that's correct.
I think from all of the discussions that I read, the desire was to go for consistency with other settings, so I copied the behavior from colors and gradients just above. However, I know that behavior is different from what you had talked about in WordPress/gutenberg#58908.
If we want to match the appearance-tools
behavior that you were going for there, this can be moved just a few lines lower into the appearance-tools
section.
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 don't feel too strongly about it, but mostly trying to follow the general discussion from WordPress/gutenberg#58908. My impression was that shadows / effects are a bit of a special case, so guarding behind appearance-tools
is likely a better fit so that we're not outputting anything for themes that don't explicitly opt-in either to the presets or to appearance-tools
, but @carolinan might have more insight for the Classic themes use case than me here 🙂
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.
And fair warning, I haven't really tested any of this add_theme_support
code yet. I wanted to get something pushed up as a starting point that folks could look at. But it's all copied from colors/gradients configuration, so I'm relatively confident that it should be working.
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.
so that we're not outputting anything for themes that don't explicitly opt-in either to the presets
This is often a point of confusion for global styles, but setting default*
options to false
does not prevent the styles from being output. It just allows for themes to override the default values. What I've been told is that the default styles always need to exist in order to support patterns between themes. The only preset that handles this differently is duotone.
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.
Ah, gotcha.
The only preset that handles this differently is duotone.
I suppose that's the question then: whether shadows are like colors or font sizes, or whether they're more like duotone in that respect. It might be worth getting more opinions on this? I don't feel strongly either way, my main hope is that whichever way it works feels natural and not unexpected to folks. Maybe @madhusudhand might have some thoughts, too?
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 suppose that's the question then: whether shadows are like colors or font sizes, or whether they're more like duotone in that respect.
The only reason duotone is different is because of the large SVGs that were also being generated WordPress/gutenberg#38299. Changing it was not an easy feat—we had to essentially rewrite duotone from scratch to do all the things that the global styles classes give you for free. And there are still unresolved issues from making that change WordPress/gutenberg#53662 and WordPress/gutenberg#49293.
For something small like a few lines of shadow presets, I promise it isn't worth it.
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.
Good to know, thanks!
register_theme_feature( | ||
'editor-shadow-presets', | ||
array( | ||
'type' => 'array', | ||
'description' => __( 'Custom shadow presets if defined by the theme.' ), | ||
'show_in_rest' => array( | ||
'schema' => array( | ||
'items' => array( | ||
'type' => 'object', | ||
'properties' => array( | ||
'name' => array( | ||
'type' => 'string', | ||
), | ||
'shadow' => array( | ||
'type' => 'string', | ||
), | ||
'slug' => array( | ||
'type' => 'string', | ||
), | ||
), | ||
), | ||
), | ||
), | ||
) | ||
); |
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.
Bonus support for custom shadows in classic themes to match other presets.
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 great 🌟
I think it is best to split this change into separate PR (as it would be a new feature), in case if it gets landed in 6.5 or in a patch version.
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 was required in order to support these lines and match the behavior of colors/gradients.
if ( ! isset( $theme_support_data['settings']['shadow']['presets'] ) ) {
// If the theme does not have any shadows, we still want to show the core ones.
$default_shadows = true;
}
If we decide to diverge from the colors/gradients behavior like we're discussing in https://github.com/WordPress/wordpress-develop/pull/6295/files#r1533015533 and in WordPress/gutenberg#59989 (comment), we could remove it from here and add it to a follow-up.
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 opened an alternative PR (#6303) with shadows enabled by default in classic themes (like colors/gradients) but without the option to opt-out with add_theme_support( 'editor-shadow-presets', array() )
.
Both PRs fix the regression that I'm concerned with.
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.
Thanks @ajlende for bring this alternate approach for discussion.
It feels right to me and also exposes shadows to classic themes without creating any impact.
I gave it a test in both block and classic themes. It tests well with addition of small code. Also it uncovers a small guternberg UI issue where the label is set as Shadow
instead of Border & Shadow
, which I guess not because of the current changes. I am going to make a separate fix.
register_theme_feature( | ||
'editor-shadow-presets', | ||
array( | ||
'type' => 'array', | ||
'description' => __( 'Custom shadow presets if defined by the theme.' ), | ||
'show_in_rest' => array( | ||
'schema' => array( | ||
'items' => array( | ||
'type' => 'object', | ||
'properties' => array( | ||
'name' => array( | ||
'type' => 'string', | ||
), | ||
'shadow' => array( | ||
'type' => 'string', | ||
), | ||
'slug' => array( | ||
'type' => 'string', | ||
), | ||
), | ||
), | ||
), | ||
), | ||
) | ||
); |
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 great 🌟
I think it is best to split this change into separate PR (as it would be a new feature), in case if it gets landed in 6.5 or in a patch version.
Flagging this to @swissspidy and @dream-encode as a PR that may needing a commit prior to WP 6.5 release. |
@getdave see the discussion on the trac ticket. To me there's too much back and forth on this issue and expected behavior seems unclear at this point. That's why I suggested 6.5.1 for this change. But let's discuss on the ticket please. |
Looks like we're converging towards focusing on #6309, so closing this one. |
All discussion for this issue should be done in WordPress/gutenberg#59989
Description
settings.shadow.defaultPresets
totrue
to fix the regression. (Back to working the same as color/gradient preset configuration for block themes.)editor-shadow-presets
anddefault-shadow-presets
for classic themes to configure shadows. (Works the same way as color/gradient preset configuration in classic themes.)Backport to Gutenberg: WordPress/gutenberg#60000
Gutenberg issue: WordPress/gutenberg#59989
Trac ticket: https://core.trac.wordpress.org/ticket/60815
Testing
Here is an example theme.json for testing that would override the default
natural
shadow with a red shadow to make the difference obvious.wp/6.4
trunk
wp/6.4
and this PR match.Regression screenshots
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.