Make WordPress Core

#57891 closed defect (bug) (fixed)

Frontend of block theme does not render as expected

Reported by: ironprogrammer's profile ironprogrammer Owned by: azaozz's profile azaozz
Milestone: 6.2 Priority: normal
Severity: major Version: 6.2
Component: Themes Keywords: has-screenshots has-testing-info has-patch
Focuses: Cc:

Description (last modified by azaozz)

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
https://cldup.com/0LC1ninezr.png https://cldup.com/ckIBM-jyZw.png

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

Attachments (1)

57891.diff (558 bytes) - added by azaozz 13 months ago.

Download all attachments as: .zip

Change History (12)

#1 @ironprogrammer
13 months ago

  • Description modified (diff)
  • Severity changed from normal to major

This ticket was mentioned in Slack in #core by ironprogrammer. View the logs.


13 months ago

#3 @ironprogrammer
13 months ago

  • Description modified (diff)

#4 @petitphp
13 months ago

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
Last edited 13 months ago by petitphp (previous) (diff)

#5 @petitphp
13 months ago

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.

Last edited 13 months ago by petitphp (previous) (diff)

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


13 months ago

#7 @hellofromTonya
13 months ago

  • Milestone changed from Awaiting Review to 6.2
  • Owner set to azaozz
  • Status changed from new to assigned

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.

#8 @azaozz
13 months ago

  • Description modified (diff)

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
13 months ago

#9 @azaozz
13 months ago

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

#10 @ironprogrammer
13 months ago

  • Keywords has-patch added

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).
Last edited 13 months ago by ironprogrammer (previous) (diff)

#11 @azaozz
13 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.