Problem with the wpautop function ads a extra <p> tag if there is more span tag

[keithdsouza]

There is a small bug in the cleanup code wpautop where it adds a extra <p> tag if there is a more section in the post.

The problem starts on this line of code

$pee = preg_replace('/\n?(.+?)(?:\n\s*\n|\z)/s', "<p>$1</p>\n", $pee); make paragraphs, including one at the end

For starters run the method in a standalone mode on this html snippet

<p>hello</p> <span id="more-2689"></span> <p>hello1</p>

once this line of code is applied the new html code is

<p><p>hello</p></p>
<p> <span id="more-2689"></span>
<p>hello1</p></p>

As you can see it added the <p> tag before span but missed out on adding the end tag, on the other hand it still added <p> tags to all other start and end tags

This line $pee = preg_replace('!(</?' . $allblocks . '[^{>]*>)\s*</p>!', "$1", $pee);}

removes the duplicate tags but the output leaves a invalid xhtml in the form of a open <p> tag

<p>hello</p>
<p> <span id="more-2689"></span> (missing close p tag here)
<p>hello1</p>

The solution would be to change the first regex to this

$pee = preg_replace('/\n\n?(.+?)(?:\n\s*\n|\z)/s', "<p>$1</p>\n", $pee); make paragraphs, including one at the end

Note the \n\n because you are already adding two line breaks in the earlier regex, hopefully you can add this to the coming version

[azaozz]

This particular line in autop doesn't exist any more (as of yesterday), however the replacement works the same way. Entering invalid XHTML as in the example (missing base block around the <span>) could produce unexpected results. You can either enter all <p> tags (valid XHTML) or you can use the HTML editor and type:

hello

<span id="more-2689"></span>

hello1

In both cases it would work correctly.

[WraithKenny]

I know this ticket is over 3 years old but the comment struck me as extremely strange.

It's a slightly absurd and extremely rare condition (likely never happened) for a theme to put the editors contents directly into a XHTML 1.0-Strict document's body element on the theme-side (for this is the only circumstance that the snippet would be invalid). It'd seem to me in this (imaginary) case it'd be the theme's error and the theme should be considered invalid (as opposed to this ticket).

If we'd consider the theme that dumps the_content() into the body element as invalid, that would suggest a shortcoming in the Content Editor's implementation: The fact that the output of the_content() maps to the content of the TinyMCE's body element (which is XHTML 1.0-Strict and disallows inline elements as body children).

<ASIDE>When using Visual Mode, it'd be better to put a div element as a content wrapper (as a valid XHTML 1.0-Strict child of the body element and thus making child inline elements valid) and then removing it on save. This could allow the Visual Editor to contain a proper cascade of body_class (on the TinyMCE's body) and post_class (on this new temporary div) for editor_style.css.</ASIDE>

There isn't any requirement that the Theme be XHTML 1.0-Strict; Other doctypes allow inline elements as children of the body. The XHTML 1.0-Strict limitation is merely a technical shortcoming of the Visual Editor. The Visual Edidor itself is optional and the Visual Editor isn't required to trigger this bug. The bug is, in fact, "entering invalid XHTML could produce unexpected results" and saying so is just a restatement and confirmation of the bug.

Again, this just struck me as bazaar that it would be closed as "invalid" and blamed on user error.

[azaozz]

Replying to WraithKenny:

... that it would be closed as "invalid" and blamed on user error.

The user error is not respecting how the HTML editor (together with wpautop) works. In "pure" HTML code line breaks don't matter, however when using the HTML editor they are converted to <p> or <br>. So pasting or typing "formatted" HTML code in there sometimes won't work as expected.

[WraithKenny]

Andrew, your response upset me quite a bit, I'll admit. Recently I was reminded of this quote:

"The software is wrong, not the people."
Matt Mullenweg

​http://ma.tt/2011/07/the-software-is-wrong-not-the-people/
​http://joeflood.com/2011/07/13/the-software-is-wrong-not-the-people/

[nacin]

Rather than dig up old tickets: ​http://core.trac.wordpress.org/ticket/14264#comment:22.