wpautop: Avoid wrapping <table> tags with a paragraph

[Denis-de-Bernardy]

wpautop should at least ignore multiline html tags, and possibly ignore any area enclosed within html.

<table
 style="width: 120px; height: 92px; text-align: left; margin-left: auto; margin-right: auto;"
 border="1" cellpadding="7" cellspacing="2">
  <tbody>
    <tr>
      <td><small><small style="font-family: Arial;">Once
I saw it here, I instantly knew what I wanted. I love my new woven wood
shades.</small></small><br>
      <small><small>- Ginny Good</small></small></td>
    </tr>
  </tbody>
</table>

gets formatted as:

<table<br />
 style="width: 120px; height: 92px; text-align: left; margin-left: auto; margin-right: auto;"<br />
 border="1" cellpadding="7" cellspacing="2"><br />
<tbody>
<tr>
<td><small><small style="font-family: Arial;">Once<br />
I saw it here, I instantly knew what I wanted. I love my new woven wood<br />
shades.</small></small><br /><br />
      <small><small>- Ginny Good</small></small></td>

</tr>
</tbody>
</table>

[Denis-de-Bernardy]

Reformatting tags like this before auto-formatting might work:

$str = preg_replace("/

(<[^>]+)
\n
([>]*>)
/x", , $str);

D.

[Denis-de-Bernardy]

It should occur after escaping stuff we don't want to autop, though, i.e. scripts, objects, etc.

[Denis-de-Bernardy]

Related: #9218

[Denis-de-Bernardy]

better approach would be to apply this before saving the post's contents and excerpts.

[Denis-de-Bernardy]

code I use in my plugin:

		add_filter('content_save_pre', array('sem_fixes', 'fix_wpautop'), 0);
		add_filter('excerpt_save_pre', array('sem_fixes', 'fix_wpautop'), 0);
		add_filter('pre_term_description', array('sem_fixes', 'fix_wpautop'), 0);
		add_filter('pre_user_description', array('sem_fixes', 'fix_wpautop'), 0);
		add_filter('pre_link_description', array('sem_fixes', 'fix_wpautop'), 0);

	#
	# fix_wpautop()
	# http://core.trac.wordpress.org/ticket/4298
	#
	
	function fix_wpautop($content) {
		$content = str_replace(array("\r\n", "\r"), "\n", $content);
		
		while ( preg_match("/<[^<>]*\n/", $content) ) {
			$content = preg_replace("/(<[^<>]*)\n+/", "$1", $content);
		}
		
		return $content;
	} # fix_wpautop()

[Denis-de-Bernardy]

see also: #3833, #6041, #6984, #2833, #9437, #7988

[Denis-de-Bernardy]

new patch on pre_ filters

[westi]

Before we carry on modifying autop I would really like to see a set of test cases written using the wordpress-tests setup so that we can really get a defined behaviour for this function and iron out all the bugs ;-)

I'm not sure we should make any changes to it's behaviour without these tests.

[Denis-de-Bernardy]

agreed to a large extent. but I won't be writing them (I currently have a miles long list of things to do already).

punting this to future pending the unit tests.

[Denis-de-Bernardy]

doh, wait. I thought this was another ticket.

it's not a wpautop ticket, or rather it is, but it fixes a genuine bug in it. you don't need a unit test for this one. the stuff in the patch is done by the latest tinymce already. it's the php version that has a problem.

it merely turns stuff like:

<p
  class="foo">

... which gets wrecked by wpautop, into:

<p class="foo">

it has been working successfully for over a year on thousands of sites, and bugs would have been reported long ago if any were present.

the while loop stands for: until there is no open tag (<) followed by a newline char, turn the newline char into a space.

[Denis-de-Bernardy]

until there is no open tag (<) followed by a newline char before it's closed, turn the newline char into a space. even.

[Denis-de-Bernardy]

the ticket that needs unit tests is #3833. this one needs absolutely none of it. it's a bug, and the suggested patch is absolutely harmless.

[Denis-de-Bernardy]

can wait until 2.9

[Denis-de-Bernardy]

still applies clean

[hakre]

Another long-player in the formatting bug league, +1 for getting a
definition, unit-tests and merging with related ones.

Versus: #3833, #4152

[markjaquith]

Early 3.0, for sure. Just hadn't seen this until now.

[Denis-de-Bernardy]

A quick note on this one, because an issue was brought to my attention a few weeks ago. My patch actually breaks things such as:

<?php
$foo = $bar;
?>

What I'm currently doing, in case it inspires a better solution:

	/**
	 * fix_wpautop()
	 *
	 * @param string $content
	 * @return string $content
	 **/

	function fix_wpautop($content) {
		$content = str_replace(array("\r\n", "\r"), "\n", $content);
		
		if ( !preg_match("/<[a-z][^<>]*\n/i", $content) )
			return $content;
		
		global $sem_fixes_escape;
		$sem_fixes_escape = array();
		
		$content = preg_replace_callback("/<\?php.+\?>/is", array('sem_fixes_admin', 'escape_php_callback'), $content);
		
		while ( preg_match("/<[a-z][^<>]*\n/i", $content) ) {
			$content = preg_replace("/(<[a-z][^<>]*)\n+/i", "$1", $content);
		}
		
		if ( $sem_fixes_escape )
			$content = str_replace(array_keys($sem_fixes_escape), array_values($sem_fixes_escape), $content);
		
		return $content;
	} # fix_wpautop()
	
	
	/**
	 * escape_php_callback()
	 *
	 * @param array $match
	 * @return string $out
	 **/

	function escape_php_callback($match) {
		global $sem_fixes_escape;
		
		$tag_id = "----sem_fixes_escape:" . md5($match[0]) . "----";
		$sem_fixes_escape[$tag_id] = $match[0];
		
		return $tag_id;
	} # escape_php_callback()

