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.

[Otto42]

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.

Note that the issue also exists in 3.4.

[Otto42]

See #19917.

Also possibly relevant: #6485.

[nacin]

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

[azaozz]

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>.

[Otto42]

Possible patch for wpautop

[Otto42]

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.

[SergeyBiryukov]

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

[azaozz]

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.

[Otto42]

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.

[azaozz]

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".

[nacin]

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.

[SergeyBiryukov]

#22397 was marked as a duplicate.

[difreo]

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...

[markoheijnen]

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.

[SergeyBiryukov]

#23324 was marked as a duplicate.

[SergeyBiryukov]

#19917 was marked as a duplicate.

[SergeyBiryukov]

#24125 was marked as a duplicate.

[SergeyBiryukov]

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

[Horttcore]

A workaround for the moment is to add a class in example

<td>
<p class="void">foo</p>
<p class="void">bar</p>
</td>

This p tag will not be removed.

[beardj]

This issue is still happening in version 3.6.1.

[JakePT]

Still occurring in 3.7. I do notice that it only happens to the first paragraph. Not sure if this was always the case or new to 3.7.

[JakePT]

Still occurring in 3.8 RC2. Makes working with tables in WordPress next to impossible.

[nacin]

Paragraph tags might just benefit from special handling compared to other blocks, so they can remain in <td> or <li> (any others?) untouched. Would *love* to fix this. (I personally like paragraph tags inside lists.)

[aatospaja]

Still experiencing this when updating the post. Tried with the latest build I just pulled from git.

While switching from visual to text in the editor, it doesn't remove p/linebreaks but clicking update does.

Adding something like <p align="left"> will help keep the p tags (so it doesn't have to be class="something").

[JakePT]

Still occurs in 3.9 with TinyMCE 4.0.

What's happening is that it will remove 1 paragraph break for every update. So if I had three lines:

<td>Line 1

Line 2

Line 3</td>

I press update and go to Text view, and it's become:

<td>Line 1Line 2

Line 3</td>

And the last time:

<td>Line 1Line 2Line 3</td>

[OzzyCzech]

Wordpress 3.9.1 same problem

[alleynoah]

JS tweak to preserve line breaks in table cells in pre_wpautop

[alleynoah]

According to my testing, the above fix (20943.3.diff) prevents the destruction of line breaks inside table cells without requiring any changes to the backend wpautop. It also does not force all table cell contents to be wrapped in <p> tags.

I'd be happy to contribute test coverage but couldn't quite parse the existing structure to figure out where it would make sense to do so (aside from generally, I think, in tests/qunit/editor/ somewhere?).

[DrewAPicture]

@SergeyBiryukov: Any chance you could follow up here, and consult on test coverage re: comment:37?

[Milmor]

Replying to alleynoah:

According to my testing, the above fix (20943.3.diff) prevents the destruction of line breaks inside table cells without requiring any changes to the backend wpautop. It also does not force all table cell contents to be wrapped in <p> tags.

With this fix the preview is correct, even if switching between html/text mode.

But when saved, the bug is still there and affects the preview (refreshed), even with wp_autop disabled. It happens with and without <p> (<p> are not kept - lines are not kept)

remove_filter( 'the_content', 'wpautop' );
remove_filter( 'the_excerpt', 'wpautop' );

Same with 20943.2.diff

4.2-alpha-31330

[sandyr]

The patch doesn't consider other block elements. Adding different block elements like <ul> <li> and toggling from visual to text(source) mode breaks the content (<p> tags) as well as preview.

I tried with :

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

The tinymce editor handles this well (​http://www.tinymce.com/tryit/full.php). Open source editor with the sample test data above, the preview as well as the visual mode comes up fine.

[sandyr]

The patch doesn't consider other block elements. Adding different block elements like <ul> <li> and toggling from visual to text(source) mode breaks the content (<p> tags) as well as preview.

I tried with :
<table>
<tbody>
<tr>
<td>
<ul>
<li>
<p>Test one</p>
<p>Test two</p>
<p>Test three</p>
</li>
</ul>
</td>
</tr>
</tbody>
</table>

The tinymce editor handles this well (​http://www.tinymce.com/tryit/full.php). Open source editor with the sample test data above, the preview as well as the visual mode comes up fine.

[sandyr]

Patch to fix html, tinymce toggle issue for tables and lists

[sandyr]

Patch attached, as suggested by @nacin: "Paragraph tags might just benefit from special handling compared to other blocks, so they can remain in <td> or <li> (any others?) untouched."

Also fixes the _wp_Nop being invoked for every autosave or toggle from html to tinymce even if there are no changes in the text.

[SergeyBiryukov]

@azaozz or @iseulde would be a better person to provide feedback here.

[azaozz]

Replying to SergeyBiryukov:

None of the patches fix this properly. 20943.3.diff works in some cases only, fails for <td>abc<p>123</p></td>. 20943_patch.diff just disables pre_wpautop (the removal of the <p> tags) if there is <table>, <ul> or <ol> in the content. That makes the Text editor inconsistent and causes problems with some of the display filters, like some shortcodes, etc.

[azaozz]

Fixing this should be a part of a more general fixes/improvements/reworking of wpautop(). Partial changes won't do it, we will just introduce other/different edge cases.

Related: #30644, #25856.

[JakePT]

This seems a little better in 4.3. Paragraphs are typically no longer removed during publishing or switching views.

However if a paragraph has a line break in it (Shift+Enter), then that paragraph will collapse into the following paragraph under the same conditions that paragraphs used to fail.

I'll play around a bit more to see what exactly what's happening.

[SergeyBiryukov]

#29345 was marked as a duplicate.

[dankop]

Is there any progress being made on this issue? Paragraph tags are still getting removed from the first paragraph inside an element (div in my case). In some cases with every switch between text/visual editor, a paragraph gets removed until all that's left is just a hug chunk of text.

[DarcPress]

Still bugged the same way as of today.

This is especially annoying when using ACF (Advanced Custom Fields) because sometimes the ACF takes time to load the TinyMCE and when it does, it behaves like moving from Text to Visual.

[artworking]

For anyone still having issues, this plugin has an option to turn off <p> and <br> removal called "Keep paragraph tags". Saved the day for me works when the issue is caused by ACF too.

​https://wordpress.org/plugins/tinymce-advanced/

[azaozz]

Trying to patch autop doesn't seem relevant any more as it's on its way out.

[sabernhardt]

#58259 was marked as a duplicate.