HR destroys HTML

[thomask]

if you add <hr /> to the post (via HTML editor, or via enhanced TinyMCE editor) followed by normal text id do not add the <p> for that paragraph, but add the finishing </p>

so it than looks like

<p>some text</p>
<hr>some other text</p>

it can be solved by adding extra line break after <hr> but after reediting the post, the linebreak disapears and must be added again.

[solarissmoke]

HR's are a special case of block level element because they self-close

[solarissmoke]

I think the problem was the wpautop was expecting to find a closing tag for the hr element, like it does with all other block-level elements. This patch fixes it for me but needs testing to be sure it doesn't break anything else.

[solarissmoke]

Refreshed

[MikeHansenMe]

not sure why I asked for refresh. This problem seems to be fixed in the current version 3.5-alpha-21751. Proposing we close the ticket.

[SergeyBiryukov]

I can still reproduce in trunk.

1. Copy this into Text editor:

   <p>some text</p> <hr />some other text
   

2. Preview the post.
3. View HTML source of the page:

   <p>some text</p>
   <hr />some other text</p>
   

[chriscct7]

Replying to SergeyBiryukov:

I can still reproduce in trunk.

1. Copy this into Text editor:

   <p>some text</p> <hr />some other text
   

2. Preview the post.
3. View HTML source of the page:

   <p>some text</p>
   <hr />some other text</p>
   

This now works on 4.2. Closing as works for me.

[SergeyBiryukov]

I can still reproduce comment:7 in 4.2 exactly as described.

[chriscct7]

This is wierd. I think I know why me and @MikeHansonMe can't replicate this.

Depending on the browser used, the browsers try to fix the error I think.

This is what I get in Chrome:

<p>some text</p>
<hr>some other text<p></p>

but this is what I get in FireFox:

<p>some text</p>
<hr></hr>some other text<p></p>

What browser are you using?

[SergeyBiryukov]

Firefox 37.0.2.

Make sure to actually view the page source, not via Inspect Element. I think both Firebug and Chrome Developer Tools try to normalize invalid HTML.

[chriscct7]

Replying to SergeyBiryukov:

Firefox 37.0.2.

Make sure to actually view the page source, not via Inspect Element. I think both Firebug and Chrome Developer Tools try to normalize invalid HTML.

Ah I see now. Yep, that needs to be fixed.

Tagging patch as needs testing.

[MattyRob]

The current patch doesn't take into account the HTML <hr> tag as well XHTML <hr /> tag. Updated patch takes this into account using a preg_replace() call and also demonstrates using two consecutive str_replace calls (I'm not sure which will be faster).

In my testing it works fine. (Mac OS Browser as follows Safari 9.1.2, FF 48.0 and Chrome 58)

[MattyRob]

I coincidently found that the above patch (14674.3.diff) fails PHPUnit tests but I believe that this is because the unit tests are not accurate.

The test fails expecting <hr>foo</hr> but getting <hr>\n<p>foo</hr> however there should not be any content within <hr> tags as it's self closing.

Can the <hr> test simply be removed from the unit tests?

[dd32]

Can the <hr> test simply be removed from the unit tests?

If the test is wrong, yes. If possible, it should be ensured another unit test shows the expected behaviour.

[MattyRob]

@dd32

Update patch attached for the unit tests. Needs another set of eyes though as this is my first ever PHPUnit test! The test is passing but is it a valid test?

[pento]

14674.6.diff​ Refreshes the patch to apply cleanly, and tweaks the behaviour to account for changes in how wpautop() behaves since this ticket was last active.

[pento]

In 45574:

Formatting: Add correct <p> tags near <hr> tags.

It can be tricky to know when wpautop() should add <p> tags, but one thing we can be certain about is that they really shouldn't be anywhere near <hr> tags.

Now they aren't.

Props solarissmoke, MattyRob, pento.
Fixes #14674.

[pento]

#28762 was marked as a duplicate.