Making WordPress.org

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#5148 closed defect (bug) (fixed)

'p' tags visually bookend SyntaxHighlighter Code blocks in handbooks

Reported by: argumentum0's profile argumentum0 Owned by: coffee2code's profile 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
5 years 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.


5 years ago

#3 @Otto42
5 years ago

#5149 was marked as a duplicate.

#4 @theMikeD
5 years 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 5 years ago by theMikeD (previous) (diff)

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


5 years ago

#6 follow-up: @Otto42
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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
5 years 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.