[wp-trac] [WordPress Trac] #6016: Whitespace is not trimmed from teaser/extended entries

[WordPress Trac]

#6016: Whitespace is not trimmed from teaser/extended entries
------------------------+---------------------------------------------------
 Reporter:  redsweater  |       Owner:  josephscott
     Type:  defect      |      Status:  new        
 Priority:  normal      |   Milestone:  2.6        
Component:  XML-RPC     |     Version:             
 Severity:  normal      |    Keywords:  has-patch  
------------------------+---------------------------------------------------
 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.

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

-- 
Ticket URL: <http://trac.wordpress.org/ticket/6016>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software