wpautop adds a extra </p>

[pbearne]

I am seeing similar problem this code

<?php
wpautop( '<div><span></span><div></div></div>' );

renders

 "<div><span></span></p>
<div></div>
</div>
"

[pbearne]

fixed the uses comment

[pbearne]

fixes it

[pbearne]

Added a patch that does fix it but the fix is to add span to the block items which does feel right

This was caused by https://core.trac.wordpress.org/changeset/38592

[azaozz]

Looking at formatting.php.patch, we cannot add span to the list of "block tags", it is not a block :) That would introduce numerous failures with spans in paragraphs.

Not even sure if this edge case can be fixed without removing the extra \n from here. We can try adding exceptions for the more common inline tags that are before a block tag where both are inside another block tag, but that will be quite slow and complex, and will have additional edge cases.

This looks quite similar to the nested block tags problems in autop. More cases are tracked in #38656. Perhaps better to close it as duplicate.

[pbearne]

I suspected that adding span to the blocks wouldn't be the best fix

Can we keep the unit test?

[pbearne]

patch and test

[pbearne]

I had a quick look at the function again and saw that where are handling <option> to fix the same problem so I have been able to add similar code to strip line breaks before and after <span> elements and this works

[pbearne]

@dd32 can push into the next 4.7.x as well as #39307

[azaozz]

Replying to pbearne:

I had a quick look at the function again and saw that where are handling <option> to fix the same problem so I have been able to add similar code to strip line breaks before and after <span> elements

As I said above this will introduce numerous regressions. All spans that are not immediately inside a block element will be affected. Also all <br> around spans will be gone. Couple of cases:
1 <span>2</span> 3 will render as 123 instead of 1 2 3

1 <span>2</span>
3

will render as 123 instead of

1 2
3

I still don't see a good way to fix this apart from reverting [38592].

I had a quick look at the function again and saw that where are handling <option> to fix the same problem

Yes, that works for <option> as it is only allowed in <select> and there can't be any text around it.

[pento]

Closing this as a duplicate of #27350, which has the same root cause.