-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Allow themes to provide empty values for color.duotone
and spacing.units
#33280
Conversation
I've got curious about how one can prevent the color panel in the inspector and the duotone control from showing. Apparently we can't, and this is an issue that should be discussed in a different PR. I've tried this in the
Resulting in (notice how the color panel and the duotone control are still accessible but are empty): |
theme.json
can be emptytheme.json
Updated the issue description with data about how this affects the other presets. TLDR: all work well except for units. The issue with units is that UI controls don't respect the empty array passed by the theme and should be fixed in a different PR. |
@@ -1073,6 +1073,7 @@ public function merge( $incoming ) { | |||
// For leaf values that are arrays it will use the numeric indexes for replacement. | |||
// In those cases, we want to replace the existing with the incoming value, if it exists. | |||
$to_replace = array(); | |||
$to_replace[] = array( 'layout', 'units' ); |
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.
@youknowriad would like confirmation about how layout.units
should work. My understanding is that it should work this way:
- if a theme doesn't provide any
layout.units
defaults are listed - themes can override these values via
theme.json
- if a theme provides an empty array in
layout.units
, the control only showspx
- if a theme provides a limited set of units, such as
[ 'px', 'em' ]
, those are the only units shown in the control
Is this behavior correct?
If so, we need to add layout.units
to the list of things we merge ourselves.
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.
@aristath would know more here but it does sound right.
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.
Though that makes me wonder, is layout.units
a thing? Why "units" are in "layout" I feel like that's an error?
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.
isn't it spacing.units
?
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.
Both exist and are used in different places:
layout.units
: layout hook, letter-spacing component, border width hook, column width.spacing.units
: padding hook, margin hook, cover height, unit control.
I don't know if this is proper or we should only have one of them.
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 think replacing layout.units
with spacing.units
would be OK... Both implementations are sub-optimal, but until we figure out a proper way to differentiate these things we should probably keep things as they were 👍
If and when the time comes to differentiate them, a separate ticket should be opened and we can investigate the implementation separately. For now, let's replace things with spacing.units
and keep it consistent ❤️
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.
spacing.units
can be overridden by block, so I wonder if that's enough for now.
Another thing I've noticed is that the UnitControl
uses spacing.units
for availableUnits
: it looks like these are the "allowed units" the control can use unless a consumer filters them via units
. This means that what you pass as units
can only be a subset of spacing.units
: you can't have in layout.units
things that are not part of spacing.units
as well.
I'm also in favor of starting small and add things if we need them later. Remove things is hard/impossible.
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 haven't seen this in use by any theme and doesn't have documentation either, so I presume layout.units
wasn't widely known/used in practice.
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.
For example, if you set spacing.units
to an empty array, any content in layout.units
would've been ignored. I think I'm going to commit this as it is. It's code, so we can always add more, should it be necessary.
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 other side effect here is that we shouldn't add any config to layout that is not about the "layout config" itself (content width, wide width, type of layout), because that config has a meaning holistically and it's not a discrete list of settings.
Prepared this #33303 to specify what settings can be part of layout, so we don't allow random things there.
Ok, units seem to work as expected as well, except for the border-radius that doesn't allow filtering the units by the theme, so I've asked https://github.com/WordPress/gutenberg/pull/31585/files#r666080677 This can be done later as it's unrelated and doesn't affect WordPress 5.8. |
I think you could say |
That raises an error in the translation code because it's expecting an array. We can update that code to allow |
Maybe it's |
We can update
|
No, it didn't. Tested that PR and it also fails with Ok, let's move forward: this PR should focus on fixing the ability to filter and pass empty units to In a different PR, we should address how panels are shown/hidden. I'd argue we should not use
Essentially, the panels should be hidden when the presets they are empty && the other boolean style properties are false. |
@@ -1086,8 +1087,8 @@ public function merge( $incoming ) { | |||
foreach ( $nodes as $metadata ) { | |||
foreach ( $to_replace as $property_path ) { | |||
$path = array_merge( $metadata['path'], $property_path ); | |||
$node = _wp_array_get( $incoming_data, $path, array() ); | |||
if ( ! empty( $node ) ) { |
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 already a similar bug before with using empty. I grepped for empty on this file to make sure we don't have additional issues. I found other suspicious case:
if ( ! empty( $escaped_preset ) ) {
gutenberg_experimental_set( $output, $preset_metadata['path'], $escaped_preset );
}
It is related to user escaping does not affect 5.8 I will confirm if this is indeed another bug and if yes fix it in another PR.
I think for the color panels that's already the case unless we had some regression. |
I think duotone should be consistent with the other presets we can have duotone presets that are always an array, and a customDuotone flag. Duotone is not available at all if the presets are empty and customDuotone flag is false, exactly as it happens on color, grandients, font sizes. |
I'd love @aristath's input but I think nevermind @nosolosw just saw that you did already :) |
phpunit/class-wp-theme-json-test.php
Outdated
@@ -899,10 +884,6 @@ public function test_merge_incoming_data_null_presets() { | |||
), | |||
), | |||
), | |||
'layout' => array( | |||
'contentSize' => '610px', |
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.
not sure what this test is about but this config is valid (contentSize) and maybe we could keep 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.
This commit is removing a previous commit in this PR: I had added this when I thought layout.units
was a valid input and wanted to make sure the merge algorithm respected pre-existing data (layout.contentSize
). If we want a test for this it should live in another method of this file. Can be done in a follow-up PR if necessary.
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.
LGTM 👍
theme.json
color.duotone
and spacing.units
Thank you for the ping! Added comment on #33280 (comment) 👍 |
This is ready in my testing as well. I'm waiting for the conversation at #33280 (comment) to settle before merging this. |
WordPress/wordpress-develop#1489 ports the PHP changes to core. The JS changes are related but don't need to land at the same time: I presume they are going to be part of the next package release for core? |
Or perhaps is best if I push the JS changes to the |
Yeah, next package update but we can include WordPress/wordpress-develop#1489 in the same commit if needed. |
#33295 updates the conditions under which the duotone control and its subcomponents are visible. |
Follow-up from #33280 (comment) I could reproduce the color panel issue: it seems that it requires all things to be disabled/empty, even if the block itself supports only some of them: #33304 |
….units` and remove `layout.units` (#33280)
….units` and remove `layout.units` (#33280)
….units` and remove `layout.units` (#33280)
This fixes an issue with the
color.duotone
&spacing.units
in which empty values didn't override previous origins, resulting in that a theme couldn't provide an empty set for this via itstheme.json
.How to test
Use the TT1-blocks theme.
Test empty units work as expected
theme.json
:px
units.Test filtered units work as expected
theme.json
:px
,em
).Test no units work as expected
color.duotone
andspacing.units
from thetheme.json
of TT1-blocks.I've also tested passing an empty array to the other presets and this is how it should work: colors and gradients should still work as before: hide the list of preset values, but users still can add custom values. Font sizes should still work as before: hide the control.