id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
23219,Duplicate enclosure metadata created because of disagreement on meta field formatting,redsweater,,"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.
",defect (bug),new,normal,3.6,XML-RPC,2.8,normal,,has-patch needs-unit-tests,tollmanz@…