Stale enclosures are not removed if post is edited.

[my_user_name_was_not_valid]

The only way to remove enclosures is to delete them from the postmeta table by hand. If you change a url on a enclosure the rss/atom feeds would now show both new and old enclosure urls even though there is only one enclosure. I am attaching a patch that adds a foreach loop to the do_enclose function in wp-includes/functions.php that deletes enclosures from the metapost table that are no longer in the post.

Milestone 2.5.2 deleted

broken patch

Hi, I have verified that this bug exists and i have rebased the old patch to a current svn revision 11181 and tested it briefly, it appears to be working. I've attached it (fix_stale_enclosures-rebased.patch)

shouldn't the query be meta_value = %s, rather than like (%s)?

meta_value = %s wont work because the url wont match exact since the meta_value also contains the length and the type appended to it separated by newlines. An example meta_value:

http://podcasts.example.com/some.mp3
3133986
audio/mpeg

And since we don't know the length and mine type at this point in the code we can't match them, hence the LIKE

could this code not be placed over at in wp_update_post or something like that?

Replying to Denis-de-Bernardy:

could this code not be placed over at in wp_update_post or something like that?

I can't figure out how to put this functionality in wp_update_post without some major re-factoring of how enclosures are handled. Plus it makes since (to me at least) to do all the enclosure stuff in the do_enclose function. Is there a specific reason why you don't like it where it is, or a specific place where you think it would be better placed?

no specific reason, I was merely wondering. it seems natural to ensure that enclosures are correct upon saving the post, but as you highlight it's already done with somewhere else.

re-based to revision 11274, adjusted inline documentation

(In [11315]) Remove stale enclosures. Props mystyman. fixes #6840

I'm still seeing this problem in 2.8.2. Unless the last function performed is "Add Custom Field", for something like Slippery 1, the custom field disappears. Each time the post is updated, the custom field disappears. I have set the default theme and disabled all plugins and the custom fields still disappear. I'm going to reopen based on this behavior.

Sorry... this is the old bug. I see that the new one is #10511. Sorry.