-
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
Always pass layout to inner blocks #47477
Changes from 5 commits
6bd0112
b5cc279
f301327
7dde489
ebe258d
f1acfb5
e28c0d7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -67,22 +67,13 @@ export default { | |||||
info: alignmentInfo[ alignment ], | ||||||
} ) ); | ||||||
} | ||||||
const { contentSize, wideSize } = layout; | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just double-checking — is the idea that this can be removed now because of the layout object being passed down? From testing, the issue of the wide width post template showing up using content size appears to have returned in this PR. I think the flow layout might still need the logic here (or elsewhere), so that the With TwentyTwentyTwo theme applied, it looks like the post template is being rendered as wide width on the site frontend, but content width in the site editor:
It looks like on the site frontend the post template block's output has both There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That code needs to be removed because it's causing align wide and full controls to always show, even if the parent block doesn't have a content width. The problem is that the layout we're extracting content and wide size from there is the full theme layout, not the block one, so it always includes those properties if they're set by the theme. The specific problem those lines were fixing should now be fixed by the Query block deprecation. I only checked with the test markup from your PR, but will have a look at TT2 now. |
||||||
|
||||||
const alignments = [ | ||||||
{ name: 'left' }, | ||||||
{ name: 'center' }, | ||||||
{ name: 'right' }, | ||||||
]; | ||||||
|
||||||
if ( contentSize ) { | ||||||
alignments.unshift( { name: 'full' } ); | ||||||
} | ||||||
|
||||||
if ( wideSize ) { | ||||||
alignments.unshift( { name: 'wide', info: alignmentInfo.wide } ); | ||||||
} | ||||||
|
||||||
alignments.unshift( { name: 'none', info: alignmentInfo.none } ); | ||||||
|
||||||
return alignments; | ||||||
|
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 might be super edge-casey, but I was wondering if we should check whether or not the block has opted-in to the layout support before passing down its
layout
attribute in the context? Because this will apply to all blocks, if a 3rd party block happens to use an attribute also namedlayout
, then it will be passed down here, too, without a check for the layout block support.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 idea, let's do that!