Styles for the .wp-container-uniqueID are loaded in the incorrect order or not loaded at all in 5.9.1 - 5.9.2

[carolinan]

Description

Since Gutenberg 12.7, if you use do_blocks() to render a block, the CSS normally placed in a style tag for the wp-container-uniqueID inline in the document is missing. Such as the flex, margins, widths and alignments.

I have received multiple reports and support requests about this causing problems with missing styles for universal and hybrid themes.

Step-by-step reproduction instructions

1. Use do_blocks() (in a front facing template file) to render a block with a layout setting like a group or template part.
2. Confirm that the CSS is missing on the front.

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 5.9.1
Gutenberg 12.7.

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

[carolinan]

WordPress 5.9.0 without Gutenberg: Styles are included
WordPress 5.9.0 with Gutenberg 12.6: Styles are included
WordPress 5.9.0 with Gutenberg 12.7: Styles are not included

WordPress 5.9.1 without Gutenberg: Styles are not included
WordPress 5.9.1 with Gutenberg 12.6: Styles are included
WordPress 5.9.1 with Gutenberg 12.7: Styles are not included

[Mamaduka]

Pinging @oandregal. This might be related to #38750 which was backported into minor release.

[Mamaduka]

Another issue reported #39217.

[carolinan]

I was about to open a separate issue, but I think they are the same or very closely related, so I will add the details here:

---

On WordPress 5.9.2, with a block theme active, when Gutenberg is not active, the post template block is left aligned on the front, but correctly positioned in the editor.

When Gutenberg is active, the block is positioned correctly.
When WordPress 5.9.0 is used, the block is positioned correctly.

To test with Empty theme:

1. Open the Index template in the Site Editor
2. Select the Query loop block. Enable "Inherit default layout"
3. See that the post template block is moved to the center of the template:
   
4. Save and view the front.
5. Confirm that the post block is left aligned on the front:
   

To test with Twenty Twenty-Two:

1. Open the Home template in the Site editor
2. Select the Post template block
3. Change the alignment to none. See that the post template block is moved to a centered position on the template:
   
4. Save and view the front. See that the post template is left aligned on the front
   

In 5.9.2, without Gutenberg active:

.wp-block-post-template.wp-block-post-template, .wp-block-query-loop.wp-block-post-template {
    background: none;
}

.wp-block-post-template, .wp-block-query-loop {
    margin-top: 0;
    margin-bottom: 0;
    max-width: 100%;
    list-style: none;
    padding: 0;
}
.wp-container-623189d9cb0cb > * {
    margin-top: 0; //comment: this is overwritten by the style above
    margin-bottom: 0; //comment: this is overwritten
}
.wp-container-623189d9cb0cb > * {
    max-width: 840px; //comment: this is overwrittenby the style above
    margin-left: auto !important;
    margin-right: auto !important;
}

In 5.9.2, with Gutenberg active:

.wp-block-post-template.wp-block-post-template, .wp-block-query-loop.wp-block-post-template {
    background: none;
}

.wp-container-8 > * {
    margin-top: 0;
    margin-bottom: 0;
}
.wp-container-8 > :where(:not(.alignleft):not(.alignright)) {
    max-width: 840px;
    margin-left: auto !important;
    margin-right: auto !important;
}
.wp-block-post-template, .wp-block-query-loop {
    list-style: none;
    margin-bottom: 0;
    margin-top: 0;
    max-width: 100%;
    padding: 0;
}

In WordPress 5.9.0 without Gutenberg active:

.wp-container-623187f8990d5 > * {
    margin-top: 0;
    margin-bottom: 0;
}

.wp-container-623187f8990d5 > * {
    max-width: 840px;
    margin-left: auto !important;
    margin-right: auto !important;
}
.wp-block-post-template, .wp-block-query-loop {
    margin-top: 0;
    margin-bottom: 0;
    max-width: 100%;
    list-style: none;
    padding: 0;
}

[carolinan]

