Opened 23 months ago

Last modified 6 months ago

#18136 reopened defect (bug)

WordPress Adding Spurious </p>

Reported by: singpolyma Owned by:
Priority: normal Milestone: Awaiting Review
Component: Formatting Version:
Severity: normal Keywords:
Cc: japh@…, mike@…

Description

If you look at this page: https://singpolyma.net/2011/06/dystoparx-part-12/ WordPress seems to be adding extra </p> tags before the </div>s This causes major well-formedness problems on the page.

Change History (12)

Please post the HTML you have in your post content. We need before and after.

  • Keywords reporter-feedback added

I checked the code on some of the other more recent posts and it doesn't show anymore. This has more than one year. Shouldn't it be closed?

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Severity changed from major to normal
  • Status changed from new to closed

There are still excess </p> tags in the linked post, but I couldn't reproduce the issue by copying the content from the HTML source (also tried switching to visual editor and back to HTML) neither in 3.4 nor in current trunk.

Free free to reopen with steps to reproduce if there's still a problem.

  • Resolution worksforme deleted
  • Status changed from closed to reopened

http://pastie.org/4466275

That's the input as showing on my WP dashboard. I tried saving again and with X-Valid turned off as well, just in case that was transforming it (but it's not, still shows as fine in the dashboard), but it's still got the extra </p> in the page.

  • Keywords reporter-feedback removed
  • Milestone set to Awaiting Review

Confirmed when pasting the linked input into HTML (Text in 3.5) editor, saving and viewing the post.

After switching to visual editor and back, the extra </p> is gone.

I enabled the visual editor, switched to it and then switched back, and it broke some of my other markup, but after fixing that it does seem to be a workaround for the issue.

Still seems like a bug, though.

Got it down to this:

  • Extra closing P
    <div><p>123</p> </div> 
    
  • Works as expected
    <div><p>123</p></div> 
    

Generally autop should ignore the whole content as there are no line breaks in there. What happens in this case: autop inserts a line break after the </p> and then threats the white space as another row.

A temporary workaround would be to remove all spaces between block tags.

  • Cc japh@… added
  • Cc mike@… added

Related: #21689
(via @Japh)

Note: See TracTickets for help on using tickets.