-
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
Layout: show inherit toggle in the absence of settings.layout
object
#59580
Conversation
…nherit toggle regardless of whether there is a `defaultThemeLayout` value. Presently, an empty object will pass the test so perhaps it's okay to remove the check? Also a bit of ESlint stuff for redundant var `css`
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 not confident of this approach.
cc layout oracles @tellthemachines and @andrewserong
@@ -125,14 +125,13 @@ export function useLayoutStyles( blockAttributes = {}, blockName, selector ) { | |||
const fullLayoutType = getLayoutType( usedLayout?.type || 'default' ); | |||
const [ blockGapSupport ] = useSettings( 'spacing.blockGap' ); | |||
const hasBlockGapSupport = blockGapSupport !== null; | |||
const css = fullLayoutType?.getLayoutStyle?.( { | |||
return fullLayoutType?.getLayoutStyle?.( { |
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.
ES lint was bugging me
// and either the default / flow or the constrained layout type is in use, as the toggle switches from one to the other. | ||
const showInheritToggle = !! ( | ||
allowInheriting && | ||
!! defaultThemeLayout && |
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 I don't really know if this is safe.
Things appear to work as expected.
The scenario is that:
allowInheriting
istrue
, butdefaultThemeLayout
has no value.
A value of {}
would pass the test, so it seems safe to just wave it through, unless we specifically want to check for settings.layout.wideSize|contentSize
?
Not sure 🤔
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 question! I haven't taken this PR for a spin, but does this affect classic themes at all? And is it a problem if when you toggle the inherit toggle, if it doesn't immediately apply any rules? I.e. if folks go to set child blocks to "wide" versus content alignment they mightn't see any difference until a value is entered in for the constrained controls 🤔
These are just drive-by comments, though, thanks for working on the fix! If it's still open in a couple of days, happy to take it for a spin and give it a proper review 🙂
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 taken this PR for a spin, but does this affect classic themes at all?
Good question. I smoke tested a couple and couldn't see any difference between this PR and trunk, but I didn't really go in depth.
I'm just wondering if the approach is any good right now 🤷🏻
And is it a problem if when you toggle the inherit toggle, if it doesn't immediately apply any rules? I.e. if folks go to set child blocks to "wide" versus content alignment they mightn't see any difference until a value is entered in for the constrained controls
I'm not sure - I can't see any issue, but I'm a bit layout blind.
Also, the fact that, on trunk,settings.layout
can be an empty object and pass the test is a bit suspect.
If we tighten up that test, so that we need settings.layout
to actually contain something, then we'd have to work out how to deal with the empty layout panel.
Whatever folks think is the best way forward...
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.
Given that this whole UI is going to change once #53455 (or something similar) is ready, it's not too important to make this a perfect fix.
is it a problem if when you toggle the inherit toggle, if it doesn't immediately apply any rules?
I think as long as the controls to set custom content/wide withs are shown, it's not super awkward 😅 because it exposes those controls, which once set will produce the visible effect.
We could perhaps refine the check to make sure that either the theme sets a contentSize
or allowCustomContentAndWideSize
is true, because if neither exist we might as well hide the whole panel.
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: -17 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
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 for fixing this! I think it's OK as is and my testing shows no ill effects on classic or on block themes (layout panel still shows/doesn't show when expected). I did leave a suggestion for further iteration below if you think it's worth it.
@ramonjd Friendly reminder to include the props in the commit description when merging. Also might be good to adapt the copy of the title (commit message). (For next times) |
What?
I'm not really sure if this is right, but this commit will show the layout inherit toggle regardless of whether there is a
defaultThemeLayout
value.Why?
Presently, an empty object will pass the test anyway, so perhaps it's okay to remove the check?
How?
Deleting the
defaultThemeLayout
check that's a condition for the toggle to display.Testing Instructions
In a block theme, remove the "layout" settings object:
Add a group block with "default" layout:
The inherit toggle should be present.
Screenshots or screencast