#5148 closed defect (bug) (fixed)
'p' tags visually bookend SyntaxHighlighter Code blocks in handbooks
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
This ticket was mentioned in Slack in #meta by otto42. View the logs.
5 years ago
#4
@
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/
This ticket was mentioned in Slack in #core-editor by themiked. View the logs.
5 years ago
#6
follow-up:
↓ 10
@
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
@
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.
#8
@
5 years ago
Possibly related: https://core.trac.wordpress.org/ticket/45495
cc @pento
#9
@
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
@
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
@
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
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.