[wp-trac] [WordPress Trac] #23219: Duplicate enclosure metadata created because of disagreement on meta field formatting

[WordPress Trac]

#23219: Duplicate enclosure metadata created because of disagreement on meta field
formatting
-----------------------------+--------------------------
 Reporter:  redsweater       |       Type:  defect (bug)
   Status:  new              |   Priority:  normal
Milestone:  Awaiting Review  |  Component:  XML-RPC
  Version:  trunk            |   Severity:  normal
 Keywords:                   |
-----------------------------+--------------------------
 Years ago I reported an issue in Ticket #7773 that the enclosures would be
 duplicated each time the post was edited and resubmitted through the
 XMLRPC API. That bug was fixed in [10383] but a nuance was overlooked that
 causes this kind of duplication to occur with every edit if the ORIGINAL
 custom field meta for the enclosure was generated by the automatic
 content-scraper in WordPress.

 If a post with links to "enclosure" type files is submitted either through
 the web interface or through the XMLRPC API, it will automatically
 generate the insertion of enclosure metadata as a custom field with
 fragile-structured content of the format:

 {{{add_post_meta( $post_ID, 'enclosure', "$url\n$len\n$mime\n" );}}}

 But the XMLRPC implementation, where the attempt is made to avoid
 generating duplicates, uses a slightly different fragile template, with no
 trailing newline:

 {{{$encstring = $enclosure['url'] . "\n" . $enclosure['length'] . "\n" .
 $enclosure['type'];}}}

 To make a long story short: the attempt to detect an existing enclosure on
 the post always fails because the existing enclosure string has a newline,
 and the XMLRPC-based one does not.

 I propose that this be fixed by at enacting 1 and probably also 2:

 1. Make sure duplicate detection method insensitive to trailing
 whitespace. This will fix the bug in a way that doesn't require
 retroactively "fixing" the existing stored metadata with trailing newline.

 2. Change the format of the "scraped" enclosure generation to match the
 format used by XMLRPC. Either with or without the newline would probably
 be fine, but it seems cleaner to stick with the one that doesn't require a
 trailing newline, just three blobs of text separated by newlines. It also
 seems lucky that the last blob is a MIME type and thus would never have a
 meaningful newline at the trailing end.

 I'm attaching a patch that achieves both of these goals. I report this to
 the XML-RPC component because that's the impact is, even if some of the
 issue is in the default scraping code from functions.php.

 I'm a little less certain about how to tackle a unit test for these cases,
 but if somebody wants to point me in the right direction I can take a hack
 at that too.

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