# http://core.trac.wordpress.org/ticket/4298
add_filter('content_save_pre', array('sem_fixes_admin', 'fix_wpautop'), 0);
add_filter('excerpt_save_pre', array('sem_fixes_admin', 'fix_wpautop'), 0);
add_filter('pre_term_description', array('sem_fixes_admin', 'fix_wpautop'), 0);
add_filter('pre_user_description', array('sem_fixes_admin', 'fix_wpautop'), 0);
add_filter('pre_link_description', array('sem_fixes_admin', 'fix_wpautop'), 0);

[azaozz]

Think this is mostly fixed now. It can only happen when using the HTML editor. By default the visual editor removes all line breaks (except in <pre> tag) as they are insignificant and the JS version of autop removes any breaks inside tags when switching HTML to visual. What remains is perhaps post by email, atompub, etc.

[Denis-de-Bernardy]

Replying to azaozz:

Think this is mostly fixed now. It can only happen when using the HTML editor. By default the visual editor removes all line breaks (except in <pre> tag) as they are insignificant and the JS version of autop removes any breaks inside tags when switching HTML to visual. What remains is perhaps post by email, atompub, etc.

The user who reported it was pasting HTML code from Dreamweaver, I think, into the HTML editor. It was a real annoyance (for him anyway). You're welcome to close if you're not interested in fixing it; only a handful of users reported the issue to me, and I've a plugin that adds the above-mentioned filters.

[Denis-de-Bernardy]

@andrew: shall we close, or should I massage a patch?

[hakre]

@andrew/azzozz: please decide.

[azaozz]

There are several tickets about autop and HTML block elements that can contain other blocks. Think we should handle them together but first will need well made test cases as @westi suggests. Without them don't think we will be able to do this properly.

[nacin]

Moving to future, we need test cases and maybe we can take care of the whole group of wpautop tickets.

[c3mdigital]

Tested: Works in visual fails in Text.

[chriscct7]

Closing as wontfix. Complete lack of interest on the ticket over the last 6 years. Feel free to reopen when more interest re-emerges (particularly if there's a patch)

[Mte90]

Just tested:

<table
 style="width: 120px; height: 92px; text-align: left; margin-left: auto; margin-right: auto;"
 border="1" cellpadding="7" cellspacing="2">
  <tbody>
    <tr>
      <td><small><small style="font-family: Arial;">Once
I saw it here, I instantly knew what I wanted. I love my new woven wood
shades.</small></small><br>
      <small><small>- Ginny Good</small></small></td>
    </tr>
  </tbody>
</table>

And 6.2 alpha now generates:

<p><table style="width: 120px; height: 92px; text-align: left; margin-left: auto; margin-right: auto;" cellspacing="2" cellpadding="7" border="1">
  <tbody>
    <tr>
      <td><small><small style="font-family: Arial;">Once
I saw it here, I instantly knew what I wanted. I love my new woven wood
shades.</small></small><br>
      <small><small>&#8211; Ginny Good</small></small></td>
    </tr>
  </tbody>
</table></p>

We can see that just ignored all the HTML content and added a paragraph to wrap everything.

[Mte90]

So our discussion right now is to understand if it is valid that a paragraph can include a table or not as for the spec ​https://developer.mozilla.org/en-US/docs/Web/HTML/Element/p is not clear.

I will investigate on that.

[audrasjb]

As per today's Old Tickets Triage session, it looks like there is still an issue: <p> element can't contain <table> elements (see ​MDN Specs).

[Mte90]

Just a HTML example to test in the W3C validator (​https://validator.w3.org/#validate_by_input):

<!DOCTYPE html>
<html lang="en">
<head>
<title>My Table-y paragraph.</title>
</head>
<body>
<p>
 <table>
  <tr>
   <td>Hello</td>
  </tr>
 </table>
</p>
</body>
</html>

[Mte90]

So reading the spec ​https://www.w3.org/TR/html4/struct/text.html#h-9.3 (I think that is the same as HTML5 the W3C validator infact report it as error) paragraph cannot contain a table element.

Reading seems that we open a paragraph, we add a table and the close of the table tag close the paragraph.

This means that we need to fix wpautop and add some tests for that case.

[azaozz]

Replying to audrasjb:

it looks like there is still an issue: <p> element can't contain <table>...

Yes, generally wpautop doesn't support tables. There is a workaround: no line breaks between any of the table tags (tr, td, etc.). Then the tables mostly work properly.

This ticket hasn't been fixed for 19 years because similar changes to wpautop tend to introduce bugs and other/new edge cases. Another reason is that some of the incorrect behavior may be expected by other code and fixing it would break that code.

Re-closing as "wontfix" seems the right thing to do here.