Make WordPress Core

Opened 13 months ago

Closed 7 months ago

#58027 closed defect (bug) (fixed)

Post Content / Post Featured Image blocks break content if added before the loop

Reported by: edge22's profile edge22 Owned by: flixos90's profile flixos90
Milestone: 6.4 Priority: normal
Severity: normal Version: 5.8
Component: Editor Keywords: has-testing-info has-patch gutenberg-merge
Focuses: Cc:

Description (last modified by ironprogrammer)

Since 6.2, any "classic" theme that hooks the core "Post Featured Image" block before the loop causes the content within the loop to disappear.

To replicate:

  1. Use a "classic" theme like Twenty Twenty-One.
  2. Hook the Post Featured Image block into the theme before the loop begins:
<?php
add_action( 'wp_body_open', function() {
        $block_content = '<!-- wp:post-featured-image /-->';
        $block = parse_blocks($block_content)[0];
        echo render_block($block);
} );
  1. View a single post.

The content will be gone.

This is an issue if any theme is allowing users to insert this block as a page hero before the loop begins.

This is the PR that introduced the error: https://github.com/WordPress/gutenberg/pull/45534

Change History (18)

#1 @flixos90
13 months ago

  • Summary changed from Post Featured Image block breaks content if added before the loop to Post Content / Post Featured Image blocks break content if added before the loop
  • Version changed from 6.2 to 5.8

@edge22 I can reproduce this issue. I am curious however, how did you ran into it? My first hunch would be to consider this an edge-case, since why would you use a block intended for FSE / block themes in a classic theme? I would like to understand in which legitimate use-case would be affected by this bug.

I also would like to add that this bug is not actually new. While the logic was added to the post-featured-image block in 6.2, it was directly taken over from the same code being in the post-content block. If you put the same code from your snippet but with the post-content block, you'll see the same problem occur. While I would love to understand better where this realistically is a problem, I certainly agree that that logic feels clunky, and I am not sure why it's there.

The logic (i.e. also the bug) has been in that block since it was originally added in WordPress 5.8 (introduced as part of [50929] and [51344]). Digging further, it looks like the original logic was introduced in https://github.com/WordPress/gutenberg/pull/30405. Acknowledging that this was added almost 2 years ago, @aristath @ntsekouras do you have any memory on why enforcing a loop was added in the core/post-content block? Shouldn't we rather make sure, outside of that block, that it is used within a loop?

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

#2 @ntsekouras
13 months ago

That's a tough one since what takes effect here is the combination of post content and post featured image, which also calls the_post: https://github.com/WordPress/gutenberg/pull/45534

The reason is the same for both, as some places in code check if they are in the loop and this is bad to start with. Ideally templates/blocks shouldn't rely on the loop(that goes for post content) and maybe there could be another way to handle lazy loading of images?

I'm not sure how we could find plugins or blocks that rely on the loop and start a deprecation process.. Normally using block context could make the trick, but I'm not sure of the nuances of every use case. Recently there was a related discussion here: https://github.com/woocommerce/woocommerce-blocks/discussions/8792.

Backwards compatibility is tough.

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


12 months ago

#4 @ironprogrammer
12 months ago

  • Description modified (diff)
  • Keywords has-testing-info added

Updated "classic" theme referenced in reproduction step 1 to TT1 (TT2 is a block theme).

#5 @ironprogrammer
12 months ago

Reproduction Report

I was also able to reproduce this in TT1 and TT.

Environment

  • Hardware: MacBook Pro Apple M1 Pro
  • OS: macOS 12.6.3
  • Browser: Safari 16.3
  • Server: nginx/1.23.4
  • PHP: 7.4.33
  • WordPress: 6.2
  • Theme: twentytwentyone, twentytwenty
  • Active Plugins:
    • body-open (custom mu-plugin that hooks wp_body_open as indicated in repro steps)

Actual Results

  • ✅ Post content on single post page is not output.

Additional Information

  • As noted in comment:1, I could also repro this issue using a post-content block (tested in WP 6.1.1).

This ticket was mentioned in Slack in #core-test by oglekler. View the logs.


12 months ago

#7 @annashopina
12 months ago

#58111 was marked as a duplicate.

#8 @annashopina
12 months ago

The task was linked with https://core.trac.wordpress.org/ticket/58111#comment:4 for future investigation. Looks like they are duplicated.

#9 @flixos90
12 months ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 6.3
  • Owner set to flixos90
  • Status changed from new to assigned

I have identified a more appropriate solution for the underlying problem here, which basically was a workaround for a problem identified in #58154.

In order to fix the problem, we'll need to:

  1. Merge this Gutenberg PR https://github.com/WordPress/gutenberg/pull/49904
  2. Port it over to WordPress core
  3. Merge this core PR https://github.com/WordPress/wordpress-develop/pull/4341

@hellofromTonya Flagging this ticket as it will require a Gutenberg fix to be ported over to WordPress core in order to get fixed.

#10 @ugyensupport
12 months ago

Same here would able to reproduce in TT1 and TT.

#11 @flixos90
10 months ago

  • Milestone changed from 6.3 to 6.4

Unfortunately there is no consensus on this yet, and as the Gutenberg PR https://github.com/WordPress/gutenberg/pull/49904 hasn't been merged, this has to be punted.

#12 @hellofromTonya
9 months ago

  • Keywords gutenberg-merge added

As this ticket is dependent upon code from Gutenberg being merged into Core, adding the gutenberg-merge keyword for tracking purposes.

#13 @flixos90
8 months ago

After some additional digging, which led to discovery of a more severe underlying problem (see #59225), the Gutenberg PR https://github.com/WordPress/gutenberg/pull/49904 has been updated with a detailed description. Once that is merged and backported to WP core, this bug here will be fixed.

This ticket was mentioned in Slack in #core-performance by flixos90. View the logs.


8 months ago

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


8 months ago

#16 @flixos90
8 months ago

For reference, the bug reported in https://github.com/WordPress/gutenberg/issues/53593 is happening for the same reason as this one. cc @gziolo

On another note, the Gutenberg PR https://github.com/WordPress/gutenberg/pull/49904 has been merged. Next steps are:

  • Commit the PR for #58154
  • Port the above Gutenberg update into core

#17 @flixos90
7 months ago

In 56507:

Editor: Ensure main query loop is entered for singular content in block themes.

Block themes currently lack the means to trigger the main query loop for singular content, since they cannot reasonably use the core/query and core/post-template blocks which are intended only for displaying a list of posts. So far, the missing main query loop on singular block templates has been worked around by enforcing the loop in certain core/post-* blocks, which however causes other bugs.

This changeset ensures that the main query loop is still started for singular block theme templates, by wrapping the entire template into the loop, which will by definition only have a single cycle as it only encompasses a single post. This is currently the most reliable solution, since even if there were blocks to properly trigger the main query loop on singular content, it would be unrealistic to expect all existing block themes to update their templates accordingly. It may be revisited in the future.

Props gziolo, youknowriad, joemcgill, costdev, mukesh27, flixos90.
Fixes #58154.
See #59225, #58027.

#18 @flixos90
7 months ago

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

This bug should be fixed as of [56710], specifically through the changes in src/wp-includes/blocks/post-featured-image.php.

When testing with the 6.4 Beta 1, which is out later today, the bug should no longer occur.

Note: See TracTickets for help on using tickets.