-
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
Always pass layout to inner blocks #47477
Changes from 1 commit
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; | ||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -296,6 +296,80 @@ const v3 = { | |
}, | ||
}; | ||
|
||
const deprecated = [ v3, v2, v1 ]; | ||
const v4 = { | ||
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. Can we add a fixture to match this added deprecation? (e.g. 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. Thanks, I always forget about the fixtures 😅 |
||
attributes: { | ||
queryId: { | ||
type: 'number', | ||
}, | ||
query: { | ||
type: 'object', | ||
default: { | ||
perPage: null, | ||
pages: 0, | ||
offset: 0, | ||
postType: 'post', | ||
order: 'desc', | ||
orderBy: 'date', | ||
author: '', | ||
search: '', | ||
exclude: [], | ||
sticky: '', | ||
inherit: true, | ||
taxQuery: null, | ||
parents: [], | ||
}, | ||
}, | ||
tagName: { | ||
type: 'string', | ||
default: 'div', | ||
}, | ||
displayLayout: { | ||
type: 'object', | ||
default: { | ||
type: 'list', | ||
}, | ||
}, | ||
namespace: { | ||
type: 'string', | ||
}, | ||
}, | ||
supports: { | ||
align: [ 'wide', 'full' ], | ||
html: false, | ||
color: { | ||
gradients: true, | ||
link: true, | ||
__experimentalDefaultControls: { | ||
background: true, | ||
text: true, | ||
}, | ||
}, | ||
__experimentalLayout: true, | ||
}, | ||
save( { attributes: { tagName: Tag = 'div' } } ) { | ||
const blockProps = useBlockProps.save(); | ||
const innerBlocksProps = useInnerBlocksProps.save( blockProps ); | ||
return <Tag { ...innerBlocksProps } />; | ||
}, | ||
isEligible: ( { layout } ) => | ||
! layout || layout.inherit || layout.contentSize, | ||
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. By including 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's a good question! I re-used the same logic from the Group block deprecation which seems to be working fine, but will double-check. 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. Yeah, turns out it does run so I added an extra check to only run it if content size is set without constrained layout. |
||
migrate: ( attributes ) => { | ||
const { layout = null } = attributes; | ||
if ( ! layout ) { | ||
return attributes; | ||
} | ||
if ( layout.inherit || layout.contentSize ) { | ||
return { | ||
...attributes, | ||
layout: { | ||
...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 noticed that if 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. I don't think there's any harm in keeping it. We've been keeping it for the Group block deprecation, and on the whole I think the less we change the less scope there is for things to go wrong 😅 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. The main reason I thought of removing it is that a truthy check for Totally agree with trying to change fewer things, though! 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. We can also change the check to not run at all if 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. Why other blocks don't have a deprecation except for Query? It's weird to have an empty Query Loop with all the attributes set.. Also the 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. The Query deprecation doesn't address this change, it should have been added as part of #42763. I added it here in an attempt to fix the issue reported in #43502, as the solution from that PR was causing other breakage.
I'm not sure I understand. Is there anything I should change here? 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. I haven't tested, but this is from the docs:
You could test by copy/paste the other deprecated versions and see if there are errors. 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. Oh, got it, thanks! I'll have a look. |
||
type: 'constrained', | ||
}, | ||
}; | ||
} | ||
}, | ||
}; | ||
|
||
const deprecated = [ v4, v3, v2, v1 ]; | ||
|
||
export default deprecated; |
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!