wpautop() breaks inline tags on the same line as block tags

[retrib]

Hi guys! I've got latest WP installation (3.0.3) and found strange bug in posts parser.

Create article with following HTML:

<div class="wassup"><a href="#">WP IZ ASSUM</a></div>

Browser will get:

<div class="wassup"><a href="#">WP IZ ASSUM</a></div>

All seems to be fine! Now get rid of unnecessary div.

Create article with following HTML:

<a href="#">WP IZ ASSUM</a>

Browser will get:

<p><a href="#">WP IZ ASSUM</a></p>

Dunno why there is extra <p> but who cares. All seems to be OK.

Create article with following HTML:

<figure><a href="#">WP IZ ASSUM</a>
</figure>

Browser will get:

<figure><a href="#">WP IZ ASSUM</a><br />
</figure>

Now isn't that cool? But check what is even cooler!

Create article with following HTML:

<figure><a href="#">WP IZ ASSUM</a>
<figcaption>NO IT'S BUGGY AS HELL</figcaption>
</figure>

Browser will get:

<figure><a href="#">WP IZ ASSUM</a></p>
<figcaption>NO IT’S BUGGY AS HELL</figcaption>
</figure>

Wow! Say hello to invalid markup and rendering problems! Auto-closing of tags turned off. No matter of the settings I still get this nice messed up html. WYSIWYG turned off also.

[scribu]

The problem is that wpautop() doesn't know how to treat the new HTML5 tags yet.

[johnnyb]

I can confirm that this still exists in the latest trunk, (r18406), and will try to get it fixed.

[johnnyb]

After further review, this isn't related to HTML5, it's related to the inline element being on the same line as the block-level element. If we take the test case provided and replace the HTML5 elements with divs:

<div><a href="#">WP IZ ASSUM</a>
<div>NO IT'S BUGGY AS HELL</div>
</div>

The same behaviour presents itself and we get this being sent to the browser:

<div><a href="#">WP IZ ASSUM</a></p> 
<div>NO IT&#8217;S BUGGY AS HELL</div> 
</div> 

Since this isn't restricted to HTML5 I'm adjusting the keywords on the ticket.

[nacin]

Nice find!!

[johnnyb]

I also just discovered that this is very old. I just tested it with the version of wpautop() from r5020 (March 2007), and the same problem exists.

IMO the solution to this depends on the motivation behind wpautop(), and since this is the first bug I've worked on I'm not exactly up to speed on that ;) If the motivation is to simply put all inline content into <p> tags then we should dump a <p> in between the block & inline tag, or we could add a line-break after every block tag and let the rest of wpautop do its thing.

[azaozz]

The only problem here seems to be that there are extra line breaks in the HTML. Wpautop works best when there are no line breaks at all or they are only after block elements. Try this:

<div><a href="#">WP IZ ASSUM</a><div>NO IT'S BUGGY AS HELL</div></div>

[johnnyb]

Replying to azaozz:

Try this:

<div><a href="#">WP IZ ASSUM</a><div>NO IT'S BUGGY AS HELL</div></div>

That works fine. This is what comes out:

<div><a href="#">WP IZ ASSUM</a> 
<div>NO IT&#8217;S BUGGY AS HELL</div>

[soulseekah]

Input:

<a href="#"><div>this seems valid</div></a>

Output:

<p><a href="#">\n<div>this seems valid</div>\n<p></a></p>\n

This may not be up to some strict standards but is quite valid input, it seems. At least many validators accept that.

[WraithKenny]

Note that when striping the linebreaks as suggested, moving back and forth between Visual and HTML will add them back.

<div><a href="#">WP IZ ASSUM</a><div>NO IT'S BUGGY AS HELL</div></div>

becomes the problem case:

<div><a href="#">WP IZ ASSUM</a>
<div>NO IT'S BUGGY AS HELL</div>
</div>

and after another toggle becomes

<div>

<a href="#">WP IZ ASSUM</a>
<div>NO IT'S BUGGY AS HELL</div>
</div>

but this is related to the javascript not wpautop. Still, it should probably be considered.

[chriscct7]

Still an issue in 4.0. Placing <a href="#"><div>this seems valid</div></a> in the Text editor then switching to visual and back drops the link

[ocean90]

#37328 was marked as a duplicate.

[MattyRob]

Related #39307