Paginated content

[Rahe]

Describe the bug
When I have a dynamic bloc with a render_callback function and a paginated content (<--nextpage-->) the dynamic block are not rendered.

To Reproduce
Steps to reproduce the behavior:

1. Go in admin
2. Add an content
3. Add content :

<!-- 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 /-->

4. Go to front office, load the page 2

Expected behavior
I expect that the dynamic block is rendered on page 2, but this is not the case.

Desktop (please complete the following information):

• OS: MACOS
• Browser Chrome
• Version 70.0.3538.77

Additional context

• Version 4.5.1, but appears since 4.4.0 works fine in 4.3.0

[youknowriad]

I suspect this being a parsing issue where the parsed string passed to do_blocks or something is starting with <!-- /wp:nextpage --> causing the issue.

cc @dmsnell @pento

Maybe we should just trim <!-- wp:nextpage --> and <!-- /wp:nextpage --> from the strings?

[swissspidy]

Introduced in #1467. There were some discussions about changing the parser so these blocks would always be saved as <!--nextpage--> without <!-- wp:nextpage --> and <!-- /wp:nextpage -->, but that was reverted again.

[dmsnell]

If you plug in the example content into the parser explorer (you can load the spec grammar by clicking on "fetch") then you will see that it does what it's supposed to do and parse the document into a list of blocks.

(I had originally asked for follow-up information from @Rahe but since I believe I have found the more specific problem - "blocks aren't processed on non-first pages" - then I removed the request)

my guess is that we have some different code path for following pages in multi-page documents that skips the block processing altogether. @aduth I'm not sure who to ping but I think we only run content through do_blocks on the first page of a multi-page document.

check out the rendered HTML for page two of my test document…

I'm not sure where even to begin, but I can try and look into this. seems like a critical priority. cc: @mtias

[dmsnell]

Update

It seems like my assessment was wrong about not processing the successive pages. Instead, what's happening is that we're sending an invalid document to do_blocks() and that fails in the default parser in a different way than the spec parser.

Once WordPress strips out <!--nexpage--> it passes a document to do_blocks() that starts with <!-- /wp:nextpage --> which is invalid. The default parser fails and closes out the rest of the document.

I'll try and make at least one attempt at a quick-and-minimal fix from inside do_blocks(), but we know that the real fix is to update the default parser so that it's actually a PEG and conforms to the same failure modes as the spec parser.

[mcsf]

Once WordPress strips out <!--nexpage--> it passes a document to do_blocks() that starts with <!-- /wp:nextpage --> which is invalid. The default parser fails and closes out the rest of the document.

Was starting to look at this and getting at the same conclusion. Looking forward for a quick patch. <3

[azaozz]

Once WordPress strips out it passes a document to do_blocks() that starts with which is invalid. The default parser fails and closes out the rest of the document.

Heh, got there too few min ago... Parallel work :)

A very crude fix is

	
	if ( strpos( $content, '<!-- /wp:nextpage -->' ) === 0 ) {
		$content = preg_replace( '@^<!-- /wp:nextpage -->\s*@', '', $content );
	}

	if ( strrpos( $content, '<!-- wp:nextpage -->' ) === strlen( $content  ) - 20 ) {
		$content = preg_replace( '@\s*<!-- wp:nextpage -->$@', '', $content );
	}

in do_blocks() before $blocks = parse_blocks( $content );.

[mtias]

Cross-referencing ticket in core trac: https://core.trac.wordpress.org/ticket/45401

[youknowriad]

I'm closing as this has been fixed upstream