Page/Post editors: When template has "Inner blocks use content width", editing looks broken

[jasmussen]

Consider the following Page template layout, which features the Post Content block inside a 2-column setup, where the columns block applies proper padding to ensure that things are nicely spaced out:

Note in this case how the Post Content block has the option, "Inner blocks use content width" unchecked. As a result of this option being unchecked, the regular page editor looks entirely broken, with an unbounded main column and no padding:

This layout is entirely buggy and is not a good experience.

Going back to the Page Template, if the "Inner blocks use content width" option is checked, the final site layout would look incorrect due to the intent of the 2-column setup:

However when this option is enabled, the page editor looks usable again, with its trademark center column for content:

Here's a GIF showing toggling and untoggling, and its effect on the page/post editors:

In other words, it seems like the unbounded page and post editors were intentionally made to unbound their main column when Post Content has this property toggled or untoggled. The net result is a very buggy post/page editor experience. Perhaps the intent was to be closer to WYSIWYG, but so long as the container that surrounds the Post Content blog is omitted in page or post editors, it will never by WYSIWYG, it will only ever be broken. So until that can be the case, post and page editors should not be affected by the Inner blocks/content width property.

[youknowriad]

cc @tellthemachines

The question here is what "layout" to apply in the post editor. Initially we just used to apply the "layout" from "theme.json" but I believe this was changed at some point to try to load "post content" block from the template and "guess" the layout from that to closely match the frontend config.

It seems what we want is something like that:

1- Fetch the "layout config" from the post content block.
2- If there's a layout with "content widths" defined, use that one.
3- If there's no content width in the layout, use a random centered div around the post editor like 700px with some padding on the edge for small screens but disable wide/full alignments.

Is this your expected behavior @jasmussen ?

[jasmussen]

To put it more simply, my expected behavior would be to have a better default experience in the post and page editors, and it could be as little as a fixed max-width on post and page editors like we had in the past. But to answer briefly, yes your solution could also work.

---

To expand a bit: presumably the change affecting post and page editors happens on the assumption that untoggling the layout property is an intentional design choice that should, through the principles of WYSIWYG translate to the post and page editors. But I can't think of a case where as a theme developer I would want that. Consider this layout:

Through code, the pertinent bits:

