WordPress.org

Making WordPress.org

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#5148 closed defect (fixed)

'p' tags visually bookend SyntaxHighlighter Code blocks in handbooks

Reported by: argumentum0 Owned by: coffee2code
Milestone: Priority: normal
Component: Developer Hub Keywords:
Cc:

Description

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.

Change History (13)

#1 @coffee2code
3 months ago

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.

This ticket was mentioned in Slack in #meta by otto42. View the logs.


3 months ago

#3 @Otto42
3 months ago

#5149 was marked as a duplicate.

#4 @theMikeD
3 months ago

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/

Last edited 3 months ago by theMikeD (previous) (diff)

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


3 months ago

#6 follow-up: @Otto42
3 months ago

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

#7 @Otto42
3 months ago

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.

#9 @Otto42
3 months ago

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.

#10 in reply to: ↑ 6 @coffee2code
3 months ago

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.

#11 @coffee2code
3 months ago

  • Component changed from Handbooks to Developer Hub
  • Summary changed from Theme Handbook: formatting issues on Child Themes page to 'p' tags visually bookend SyntaxHighlighter Code blocks in handbooks

#12 @coffee2code
3 months ago

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

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.

#13 @coffee2code
3 months ago

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.

Note: See TracTickets for help on using tickets.