Paragraphs get removed in table cells when Visual editor is refreshed

[JboyJW]

As far as I know, this issue has been around since 3.1. It's not a bug in 3.0.4. I even stopped upgrading at 3.0.4 for any sites where I knew the client would need to edit tabular data. For security reasons, it's time to upgrade these and I'd REALLY like this issue to be fixed.

The problem happens when using paragraphs in a table cell. When I hit enter to create a new paragraph within a table cell, it looks fine. If I then hit Update/Publish, when the page refreshes, WordPress converts that paragraph break into a single line break. If I then click Update again, WordPress removes that linebreak entirely and the paragraphs are essentially merged.

I can also reproduce this behaviour without even clicking Update. If you just switch to HTML mode and then back to Visual mode, the same issue occurs.

Confirmed, the issue is in TinyMCE somewhere.

To reproduce, make a new post in HTML mode with this text:

<table>
<tbody>
<tr>
<td>
Test one

Test two

Test three
</td>
</tr>
</tbody>
</table>

Switch to visual and back. Notice that the Test one and two are now combined. Updating the post and then the subsequent reload of the visual editor causes the same problem.

See #19917.

Also possibly relevant: #6485.

This also affects paragraphs within list items. Or did, anyway.

Replying to Otto42:

Confirmed, the issue is in TinyMCE somewhere.

No, the issue is in wpautop (both JS and PHP versions). It doesn't handle well block elements that can contain other blocks. To reproduce: save a draft with the above html code from the HTML editor and check the source when viewing the post. It is:

<table>
<tbody>
<tr>
<td>
Test one</p>
<p>Test two</p>
<p>Test three
</td>
</tr>
</tbody>
</table>

where only the first paragraph is broken as HTML 5 allows for no closing </p>.

Possible patch for wpautop

This change to wpautop seems to fix the issue without obvious side effects. However, it would need extensive testing.

Couldn't find the JS version of autop that you are referring to. Not sure where that is.

20943.2.diff​ brings the same change to the JS version.

Unfortunately it's not that easy :)

The patch works for the above example html code but fails for:

<td>Test one

Test two

Test three</td>

The problem with <p> in block tags that can contain other blocks is that it's optional, i.e. it can be <td>some text</td> or <td><p>some text</p></td> or even <td>some text<p>some more text</p></td>.

We will need separate rules for these cases. The alternative is to standardize on always having the <p> in there, but that's undesirable.

Also, this would need good/extensive unit tests if we are to get it right.

Replying to azaozz:

The alternative is to standardize on always having the <p> in there, but that's undesirable.

I'd be perfectly okay with always adding the p in there. That's sort of the whole point of wpautop. :)

Also, this would need good/extensive unit tests if we are to get it right.

Agreed.

Replying to Otto42:

I'd be perfectly okay with always adding the p in there. That's sort of the whole point of wpautop. :)

That may prove "unpopular". If a user wants a tight table like:

_____________
| abc | 123 |

it will turn it into:

_____________
|     |     |
| abc | 123 |
|     |     |

Also <li> is one of these "block parents" and we don't want to force <li><p>...</p></li> everywhere but still would need to support it.

All that gets even more complicated when adding HTML 5.0 into the mix. Unfortunately in HTML 5 there aren't clearly pre-determined block tags in the same sense as in HTML 4 / XTHML 1. Most of the block rules there are "<p> can contain <a> but not if <a> contains block tag".

My take: Paragraphs, if specified for table cells or list items, should remain and/or be corrected. But they shouldn't be added forcefully if they did not exist.

#22397 was marked as a duplicate.

This issue is a horror. It also happens when you wrap your text in a <div> Why change something that was good in previous versions? "I know better what you want - (L)USER" - said the program...

Just out of curiosity if what Nacin said wouldn't that make the patch correct. It seems that it only applies for when you do insert paragraphs yourself.

#23324 was marked as a duplicate.

#19917 was marked as a duplicate.

#24125 was marked as a duplicate.

Reproduced in 3.2 as well. Could not reproduce in 3.1.