WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 6 months ago

#15918 new defect (bug)

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

Reported by: retrib Owned by: dunno
Milestone: Future Release Priority: normal
Severity: major Version: 3.0.3
Component: Formatting Keywords: needs-patch
Focuses: Cc:

Description (last modified by scribu)

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.

Change History (13)

comment:1 @scribu4 years ago

  • Component changed from Template to Formatting
  • Description modified (diff)
  • Keywords theme parser removed

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

comment:2 @scribu4 years ago

  • Summary changed from WP adding tags no matter what the settings are to wpautop() breaks HTML5 tags

comment:3 @nacin4 years ago

  • Keywords 3.2-early added
  • Milestone changed from Awaiting Review to Future Release

comment:4 @johnnyb4 years ago

  • Cc johnnyb added

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

Last edited 4 years ago by johnnyb (previous) (diff)

comment:5 @johnnyb4 years ago

  • Keywords html5 removed

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.

comment:6 @nacin4 years ago

  • Summary changed from wpautop() breaks HTML5 tags to wpautop() breaks inline tags on the same line as block tags

Nice find!!

comment:7 @johnnyb4 years ago

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.

comment:8 follow-up: @azaozz4 years ago

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>
Last edited 4 years ago by azaozz (previous) (diff)

comment:9 in reply to: ↑ 8 @johnnyb4 years ago

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>

comment:10 @WraithKenny3 years ago

  • Keywords wpautop added

comment:11 @soulseekah3 years ago

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.

comment:12 @WraithKenny3 years ago

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.

comment:13 @chriscct76 months ago

  • Keywords needs-patch added; 3.2-early wpautop removed

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

Last edited 6 months ago by chriscct7 (previous) (diff)
Note: See TracTickets for help on using tickets.