@oandregal @youknowriad Hi, do you think this is something we can locate and fix before 6.0? 🙏
For end users who are using block themes this can potentially break their existing homepage / blog index because of the misalignment of the post template.
I know it has a small impact in the grand scheme of things, it is also troublesome for block theme authors who needs to work around these issues with (hopefully) temporary solutions.

[youknowriad]

Is this related to this one? #39164 Is it because these themes are missing wp_head() on their header?

[carolinan]

If I add a PHP template to a block theme and then use do_blocks(), I also use wp_head().

I believe it would be an earlier change since it works in 5.9.0 but not 5.9.1.

[youknowriad]

I think it's related to this #38750 (which is the first step of #39164 ).

The problem is that it used to work in 5.9 but just "by luck" basically, because wp_footer is called after do_blocks but do_blocks was never inlining these styles in the first place.

I think reverting is not the right solution though because the bug fixed by those PRs could be seen as even more important.

Maybe the right approach here is to offer a function that returns both template and styles somehow wrapping do_blocks . It's not going to be an easy fix though. I know @andrewserong also explored a similar bug in the REST API (headless use-case) where the styles are not part of the endpoint result as well.

[carolinan]

Is the comment about the loading order related or should I move it to a separate issue after all?

[youknowriad]

I think that comment is what was solved by #39164 if I'm not wrong. (and it's marked for backport to next minor if there's any)

Edit: corrected the link

[MoOx]

This commit gMagicScott/core.wordpress-mirror@f481d34 seems indeed to fix it.
Using 5.9.3-RC1 helps.

[carolinan]

Using do_blocks() still does not print the .wp-container-uniqueID CSS for the blocks.

[bradfrumos]

A workaround to get the block support styles printed in the <head> seems to be to assign all your do_blocks() to variables before calling wp_head() and then print those variables where you need them.

<?php
  $header = do_blocks('<!-- wp:template-part {"slug":"header","theme":"themeName"} /-->');
  $footer = do_blocks('<!-- wp:template-part {"slug":"footer","theme":"themeName"} /-->');
?>
<head>
  <?php wp_head(); ?>
</head>
<body>
  <?php echo $header; ?>
  <?php echo $footer; ?>
</body>

[youknowriad]

I think the best solution would be to have a function that returns the output of blocks (style, JS and HTML) without relying on hooks. (wp_head or wp_footer). I think we discussed something similar related to the style engine work. cc @andrewserong @ramonjd and others.

Basically we need the APIs to render blocks to avoid relying on this hooks to be flexible enough. Right now rendering blocks has strong assumptions about the themes as a context. In other words do_blocks is not a function you case use in any context.

This probably deserves its own issue I think.

[illycz]

Any news about that? I'm trying to use virtual page template within block theme and render header and footer within do_blocks().

Layout styles not loaded and inline blocks styles rendered before body so there is a specificity problem within custom styles which overrides blocks styles within standard block theme.

Thanks

[carolinan]

The new issue is here:
#40018
I have not tested yet but in theory, the solution @bradfrumos posted should work.

[illycz]

I have not tested yet but in theory, the solution @bradfrumos posted should work.

Yes, solution from @bradfrumos working.

Thanks

[Bijingus]

The inline styling for blocks is also missing when you get content with an AJAX request. I've been trying to figure out a solution to this for hours with no luck. I can't for the life of me find where the unique block styles/classes like .wp-container-uniqueID are coming from.

[ramonjd]

The inline styling for blocks is also missing when you get content with an AJAX request.

Hi @Bijingus

If I'm understanding things correctly, this is a known issue. @andrewserong spent some time trying to work out a fix too.

I think these PRs are related:

• Block Supports: Refactor styles rendering to utility function and add to REST API responses #35450
• Post Content: Layout styles not applied in editor (e.g. Social Icons, Buttons, etc.) #35376
• Alignment & spacing is not passed to the frontend preview pattern-directory#416

I can't for the life of me find where the unique block styles/classes like .wp-container-uniqueID are coming from.

A lot of them are being applied by the layout implementation in layout.php, but the REST API does not include them.