Make WordPress Core

Opened 17 years ago

Closed 16 years ago

#6099 closed defect (bug) (fixed)

WordPress Filters Not Properly Converting Newline Characters When Submitting Via AJAX

Reported by: ronalfy's profile ronalfy Owned by:
Milestone: 2.9 Priority: normal
Severity: normal Version: 2.5
Component: Formatting Keywords: needs-patch
Focuses: Cc:

Description

I've observed some odd behavior on plugins that submit content via AJAX, most notably comments. The problem is not with the plugins themselves, per se, but rather the way WordPress filters the content.

Here is an example of a comment submitted:

Paragraph 1 :)

Paragraph 2 :)

Paragraph 3

In a post the comment's HTML is:

<p>
Paragraph 1
<img class="wp-smiley" alt=":)" src="http://127.0.0.1/latest/wp-includes/images/smilies/icon_smile.gif"/>
</p>
<p>
Paragraph 2
<img class="wp-smiley" alt=":)" src="http://127.0.0.1/latest/wp-includes/images/smilies/icon_smile.gif"/>
</p>
<p>Paragraph 3</p>

However, if one was to post the same comment or edit the comment via AJAX, the resulting code would be:

<p>
Paragraph 1
<img class="wp-smiley" alt=":)" src="http://127.0.0.1/latest/wp-includes/images/smilies/icon_smile.gif"/>
<br/>
Paragraph 2
<img class="wp-smiley" alt=":)" src="http://127.0.0.1/latest/wp-includes/images/smilies/icon_smile.gif"/>
<br/>
Paragraph 3
</p>

The culprit could easily be the plugin, however, the code I'm currently using is the exact same used when editing a comment using the normal form method, which is to call the wp_update_comment method.

When saving the above comment, the code that the JavaScript sends is:

Paragraph 1 :)\n\nParagraph 2 :)\n\nParagraph 3

Somewhere along the way, the extra newlines are being lost in translation and being converted into BRs instead of new paragraphs.

Change History (8)

#1 @markjaquith
17 years ago

  • Milestone 2.6 deleted
  • Resolution set to invalid
  • Status changed from new to closed

We're going to need to see more of a smoking gun that WP is the culprit here. Are you using your own AJAX library, or WP's? Investigate to see where, exactly, the line breaks are being lost.

#2 @ronalfy
17 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Mark,

I'm using the jQuery supplied with WordPress and the plugin I wrote called Ajax Edit Comments. I've modified my code to mimic exactly how WordPress edits its own comments.

Using the example I provided, here's what gets sent via AJAX:

Paragraph 1 :)\n\nParagraph 2 :)\n\nParagraph 3

I then get the original comment, decode the passed text, and update the original comment with the new text. I then update the comment using WP's built in function:

$comment = get_comment($id, ARRAY_A);
$content = urldecode($content);
$comment['comment_content'] = $content;
wp_update_comment($comment);

Within the wp_update_comment function are two filters that are run on the new comment content. These two filter are pre_comment_content and comment_save_pre. If I run these two filters on the passed text, it returns this code:

Test Paragraph 1 :)\n\nTest Paragraph 2 :)\n\nTest Paragraph 33

The two filters are run and produce identical results to what's passed via AJAX.

Then of course the filter comment_text gets applied, and you get the final resulting code:

<p>Test Paragraph 1 <img src='http://127.0.0.1/raproject/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />\nTest Paragraph 2 <img src='http://127.0.0.1/raproject/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />\nTest Paragraph 3</p>\n

So the culprit I believe lies with the comment_text filter when smilies and some other characters are inserted with a comment.

This behavior happens on other AJAX related comments such as Absolute Comments, Better Comments Manager, and AJAX Comments. All have the common-denominator of the 'comment_text' filter.

#3 @ronalfy
17 years ago

Upon even further investigation, the comment_text filter calls the convert_smilies function. It looks like the newlines are being stripped out on line 687 in formatting.php

$content = preg_replace($wp_smiliessearch, $wp_smiliesreplace, $content);

This is what goes into the convert_smilies function:

"First Paragraph :)\nd\nSecond Paragraph :)\n\nThird Paragraph\n"

This is what comes out before hitting the wpautop function (the next function to be called by the comment_text filter:

"First Paragraph <img src='http://127.0.0.1/raproject/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> d\nSecond Paragraph <img src='http://127.0.0.1/raproject/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> \nThird Paragraph\n"

Notice that the newline character before the "d" is stripped out, and a newline before "Third Paragraph" is stripped out.

If smilies are disabled for WordPress in the Writing panel, this bug disappears.

#4 @ronalfy
17 years ago

  • Severity changed from major to normal

#5 @ronalfy
17 years ago

  • Keywords needs-patch added

#6 @lloydbudd
17 years ago

  • Milestone set to 2.6

#7 follow-up: @Denis-de-Bernardy
16 years ago

  • Component changed from General to JavaScript

still current?

#8 in reply to: ↑ 7 @azaozz
16 years ago

  • Component changed from JavaScript to Formatting
  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to Denis-de-Bernardy:

still current?

Seems not. The convert_smilies regex was changed some time ago and doesn't seem to strip new lines any more (if this was the original bug).

Note: See TracTickets for help on using tickets.