Make WordPress Core

Opened 17 years ago

Closed 17 years ago

#6016 closed defect (bug) (fixed)

Whitespace is not trimmed from teaser/extended entries

Reported by: redsweater's profile redsweater Owned by: josephscott's profile josephscott
Milestone: 2.6 Priority: normal
Severity: normal Version:
Component: XML-RPC Keywords:
Focuses: Cc:

Description

The contents of the "description" and "mt_text_more" should be whitespace-trimmed in order to make the behavior for entries submitted via XMLRPC match the behavior for posts entered manually in the wp-admin editor.

Specifically, xmlrpc.php currently joins the literal values, including any whitespace, by a literal "\n<!--more-->\n" constant.

The intent here is to prepare the text such that it perfectly mimics the format that code in wp-includes expects when parsing the content of a post and splitting it back out into teaser and extended. But by retaining any whitespace from the submission, it screws things up in a number of ways:

  1. The trailing newline that a user might naturally type at the end of a "teaser" composition is retained, thus causing a double-newline in the content of the post which is permanently stored in the post, and shows up in rendering.
  1. Because the assumptions about the teaser and extended being white-space stripped are so high, the XMLRPC methods for returning the content *do* strip the whitespace, so clients are given an unrealistic view of what the post actually contains. While the post will have ended up with a trailing newline in the teaser, and will render with a <br />, the XMLRPC client continues to be under the illusion that the whitespace had been trimmed.

By actually making the XMLRPC methods trim the whitespace on the way into the database, it seems to solve the problem at the root. It's possible that in the future it would be a nice ambition to preserve literally whatever whitespace a user submits for these fields, but at the moment the expectations for stripped components is so high, the guarantee should be encouraged here for maximum compatibility.

I've attached a patch which at least crudely fixes the problem. There's an issue of code repetition that I didn't attempt to remedy.

Attachments (2)

FixExtendedWhitespace.diff (1.8 KB) - added by redsweater 17 years ago.
Trim the whitespace from description and more/extended.
xmlrpc.php.diff (625 bytes) - added by josephscott 17 years ago.

Download all attachments as: .zip

Change History (10)

@redsweater
17 years ago

Trim the whitespace from description and more/extended.

#1 @redsweater
17 years ago

FYI this was motivated by a MarsEdit user's noticing the bug of the extra whitespace in his posts:

http://www.red-sweater.com/forums/viewtopic.php?pid=3621

#2 @josephscott
17 years ago

My only concern would be that this would limit some of the uses of <!--more-->, for example:

The answer to the question is ... <!--more--> 42!

With your patch that would translate into :

The answer to the question is ...
<!--more-->
42!

Which would not be rendered the same way.

#3 @redsweater
17 years ago

Actually, take a closer look at the patch. The previous code already had the "\n" characters hardcoded around the more tag. So what you're proposing wasn't exactly possible before, either. The translation you describe is exactly what happens *before* my patch, too.

You're right to notice that WordPress limits how you can play with whitespace and the more tag, and it's a valid concern. But at the moment there's no way to achieve the types of nuanced behavior you're describing through the wp-admin editor, and there are only some very weird ways of achieving creative whitespace through the RPC interface.

A better example of what my patch does is:

The answer to the question is ...


<!--more-->

42!

Becomes

The answer to the question is ...
<!--more-->
42!

But go ahead and try the same example in the wp-admin editor, and you'll see that my patch achieves parity with that editor.

What I'm proposing is that we should bring the XMLRPC interface into parity first, and then you can consider longer term whether it's desirable to respect surrounding whitespace in these components. If it's decided that it is, then it will be a good time to tackle the problem both in the wp-admin interface and in the XMLRPC interface.

But this seems like the easiest way to impose some sanity right now.

#4 @redsweater
17 years ago

  • Keywords has-patch removed

Ugh! Of course, I just tried the example you cited in the wp-admin editor

The answer to the question is ... <!--more--> 42!

And it worked as you suggest. So there are clearly more edge cases here than I though.

OK - thanks for the sanity check. I still think something needs to be done to bring the XMLRPC into parity with wp-admin, but it's not as simple as I first guessed.

#5 @redsweater
17 years ago

Somehow we need to get the text as provided by web clients to reliably line up with what you get through wp-admin. I think one step in that direction could be to remove the hardcoded "\n" characters in xmlrpc.php, surrounding the more tag.

This makes sense to me because it allows a client to carefully construct a "no newlines" example as you suggest, but also works well with the likely scenario of a client with separate fields typing in a trailing newline at the end of the teaser section.

The secondary change then would be to make sure that this combined teaser/extended post body gets processed in exactly the same way as the wp-admin submitted text. I am not sure if this is happening right now.

Daniel

#6 @josephscott
17 years ago

I agree, the "\n<!--more-->\n" in XMLRPC can cause a different experience from wp-admin. That should be changed to "<!--more-->".

#7 @josephscott
17 years ago

Add patch that removes the new lines around the <!--more--> in a post. This makes the formatting of posts in XML-RPC behave more like posts in wp-admin.

#8 @westi
17 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [7599]) Don't add new lines around the <!--more--> tag when posting over xmlrpc. Fixes #6016 props josephscott and redsweater.

Note: See TracTickets for help on using tickets.