<!-- wp:group {"lock":{"move":false,"remove":true},"style":{"border":{"width":"0px","style":"none"},"dimensions":{"minHeight":"50vh"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group" style="border-style:none;border-width:0px;min-height:50vh"><!-- wp:columns {"align":"full","style":{"spacing":{"padding":{"right":"var:preset|spacing|50","left":"var:preset|spacing|50","bottom":"var:preset|spacing|70","top":"var:preset|spacing|20"}}}} -->
<div class="wp-block-columns alignfull" style="padding-top:var(--wp--preset--spacing--20);padding-right:var(--wp--preset--spacing--50);padding-bottom:var(--wp--preset--spacing--70);padding-left:var(--wp--preset--spacing--50)"><!-- wp:column {"width":"32.5%"} -->
<div class="wp-block-column" style="flex-basis:32.5%"><!-- wp:post-title /--></div>
<!-- /wp:column -->

<!-- wp:column {"width":""} -->
<div class="wp-block-column"><!-- wp:post-content {"lock":{"move":false,"remove":false},"style":{"dimensions":{"minHeight":"50vh"}},"layout":{"type":"default"}} /--></div>
<!-- /wp:column --></div>
<!-- /wp:columns --></div>
<!-- /wp:group -->

So in this case the post content block has its inheritance toggled off so it can be full-width inside a column container on the template page. Here's the corresponding page editor:

So the short is, that so long as the page and post editors are unaware of their surrounding templates (and any containers that might be holding Post Content), the layout change seems to be mostly meaningless.

[youknowriad]

@jasmussen For the "on"/"off" state of the toggle I agree but what about the "content width" and "wide width". Do you expect the widths to either:

• match the ones defined on the "post content" block
• pick random defaults for full/wide widths.
• pick the default widths from the "layout" property of theme.json

[jasmussen]

Right, I'd definitely lean towards theme.json values for post and page editors!

[youknowriad]

@jasmussen I think that's the previous behavior, it has been changed at some point but I agree that even if it's not perfect, it makes for a better default behavior and it's also more performant because there's no need to introspect the post content block.

[andrewserong]

One thing to consider with making changes to the logic is that some of the current behaviour was introduced due to folks intentionally having full-width templates, e.g. the issue in #51371. So it sounds like there'll likely be a trade-off over which defaults we prioritise for? Overall though, ensuring usability within the post editor, even if it doesn't directly match the site frontend, sounds like a good goal to me.

[jasmussen]

I know that @SaxonF and @jameskoster have had some thoughts around "editor unification" in terms of optionally showing template properties and more in the post and page editors, so there's an opportunity in the future to do that in a coherent way.

As it is implemented today, however, I would argue the use case in 51371 is best handled by editing those pages in the site editor. As is, we have made the writing flow for just updating posts and pages very poor for a great deal of themes, to account for what is arguably an edgecase.

[andrewserong]

As is, we have made the writing flow for just updating posts and pages very poor for a great deal of themes, to account for what is arguably an edgecase.

I think that's a good way of putting it — it can sometimes be tricky to figure out which is the dominant use case and which is the edge case. I believe an assumption was probably made that most themes would likely be using constrained layout for the post content block, rather than intentionally setting the block to full-width and then constrain via a two-column layout in themes.

I agree with the discussion here — to prioritise the writing flow for posts and pages. I imagine we'll likely need to keep in mind that once we make subsequent changes, there could be some feedback from folks who flag it as a breaking change for their particular sites, but on balance I think it sounds like a good idea.

[tellthemachines]

Going back to the Page Template, if the "Inner blocks use content width" option is checked, the final site layout would look incorrect due to the intent of the 2-column setup:

Hmm, not necessarily. If the intent is for Post Content to be aligned to the left hand side of the second column, the layout justification controls already allow that. In this case, it would still be useful for Post Content to have "inner blocks use content width" so that the text doesn't become illegibly wide on a large screen.

It's a valid point that the post editor view doesn't take the full template structure into account, so we can never be sure if edge-to-edge text really is the desired outcome, and I agree it's likely not the desired outcome for most cases.

What is the preferred solution though? A minimum margin around the editor so nothing bumps against the sides, or a maximum content width (with the content centered)? Or both, to take small viewports into account too?

[jasmussen]

What is the preferred solution though? A minimum margin around the editor so nothing bumps against the sides, or a maximum content width (with the content centered)? Or both, to take small viewports into account too?

Honestly, any small patch that restores the center column we had before. Even if the intent of having some synchronicity based on the behavior is good, the previous behavior was better. But Riad's suggestion here seems good.

[richtabor]

What is the preferred solution though? A minimum margin around the editor so nothing bumps against the sides, or a maximum content width (with the content centered)? Or both, to take small viewports into account too?

Honestly, any small patch that restores the center column we had before. Even if the intent of having some synchronicity based on the behavior is good, the previous behavior was better. But #52163 (comment).

I uncovered this behavior recently and thought it was a layout bug (as reported in #60311).

I expected the editor and front-end layout values to always reflect 1:1. 😅

Maybe the "post" post format is fine to assume contentWidth intent; but certainly for pages we can't assume.

[jasmussen]

This recently regressed, so reopening.

[jasmussen]

To add more context, this is mainly/only about the abstracted editor, when "show template" is toggled off, which it is by default in the post and page editors. You should never see a content column that goes left edge to right edge.

[andrewserong]

Thanks for re-opening @jasmussen! Here are a couple of previous PRs from last year:

• Try using fallback layout instead of default in post editor #54371
• Fix layout when post content is root block #54485

If I'm following those PRs correctly, the logic from those PRs was:

• If the post content block is at the root of the template and content width is switched off for the block, then the layout is displayed edge-to-edge in the post and page editors, as that will match what's happening in the template (since the post content block is at the root)
• If the post content block is not at the root (i.e. it's within a column or any other nested configuration), and content width is switched off, then the layout is displayed using a fallback content width.

So I agree, it sounds like somewhere along the way this has regressed. I wonder if it broke somewhere during the editor unification efforts? FYI: @tellthemachines in case you remember if there were any other relevant changes since those above.

[andrewserong]

So I agree, it sounds like somewhere along the way this has regressed.

@jasmussen are you able to provide reproduction steps? The markup for the template your using could help give some clues here to hone in on the logic and whether there's a fresh bug, or something unique to the template you're working with.

In my testing so far, it seems that the feature of using the fallback layout is working okay for me if the post content block switches off content width, but does not have full width alignment set:

Template	Editor view without template preview

If I go to set the Post Content block to have full width alignment, then the CSS rules for full width alignment on the content block take precedence over the fallback layout:

Template with full width alignment set	Editor view without template preview (unintended full width alignment)

In the latter, we can see that the content width is intended to be used, but is being overridden by the editor's styling for full width content blocks:

That rule is set here:

gutenberg/packages/editor/src/components/visual-editor/index.js

Line 324 in 9b0f6aa

.is-root-container.alignfull:where(.is-layout-flow) > :not(.alignleft):not(.alignright) { max-width: none;}`;

As far as I can gather from the code comment on that rule, the expectation (from the editor's perspective) is that if the Content block has full width alignment set, that it's really full width.

Can you please confirm:

• If you're seeing the issue only when a Content block has full width alignment set?
• And if so, whether it's intended to use that alignment within the template?

I see that TT5 theme sets align to full within its single template here: https://github.com/WordPress/wordpress-develop/blob/309ecbd3241895522cd6d1eb0ef7f176dfceea94/src/wp-content/themes/twentytwentyfive/templates/single.html#L10 so I wondered if this is why we're running into the issue now, rather than something specifically regressing?

If it's that template that's causing the issue, there's potentially a couple of options:

• Update the template to remove align: full on the Content block (restructure that template a little so it isn't dependent on that alignment there), OR:
• Update the CSS rules for the post editor so that the .alignfull rules only apply when expected. I'm not too sure how to do this reliably, though, as I imagine the existing rules were there for a reason? We'd likely need to tease apart when they should and shouldn't apply 🤔

Hope that all made sense, I find it very tricky to write about this feature as it's quite nuanced and there's a fair bit of logic and existing decisions captured in the current state of the code. Let me know if there's anything else that needs digging into here!

[jasmussen]

Not sure what's up, but I see this consistently in Twenty Twenty-Five, in one of the alternate non-default templates optimized for photos. Here's the Single template:

Here's how the post editor looks:

As you can see, there's no semblance of WYSIWYG between the abstracted post editor and the actual with-template appearance.

Here's the single template markup:

<!-- wp:template-part {"slug":"header","theme":"twentytwentyfive","tagName":"header","area":"header"} /-->

<!-- wp:group {"tagName":"main","style":{"spacing":{"margin":{"top":"var:preset|spacing|60"}}},"layout":{"type":"constrained"}} -->
<main class="wp-block-group" style="margin-top:var(--wp--preset--spacing--60)"><!-- wp:group {"align":"wide","style":{"spacing":{"padding":{"top":"var:preset|spacing|60","bottom":"var:preset|spacing|60"}}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group alignwide" style="padding-top:var(--wp--preset--spacing--60);padding-bottom:var(--wp--preset--spacing--60)"><!-- wp:columns {"align":"wide","style":{"spacing":{"blockGap":{"left":"var:preset|spacing|60"}}}} -->
<div class="wp-block-columns alignwide"><!-- wp:column {"width":"60%"} -->
<div class="wp-block-column" style="flex-basis:60%"><!-- wp:post-title {"level":1} /--></div>
<!-- /wp:column -->

<!-- wp:column {"width":"40%"} -->
<div class="wp-block-column" style="flex-basis:40%"><!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap","justifyContent":"space-between","verticalAlignment":"top"}} -->
<div class="wp-block-group"><!-- wp:group {"style":{"spacing":{"blockGap":"var:preset|spacing|40"}},"layout":{"type":"flex","orientation":"vertical"}} -->
<div class="wp-block-group"><!-- wp:group {"style":{"spacing":{"blockGap":"var:preset|spacing|10"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">Published on</p>
<!-- /wp:paragraph -->

<!-- wp:post-date {"style":{"elements":{"link":{"color":{"text":"var:preset|color|contrast"}}}},"textColor":"contrast","fontSize":"small"} /--></div>
<!-- /wp:group -->

<!-- wp:group {"style":{"spacing":{"blockGap":"var:preset|spacing|10"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">Posted by</p>
<!-- /wp:paragraph -->

<!-- wp:post-author-name {"isLink":true,"fontSize":"small"} /--></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

<!-- wp:group {"style":{"spacing":{"blockGap":"var:preset|spacing|40"}},"layout":{"type":"flex","orientation":"vertical"}} -->
<div class="wp-block-group"><!-- wp:group {"style":{"spacing":{"blockGap":"0"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">Categories:</p>
<!-- /wp:paragraph -->

<!-- wp:post-terms {"term":"category","style":{"typography":{"fontStyle":"normal","fontWeight":"300"}}} /--></div>
<!-- /wp:group -->

<!-- wp:group {"style":{"spacing":{"blockGap":"0"}},"layout":{"type":"constrained"}} -->
<div class="wp-block-group"><!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">Tagged:</p>
<!-- /wp:paragraph -->

<!-- wp:post-terms {"term":"post_tag","style":{"typography":{"fontStyle":"normal","fontWeight":"300"}}} /--></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:group --></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->

<!-- wp:group {"align":"wide","style":{"spacing":{"margin":{"top":"var:preset|spacing|50","bottom":"0"}}},"layout":{"type":"default"}} -->
<div class="wp-block-group alignwide" style="margin-top:var(--wp--preset--spacing--50);margin-bottom:0"><!-- wp:group {"tagName":"nav","style":{"spacing":{"padding":{"top":"var:preset|spacing|40","bottom":"var:preset|spacing|40"},"margin":{"top":"0","bottom":"0"}}},"layout":{"type":"flex","flexWrap":"nowrap","justifyContent":"space-between"}} -->
<nav aria-label="Posts navigation" class="wp-block-group" style="margin-top:0;margin-bottom:0;padding-top:var(--wp--preset--spacing--40);padding-bottom:var(--wp--preset--spacing--40)"><!-- wp:post-navigation-link {"type":"previous","label":"Previous Photo","fontSize":"small"} /-->

<!-- wp:post-navigation-link {"label":"Next Photo","fontSize":"small"} /--></nav>
<!-- /wp:group --></div>
<!-- /wp:group -->

<!-- wp:post-featured-image {"aspectRatio":"auto","align":"wide"} /--></div>
<!-- /wp:group -->

<!-- wp:columns {"align":"wide"} -->
<div class="wp-block-columns alignwide"><!-- wp:column {"width":"66.66%"} -->
<div class="wp-block-column" style="flex-basis:66.66%"><!-- wp:post-content {"align":"full","layout":{"type":"default"}} /--></div>
<!-- /wp:column -->

<!-- wp:column {"width":"33.33%"} -->
<div class="wp-block-column" style="flex-basis:33.33%"></div>
<!-- /wp:column --></div>
<!-- /wp:columns --></main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","theme":"twentytwentyfive","tagName":"footer"} /-->

Let me know if I'm missing nuance!

[andrewserong]

Thanks for following up!

Not sure what's up, but I see this consistently in Twenty Twenty-Five, in one of the alternate non-default templates optimized for photos. Here's the Single template:

Ah, this took me a little while to find as I had to go to create a new template and then select a pattern in order to have access to this particular template. I can see it now.

I think a simple solution might be for us to avoid outputting the alignwide and alignfull classes in the abstracted post editors. Especially now that we have a template preview mode available, I think the addition of those alignment classes is confusing matters and appears to be what's resulting in styles being applied that aren't desirable in this case.

I'll open up a draft PR and we can give it a test and see what we think!

[andrewserong]

I've opened up a PR over in #66352 that tries a solution for this. It'll likely need a bit of wider feedback as the approach (and discussion) here is a little different to the feedback in #60311 which was sort of the opposite view to this issue. But it's a PR for us to play with — happy to either proceed with it or toss it out if there's a better way to handle things!

[jasmussen]

I'm tentatively closing this per the reasons given in this comment, essentially that what I was seeing was an edgecase that could/should be fixed separately. That PR may still be relevant to merge in case it addresses that edge-case, but this issue as originally reported was not entirely accurate. Thank you all for looking.