#6840 closed defect (bug) (fixed)
Stale enclosures are not removed if post is edited.
Reported by: | my_user_name_was_not_valid | Owned by: | |
---|---|---|---|
Milestone: | 2.8 | Priority: | normal |
Severity: | normal | Version: | 2.5 |
Component: | Feeds | Keywords: | 2nd-opinion has-patch needs-testing enclosures has-unit-tests |
Focuses: | Cc: |
Description
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.
Attachments (2)
Change History (23)
#3
@
17 years ago
- Keywords has-patch added
- Resolution set to fixed
- Status changed from new to closed
#9
@
16 years ago
- Keywords has-patch added; needs-patch removed
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)
#10
@
16 years ago
- Keywords reporter-feedback added
shouldn't the query be meta_value = %s, rather than like (%s)?
#11
@
16 years ago
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
#13
follow-up:
↓ 14
@
16 years ago
- Keywords 2nd-opinion added
could this code not be placed over at in wp_update_post or something like that?
#14
in reply to:
↑ 13
@
16 years ago
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?
#15
@
16 years ago
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.
#17
@
15 years ago
- Cc windyweather added
- Resolution fixed deleted
- Status changed from closed to reopened
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.
#18
@
15 years ago
- Cc windyweather removed
Sorry... this is the old bug. I see that the new one is #10511. Sorry.
This ticket was mentioned in PR #6833 on WordPress/wordpress-develop by @dmsnell.
6 months ago
#20
- Keywords has-unit-tests added
In [58418] a test was added without the test_
prefix in its function
name, and because of that, it wasn't run in the test suite.
The prefix has been added to ensure that it runs.
In the original patch, due to a logical bug, a recursive loop to
transform the inside contents of the bogus comments was never run
more than once. This has been fixed.
This patch also includes one more case where kses
wasn't
properly detecting the bogus comment state, and adds a test case
to cover this. It limits itself to some but not all constructions
of invalid markup declaration so that it doesn't conflict with
existing behaviors around those and other kinds of invalid comments.
See also #6840
Milestone 2.5.2 deleted