TinyMCE strips br tags/empty paragraphs in table cells

[jpxwordpress]

The WYSIWIG editor for WP 2.5 does not keep previous content "intact" upon editing a post, as promised:

​http://wordpress.org/development/2008/03/wordpress-25-brecker/
Friendlier visual post editor — I’m not sure how to articulate this improvement except to say “it doesn’t mess with your code anymore.” We’re now using version 3.0 of TinyMCE, which means better compatibility with Safari, and we’ve paid particular attention this release to its integration and interaction with complex HTML...

For example, the first post I tried to make and then edit after going from 'HTML' to 'Visual' mode in the post editing window garbled the appearance of the post immediately after I hit 'SAVE'. What it did, specifically, was move different lines of text too close together/took out line breaks I had wanted, and reduced size of font on some lines with links.

[The browser I am using is Mozilla Firefox 2.0.0.13]

Thank you very much for any feedback you can provide me with to help correct this.

Kevin Pajak – Webmaster, jpopexpress.com

My site’s WordPress Blog:
​http://www.jpopexpress.com/blog/

[lloydbudd]

Hi Kevin, thank you for reporting these issues. Can you please provide specific steps to reproduce the problem?

Closing as invalid for now.

[Jairus]

To reproduce, put the following code into a new post, in tinymce's HTML view:

<p class="rxbodyfield">&nbsp;</p>

<table>
<tr>
<td>Foo</td>
</tr>
<tr>
<td>Foo</td>
</tr>
</table>

<p class="rxbodyfield">&nbsp;</p>

Switch to Visual view. Put two linebreaks after the F in the first Foo. Switch to HTML. Switch to Visual. Switch to HTML. Switch to Visual. The linebreaks are now gone.

[azaozz]

Replying to jpxwordpress:

For example, the first post I tried to make and then edit after going from 'HTML' to 'Visual' mode in the post editing window garbled the appearance of the post immediately after I hit 'SAVE'. What it did, specifically, was move different lines of text too close together/took out line breaks I had wanted, and reduced size of font on some lines with links.

Line spacing and font size is controlled by your theme's style.css. Trying to alter appearance by adding empty <p> and <br /> tags is an outdated practice, so wpautop removes them.

Looking at your example: if you want more space around the table, why not make a new style for it in style.css, or even add inline style (if you want it only on this table)? Also for using tables in TinyMCE, you will need to add the "table" plugin for it or install a WordPress plugin that adds it.

The only error here seems to be that wpautop removes the closing </p> tag when an empty paragraph is immediately above a table, which is a very rare case as tables are not supported by default in the WYSIWYG editor and empty paragraphs are considered bad html coding practice.

[Jairus]

Replying to azaozz:

The only error here seems to be that wpautop removes the closing </p> tag when an empty paragraph is immediately above a table, which is a very rare case as tables are not supported by default in the WYSIWYG editor and empty paragraphs are considered bad html coding practice.

Linebreaks within table cells are being removed. That's a pretty big deal.

[azaozz]

Replying to Jairus:

Linebreaks within table cells are being removed. That's a pretty big deal.

If by linebreaks you mean <br /> tags, no they are not removed. Hard line breaks "\n" does not matter in HTML unless in <pre> tag.

[jacobsantos]

This is very annoying and one of the reasons I still don't use the visual editor.

[Denis-de-Bernardy]

Almost certainly related to the wpautop implementation in the editor js.

[azaozz]

TinyMCE has nothing to do with autop.

[Denis-de-Bernardy]

Err...

​http://core.trac.wordpress.org/browser/trunk/wp-admin/js/editor.dev.js#L35

[Denis-de-Bernardy]

I might be getting this wrong, but the way I understand the ticket is this:

• user is seeking to set the height of his table cells by inserting br tags and/or empty paragraphs
• user switches back and forth from TinyMCE to normal editor
• above-mentioned editor.js messes around with his post

This is 100% related to js. Else close as wontfix.

[Denis-de-Bernardy]

adding to the previous comment: the issue has nothing to do with wpautop, and everythign to do with the reverse of wpautop that gets called during the editor switching.

[azaozz]

Replying to Denis-de-Bernardy:

adding to the previous comment: the issue has nothing to do with wpautop, and everythign to do with the reverse of wpautop that gets called during the editor switching.

Which is still part of wpautop. The function name suggests it too... There are several similar border cases that will need looking into.

[Denis-de-Bernardy]

Replying to azaozz:

Replying to Denis-de-Bernardy:

adding to the previous comment: the issue has nothing to do with wpautop, and everythign to do with the reverse of wpautop that gets called during the editor switching.

Which is still part of wpautop. The function name suggests it too... There are several similar border cases that will need looking into.

In this particular case, though, it has everything to do with its reverse function (which is not in php).

Maybe there should be a wpautop component in trac...

On the one hand side, the two scripts (js and php) are probably no longer in sync, due to the fact that things get committed to the php version without contributors knowing there's a js equivalent. Someone should be making sure that some level of QA is ensured on that front.

On the other, it's one of the most buggiest areas of WP -- and users notice.

[Denis-de-Bernardy]

punting to Future

[Denis-de-Bernardy]

see also: #6490

[janeforshort]

Punting b/c we're in beta.

[Denis-de-Bernardy]

clearly a wontfix based on the discussions

[SergeyBiryukov]

Follow-up: #20943