'p' tags visually bookend SyntaxHighlighter Code blocks in handbooks

[argumentum0]

The page at ​https://developer.wordpress.org/themes/advanced-topics/child-themes/ has formatting issues with code block below ​2. Create a stylesheet: style.css.

Perhaps because of this, the code examples are showing some weird </p><p> tags.

[coffee2code]

I fixed the general formatting issues with the code block by switching it from a Preformatted block to a SyntaxHighlighter Code block.

However, it appears every SyntaxHighlighter Code block on the page is afflicted with a literal </p> rendered at the start of the block and literal <p> rendered at the end of the block. I haven't looked into the cause of this yet. Doesn't seem to happen on other handbook pages that I spot-checked, nor for a plain Code block.

[Otto42]

#5149 was marked as a duplicate.

[theMikeD]

This is happening in the plugin handbook to. I can make the errant p tags go away by removing the shortcode block from the content, if that is any kind of clue.

Shows the issue:
​https://developer.wordpress.org/plugins/cron/scheduling-wp-cron-events/

[Otto42]

Okay, here's what I got so far:

In /themes/pub/wporg-developer/inc/head.php, on line 62:

$desc = apply_filters( 'the_content', $post->post_content, $post->ID );

If you comment out this line or change the post content to not be blocks, problem goes away. Obviously this is not desirable for the description.

Problem seems to be coming from core, somehow. When calling this, there is the do_blocks function in core. This function is supposed to check if the content has blocks, and turn off the wpautop function appropriately. It appears to do this, and adds the hook for the _restore_wpautop_hook function to re-enable afterwards.

This appears to work, in that the process goes off normally. However, then, for some reason I cannot work out, _restore_wpautop_hook gets called a second time. On this second run, this line:

$current_priority = has_filter( 'the_content', '_restore_wpautop_hook' );

Comes back false. There's no check for false here, since it doesn't make a lot of sense. So this line gets run:

add_filter( 'the_content', 'wpautop', $current_priority - 1 );

This then adds the wpautop filter with a -1 priority, which is lower than the normal do_blocks priority. So when the actual content runs on the page (not in the head), wpautop is enabled for it, and it is what is adding the errant P blocks.

I have no idea why _restore_wpautop_hook is running twice. Can't find it. But this is where the error lies.

cc @dd32

[Otto42]

It is worth noting that adding if ($current_priority === false) return $content; to _restore_wpautop_hook instantly fixes the problem, with no obvious side effects I can find.

[Otto42]

Possibly related: ​https://core.trac.wordpress.org/ticket/45495

cc @pento

[Otto42]

FYI, this was all triggered by this change:

https://meta.trac.wordpress.org/changeset/9715

The calling of the_content filter is new, however I can't see any reason for that to be wrong here.

[coffee2code]

Replying to Otto42:

Okay, here's what I got so far:

Nice track down.

In /themes/pub/wporg-developer/inc/head.php, on line 62:

$desc = apply_filters( 'the_content', $post->post_content, $post->ID );

If you comment out this line or change the post content to not be blocks, problem goes away. Obviously this is not desirable for the description.

This is basically just getting the filtered post content for use in the meta description tags in the page head. Definitely odd that it should have an impact on post content elsewhere. I guess if it comes down to it we could just derive the description from the raw post content.

[coffee2code]

In 9734:

Developer theme: Prevent errant p tags from appearing within SyntaxHighlighter Code blocks.

At present, applying 'the_content' filter on the raw post content in this manner affects the content's display later in the page via the_content(). For now, prevent triggering the issue (the root cause of which still exists, possibly with core).

Props Otto42, argumentum0.
Fixes #5148.

[coffee2code]

Since people are noticing, I've gone ahead and just used the raw post content as the basis for the meta description tags. Anyone with access can restore the original code on their sandbox to reproduce the issue for debugging.