WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 13 of Ticket #5250


Ignore:
Timestamp:
10/04/2015 10:56:37 AM (10 years ago)
Author:
johnbillion
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #5250

    • Property Status changed from new to closed
    • Property Severity changed from trivial to normal
    • Property Cc Jani Uusitalo added
    • Property Component changed from General to Formatting
    • Property Summary changed from Unclosed p tags -- not XHTML-compliant! to wpautop() issue with lists
    • Property Priority changed from low to normal
    • Property Milestone changed from 2.5 to
    • Property Keywords needs-patch needs-unit-tests added; xhtml removed
    • Property Resolution changed from to wontfix

  • Ticket #5250 – Description

    initial v13  
    44The problem, in short: WordPress inserted a number of unclosed `<p>` tags into my post. It should either insert correctly closed tags, or none at all. I honestly would prefer the former.
    55
    6 
    76In detail: I had HTML code very similar to this:
    87
     8{{{
    99<ul>
    1010  <li>text<ul>
    … …  
    1212  </ul>more text</li>
    1313</ul>
    14 
     14}}}
    1515
    1616This was automatically converted to:
    1717
     18{{{
    1819<ul>
    1920  <li>text<ul>
    … …  
    2122  </ul><p>more text</li>
    2223</ul>
     24}}}
    2325
    2426Note the extra `<p>` tag in the above, which is unclosed (making the W3C validator choke on my website).
    … …  
    2628Also note, I was not using the WYSIWYG editor (turning it off was the first thing I did), so it's unlikely to be due to that.
    2729
    28 
    2930As a workaround, manually inserting properly closed `<p>` tags works just fine:
    3031
     32{{{
    3133<ul>
    3234  <li>text<ul>
    … …  
    3436  </ul><p>more text</p></li>
    3537</ul>
     38}}}
    3639
    3740Since this workaround exists, the bug is not very prioritary, but it should also (hopefully) be easy to fix.