Make WordPress Core

Opened 17 years ago

Closed 8 years ago

Last modified 7 years ago

#4857 closed defect (bug) (fixed)

More issues with wpautop()

Reported by: viper007bond's profile Viper007Bond Owned by: pento's profile pento
Milestone: 4.7 Priority: low
Severity: normal Version: 2.3
Component: Formatting Keywords: wpautop needs-patch needs-unit-tests
Focuses: Cc:

Description

Not sure if this should slide into 2.3 or if it can wait for 2.4. Change as need be.

wpautop() has issues with closing </p>'s when it comes to HTML.

For example:

Foo<div>Bar</div>

Results in:

<p>Foo
<div>Bar</div>

Change History (23)

#1 @mdawaffe
17 years ago

Obviously what's generated is incorrect :)

What output do you expect?

#2 follow-up: @foolswisdom
17 years ago

  • Milestone changed from 2.3 to 2.4 (next)

Viper007Bond a "real world" example would be great too, because when I look at that input I wonder if it isn't such an edge case that it could complicate solutions for more general problems.

#3 @Viper007Bond
17 years ago

  • Cc wptrac@… added

#4 in reply to: ↑ 2 @Viper007Bond
17 years ago

Replying to foolswisdom:

Viper007Bond a "real world" example would be great too, because when I look at that input I wonder if it isn't such an edge case that it could complicate solutions for more general problems.

It seems to only do it with block level items.

For example:

This is some <pre>code</pre>

gets turned into:

<p>This is some
<pre>code</pre>

#5 @Viper007Bond
17 years ago

I don't know how to get much more "real world" than that BTW. :/

#6 @mdawaffe
16 years ago

  • Keywords wpautop added
  • Owner changed from anonymous to mdawaffe
  • Status changed from new to assigned

I look at your first (and second) example and expect the paragraph to only wrap around "Foo":

<p>Foo</p>
<div>Bar</div>

since paragraph elements can only contain inline content*. For that reason, I do not expect the paragraph to wrap the whole thing:

mdawaffe thinks this is wrong

<p>Foo<div>Bar</div></p>

#7 in reply to: ↑ description @whoismanu
16 years ago

Replying to Viper007Bond:

Not sure if this should slide into 2.3 or if it can wait for 2.4. Change as need be.

wpautop() has issues with closing </p>'s when it comes to HTML.

For example:

Foo<div>Bar</div>

Results in:

<p>Foo
<div>Bar</div>

obviously it didn't make it into 2.3 ;-( let's hope it will make it into 2.4. here is a real world example from my photoblog plugin. i hope it shows that the problem really is annoying whenever there is need to have some structured content in the content section of the post. i of course also hope it could help raise the priority level of this one ;-). so here you go:

my plugin writes an image plus a corresponding description into the post like this:

<img width="700" height="525" src="someimage.jpg" />
<p class="description">Description of image</p>

The p tag with css class is needed to give the user the possibility to style the result. so i cannot just use line breaks between the image and its description like the wordpress editor would do to separate paragraphs.

The result after it has been deformed by wpautop:

<p><img width="700" height="525" src="someimage.jpg" /> 
<p class="description">Description of image</p>

which is obviously not valid xhtml. what i would expect is

<img width="700" height="525" src="someimage.jpg" /> 
<p class="description">Description of image</p>

or if you really have to put p tags all over the place:

<p><img width="700" height="525" src="someimage.jpg" /></p> 
<p class="description">Description of image</p>

yes, the paragraph should not wrap the whole thing because of the reason you mention. yes, the bug concerns all blocklevel elements, so

<img width="700" height="525" src="someimage.jpg" />
<div class="description">Description of image</div>

results in

<p><img width="700" height="525" src="someimage.jpg" /> 
<div class="description">Description of image</div>

thanks a lot for fixing this.

#8 @DD32
16 years ago

Issue Semi-resolved.

