WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#45401 closed defect (bug) (fixed)

Dynamic blocks not working when added after a page break block.

Reported by: youknowriad Owned by:
Milestone: 5.0 Priority: normal
Severity: normal Version: 5.0
Component: Editor Keywords: needs-unit-tests
Focuses: Cc:

Description

Related Gutenberg Ticket https://github.com/WordPress/gutenberg/issues/12218

Use this HTML in your post

<!-- wp:heading -->
<h2>Test</h2>
<!-- /wp:heading -->

<!-- wp:nextpage -->
<!--nextpage-->
<!-- /wp:nextpage -->

<!-- wp:quote -->
<blockquote class="wp-block-quote"><p>TEST</p><cite>ETSTTSTT</cite></blockquote>
<!-- /wp:quote -->

<!-- wp:latest-posts /-->

And notice that the latest posts block is not showing up in the second page.

The reason is simple, the string passed to do_blocks is a string starting with <!-- /wp:nextpage --> which means the content is not parsed properly by the gutenberg parser.

Attachments (2)

pagination.patch (577 bytes) - added by youknowriad 2 years ago.
45401.diff (796 bytes) - added by pento 2 years ago.

Download all attachments as: .zip

Change History (16)

#1 @youknowriad
2 years ago

The patch above is a simple and safe fix for this. A more complex fix could be achieved in the parser itself, but I think we should go with the safest approach for now.

This ticket was mentioned in Slack in #core-editor by matias. View the logs.


2 years ago

#3 @azaozz
2 years ago

How about:

$content = ltrim( $content, '<!-- /wp:nextpage -->' );
$content = rtrim( $content, '<!-- wp:nextpage -->' );

to catch cases of "left over" block boundaries when there are more than two pages :)

Version 1, edited 2 years ago by azaozz (previous) (next) (diff)

#4 @azaozz
2 years ago

Also, the trimming will probably be better to run on the 'content_pagination' filter, here: https://core.trac.wordpress.org/browser/branches/5.0/src/wp-includes/class-wp-query.php#L4013.

@pento
2 years ago

#5 @pento
2 years ago

45401.diff implements the block marker removal in WP_Query::setup_postdata(), where all of the other nextpage handling happens.

I don't think we need to run it on the content_pagination filter, inline keeps all of the relevant code in one place.

#6 @noisysocks
2 years ago

45401.diff works well in my testing. I tested:

  • That the bug as described in the ticket description is fixed
  • That multi-page posts work when published
  • That multi-page posts work when previewed
  • That page breaks at the start of a post are ignored
  • That having two page breaks next to each other creates a blank page

#7 @azaozz
2 years ago

Work well here too. To add to the list by @noisysocks:

  • Empty lines left over after removing the block delimiters don't seem to affect anything.

#8 @pento
2 years ago

In 43940:

Query: Remove nextpage block delimiters when setting up global post data.

WP_Query::setup_postdata() splits the post up by <!--nextpage-->, which causes invalid block data to be contained in the post content.

This change removes the <!-- wp:nextpage --> and <!-- /wp:nextpage -->, as well.

Props pento, youknowriad, azaozz, noisysocks.
See #45401.

#9 @pento
2 years ago

  • Keywords fixed-5.0 added

#10 @ocean90
2 years ago

Is there a unit test somewhere to verify that [43940] is working correctly?

#11 @SergeyBiryukov
2 years ago

  • Component changed from General to Editor
  • Summary changed from Dynamic blocs not working when added after a page break block. to Dynamic blocks not working when added after a page break block.

#12 @desrosj
2 years ago

In 44276:

Query: Remove nextpage block delimiters when setting up global post data.

WP_Query::setup_postdata() splits the post up by <!--nextpage-->, which causes invalid block data to be contained in the post content.

This change removes the <!-- wp:nextpage --> and <!-- /wp:nextpage -->, as well.

Props pento, youknowriad, azaozz, noisysocks.

Merges [43940] into trunk.

See #45401.

#13 @desrosj
2 years ago

  • Keywords needs-unit-tests added; fixed-5.0 removed

#14 @SergeyBiryukov
2 years ago

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

A new ticket can be created for unit tests. Let's close this one, as the milestone is now completed.

Note: See TracTickets for help on using tickets.