Closed richtabor closed 2 years ago
After looking into this further, it may be because the top-level align full
block is not getting the .wp-block[data-align="full"]
wrapper div within BlockPreview. I'm not sure if this in intentional — @youknowriad do you know?
When a fullwidth pattern is added to the page, it does indeed get the wrapper, which TT2 has negative margin applied to remove the left/right padding effectively.
Within the BlockPreview:
Added to the editor:
I could be wrong here, but I think these previews actually behave the same way that the site editor behaves, in that "inherit default layout" isn't set to true for the main container. And that results in direct "alignfull" children not going 100% full-width.
For our header/footer patterns, I added an extra (empty) Group block wrapper to solve for this and ensure they show up full-width in the site editor (and in previews):
I didn't bother doing that for the other patterns though, which are likely going to be added directly in posts and pages instead. I'm not really sure the best way to solve for this, especially because I don't want to make too many changes that are tailored to the custom CSS layout solution in the Twenty Twenty-Two — I expect that to go away in favor of a Gutenberg-based solution instead eventually.
Hmm, seems like adding an extra group block does resolve it, but that's not ideal for sure :/
Describe the bug It looks like the left/right padding that we've applied to
.editor-styles-wrapper > .is-root-container
is now negatively affecting the BlockPreviews, making fullwidth patterns not appear fullwidth anymore.Expected behavior Fullwidth patterns display as such in the Pattern Library
Screenshots
Additional context WP 5.9 RC