Post Content block in post template always appears full width in site editor.

[iamtakashi]

Description

The post content block inside a post template always appears full width in the site editor.

Let's say, you want to show the full content, not just excerpts of posts in the archive template.

This is the markup to test the scenario.

<!-- wp:query {"queryId":7,"query":{"perPage":5,"pages":0,"offset":0,"postType":"post","order":"desc","orderBy":"date","author":"","search":"","exclude":[],"sticky":"","inherit":true}} -->
<div class="wp-block-query">
	<!-- wp:post-template -->
		<!-- wp:post-title {"textAlign":"center"} /-->

		<!-- wp:post-content {"layout":{"type":"constrained"}} /-->
	<!-- /wp:post-template -->
</div>
<!-- /wp:query -->

Notice the post content's layout is set to constrained, but all the content is stretched out in the site editor.

Toggling the layout option doesn't make a difference, which I believe is the issue.

The front of the site shows what I expected.

I used Twnety Twenty-three theme, but this isn't a theme-specific issue. I didn't think this was expected, and I couldn't find a report describing this issue, but I apologise if this is a known issue!

Step-by-step reproduction instructions

1. Go to the site editor.
2. Paste the markup above or edit a template with a query loop and a post template. Choose the list view for the post template.
3. Add a content block in the post template. Make sure it's set to constrained.
4. Notice the fully stretched content.

Screenshots, screen recording, code snippet

No response

Environment info

• WP 6.3
• Gutenberg trunk
• Twenty Twenty-three
• Chrome Mac

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Ren2049]

I guess the post content block is only visually part of the template within the editor and technically the main inner block of of the actual page. Meaning that it only indicates the applied color within the editor to let users know. Maybe the devs could remove this color option and create another toggle for inner content color, would be more consistent.

[tellthemachines]

Thanks for reporting this! I can confirm that the Content block inside a Post Template doesn't have any layout classnames applied in the editor. Looking into it.

[tellthemachines]

Looks like the value of css is false here, though that seems to happen for other blocks too.

[andrewserong]

Looks like the value of css is false here, though that seems to happen for other blocks too.

I think it should be fine that css is empty if there aren't any custom layout attributes set for the particular post content block. From a bit of console.loging, I can see that the layout classnames are being correctly output by withLayoutStyles and then are being passed down to the post content block. I think the problem could be that we're handling the layout classnames by passing them to the block's Placeholder state, but not to the Content state on this line (I see layout is passed down, but I'm not sure if it's being used by anything):

gutenberg/packages/block-library/src/post-content/edit.js

Line 150 in fbc67a1

<Content context={ context } layout={ layout } />

I'll have a hack around and see where we can add the layout classnames in, if no-one beats me to it!

[andrewserong]

I have a draft PR up over in #53864 — I think it's mostly working, but I've run out of time for today. I'll do some more manual testing tomorrow to make sure I haven't missed anything or accidentally introduced any regressions, and then will get it ready for review!

[Tropicalista]

I don't know if it's related, however custom post type now always have layout flow class applied. Check here for details.

[andrewserong]

#53864 appears to be working pretty well to fix this bug, so I've switched it over to ready for review.

I don't know if it's related, however custom post type now always have layout flow class applied. Check #53885 for details.

Thanks for raising that one! While similar, I believe it's a different bug so will require a separate fix.