Frontend of block theme does not render as expected

[ironprogrammer]

Instead of displaying a block theme's frontend like that represented in the backend editor, posts are displayed in a <ul> block. Also, the site navigation appears broken.

Confirmed this behavior with TT3, TT2, and Blockbase. (Unable to repro with classic themes like TT1 and TT.) Note that activating Gutenberg (tested with trunk) results in resolving this issue.

Testing Instructions

These steps define how to reproduce the issue, and indicate the expected behavior.

Steps to Reproduce

1. From wordpress-develop:trunk, run npm run build.
2. Copy the build/ folder to a new location, and set it up as a new site.
3. After configuring the site, add a few test posts.
4. With TT3 active (should be by default), load the site frontend, and observe that posts are displayed in a list, rather than columns.
5. Try testing with other block themes.

Expected Results

When testing a patch to validate it works as expected:

• The frontend of the site should render like that represented in the backend editor.

When reproducing a bug:

• The frontend of the site renders with posts in a list, and site navigation broken.

Supplemental Artifacts

Backend Editor	Frontend

(Here is an example of the TT theme that does not have this issue: ​https://cldup.com/FH9pnSZ78F.png.)

[petitphp]

Reproduction Report

This report validates that the issue can be reproduced.

Environment

• OS: macOS 13.2.1
• Web Server: Nginx
• PHP: 7.4.30
• WordPress: 6.2-beta5-55481-src
• Browser: Firefox 111b7
• Theme: Twenty Twenty-Three
• Active Plugins: None

Actual Results

• Error condition occurs (reproduced).
• Also confirm that activating the Gutenberg plugin fix the issue.

Additional Notes

• I was able to reproduce the issue by fetching the last changes from trunk, building the assets (npm run build:dev) and starting a local docker env via npm run install/start

[petitphp]

Using add_filter( 'should_load_separate_core_block_assets', '__return_false' ); to force WordPress to load the style for all block fix the issue.

It might be that WordPress is not picking up which blocks are used in the page and thus not loading the associated styles or the styles are not inline in the HTML.

Seem to be related to [55484] which cause the compiled assets to be deleted just after being created by webpack during the build process.

In Gruntfile.js, removing the path 'wp-includes/blocks/**/*.css' from the cssFiles array and running a npm run build:dev fix the issue on my local environment.

[hellofromTonya]

Assigning to @azaozz.

The plan:

• @ironprogrammer @azaozz are currently discussing to find a quick fix before RC1.
• Else, the [55484] will be reverted before RC1.

[azaozz]

Confirmed. Happens because the .css files in wp-includes/blocks/ are cleaned together with the other CSS files, but are built earlier by Webpack.

[azaozz]

In 57891.diff move cleaning of the old CSS files from wp-includes/blocks/ to earlier, before (re)building them with Webpack.

[ironprogrammer]

Thank you for looking into this, @petitphp, and for the quick patch turnaround, @azaozz!

Test Report

Patch tested: attachment:57891.diff​

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 12.6.3
• Browser: Safari 16.3
• Server: nginx/1.23.3
• PHP: 7.4.33
• WordPress: 6.2-beta5-55481-src (trunk in src/), 6.2-beta5-20230308.154340 (output of build/ folder)
• Theme: twentytwentythree v1.1, twentytwentytwo v1.4

Actual Results

• Frontend of block theme renders as expected.
• Regression check for #47749 (same results).

[azaozz]

In 55494:

Build/Test Tools: Fix cleaning of old CSS files in wp-includes/blocks/*. Have to be cleaned earlier, before Webpack runs. Not together with the rest of the CSS files.

Props: ironprogrammer, petitphp, hellofromTonya, azaozz.
Fixes: #57891.