Duplicate enclosure attributes are created when a client resubmits a post with identical enclosure

[redsweater]

The support in 2.6 for accepting enclosures via XMLRPC does not discriminate whether the specified enclosure is already attached to the post in question. This has the effect that if a client redundantly re-specifies the enclosure value, WordPress will redundantly add new enclosure custom field entries, each time the post is edited.

The code that accepts <enclosure> elements should only add a new custom field to the post if the enclosure specified is different from the previous enclosure(s). Arguably, for an XMLRPC context, the specified enclosure should always replace the (presumed singular) enclosure on the post.

Right now, the number of redundant enclosure attributes can spiral out of control depending on the number of times a given post is edited by a remote client that re-specifies all the known attributes of a post.

Consider for example, that when resubmitting a post, it's natural and expected to re-specifiy the <title> even if it hasn't changed. This doesn't cause multiple "title" attributes to appear on a post. The re-specification of the <enclosure> value shouldn't cause attribute bloat in posts.

Daniel

Daniel

First attempt at a patch

Added patch that should check through the enclosures and not re-add any that already exist in the post meta info.

The patch provided was not quite working because the test for "!found" was missing the $ for the variable name.

I fixed the patch and also extracted the duplicated logic into a function add_enclosure_if_new().

I tested it with MarsEdit as a client and confirmed that the duplicate enclosures are no longer being created.

Revision of the initial patch.

(In [10383]) Don't duplicate enclosures on edit. See #7773 props redsweater.

Could possibly optimise to use get_post_meta rather than get_post_custom.

That would reduce the nesting a bit I think.

Bumping the optimization to Future, pending patch...