<img width="700" height="525" src="someimage.jpg" />
<p class="description">Description of image</p>

results in: (Incorrect, double <p>'s)

<p><img src="someimage.jpg" height="525" width="700" /></p>
<p><p class="description">Description of image</p></p>
<img width="700" height="525" src="someimage.jpg" />
<div class="description">Description of image</div>

results in: (Which seems to be correct?)

<p><img src="someimage.jpg" height="525" width="700" /></p>
<div class="description">Description of image</div>

Mind you, The resulting HTML in all cases seems to validate for me, But i'm pretty sure the nested <p>'s isnt right. (At least they're balanced now though)

#9 @mdawaffe
16 years ago

  • Milestone changed from 2.5 to 2.6

#10 @Denis-de-Bernardy
15 years ago

  • Component changed from Template to Formatting

#11 @hakre
15 years ago

Another long-player in the formatting bug league, +1 for getting a
definition, unit-tests and merging with related ones.

Merger candidates: #1706, #3833, #4298, ...

#12 @azaozz
14 years ago

  • Keywords needs-unit-tests added
  • Milestone changed from 2.9 to Future Release

#13 @c3mdigital
11 years ago

  • Keywords wpautop needs-patch needs-unit-tests removed
  • Resolution set to invalid
  • Status changed from accepted to closed

Not sure when this was fixed but all the examples above word as expected now.

<p>Foo
</p><div>Bar</div>
<p>This is some
</p><pre>code</pre>
<p><img width="700" height="525" src="someimage.jpg"></p>
<p class="description">Description of image</p>

#14 @SergeyBiryukov
11 years ago

  • Keywords wpautop added
  • Milestone Future Release deleted
  • Resolution changed from invalid to worksforme

#15 @SergeyBiryukov
11 years ago

  • Keywords needs-patch needs-unit-tests added
  • Milestone set to Future Release
  • Resolution worksforme deleted
  • Status changed from closed to reopened

The examples from comment:7 appear to work now, but wpautop( 'Foo<div>Bar</div>' ) still fails for me in trunk:

<p>Foo
<div>Bar</div>

Same with wpautop( 'This is some <pre>code</pre>' ):

<p>This is some
<pre>code</pre>

#16 @ericlewis
9 years ago

wpautop() has an intelligent line that adds a closing <p> tag before <div>, <address> and <form> closing tags (1).

The same could be done here, but it isn't a great fix.

#17 @pento
8 years ago

  • Milestone changed from Future Release to 4.7
  • Owner changed from mdawaffe to pento
  • Status changed from reopened to assigned

#18 @pento
8 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38592:

Formatting: Add an extra line break before block elements in wpautop().

wpautop() considers double line breaks to be the separator between block level HTML elements. By adding two line breaks before a block element, this allows us to process the text before a block element correctly.

Fixes #4857.

#19 @Viper007Bond
8 years ago

Wow, nice to finally close this one out!

#20 @pento
8 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Whee, I didn't update the comment.

#21 @pento
8 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 38593:

Docs: Fix an outdated comment.

[38592] changed the functionality of wpautop(), but didn't update the associated comment to match.

Fixes #4857.

#22 @pento
8 years ago

In 38594:

Formatting: Update autop() to match wpautop().

[38592] changed the behaviour of wpautop() , so it's nice to change autop() to match.

Interestingly, this change isn't necessary for the functionality to work - #4857 didn't affect content that had been run through autop() at some point, as autop() would add a single line break before block elements, then wpautop() would later add a second line break, making it work correctly.

Props nacin for finding out about [38592] on Twitter, and DMing me to remind me to review autop().
See #4857.

#23 @azaozz
7 years ago

Interestingly, this change isn't necessary for the functionality to work

Yes, because </p> is optional in HTML4 and HTML5. It is "good to have" the closing tags, but post_content is valid HTML without this.

Last edited 7 years ago by azaozz (previous) (diff)
Note: See TracTickets for help on using tickets.