WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 5 months ago

#10511 reopened defect (bug)

Enclosure Custom Fields are automatically deleted

Reported by: animepulse Owned by:
Milestone: Future Release Priority: high
Severity: major Version: 2.8
Component: Feeds Keywords: has-patch needs-nacin-feedback
Focuses: Cc:

Description

This bug was introduced by Ticket 6840. I and many other people only wanted specific fields added as an enclosure (like media files for podcasting) and have added those enclosures as custom fields. Now any time we edit those hundreds of posts, or create a new post, those custom fields are deleted by this "bug fix" and there is no way around it without changing code in the functions.php file and then having to redo it anytime an update comes out.

Was there no thought put into the great idea of "let's delete any enclosure field that doesn't have a link in the body of a post"? Wasn't the whole idea of custom fields originally for things like enclosures?

Attachments (3)

has-patch.txt (2.3 KB) - added by jamiefehr 5 years ago.
10511.diff (2.3 KB) - added by technosailor 5 years ago.
Try this diff.
10511.2.diff (2.3 KB) - added by technosailor 5 years ago.
I don't understand the issue, but here's the patch as a diff

Download all attachments as: .zip

Change History (31)

comment:1 @amandato6 years ago

  • Cc angelo@… added
  • Severity changed from normal to major

I hope this feature of deleting enclosures when not linked in the post content gets removed as soon as possible. Even though we (Blubrry PowerPress) implemented the bug fix similar to the one the Podcasting plugin is using to hack around this problem, it still creates problems for users who aren't using a podcasting plugin but who have been manually entering their enclosures in the custom fields because they've been told to do it by adding them to the custom Fields. Please refer to the second comment from Otto42 linked here: http://wordpress.org/support/topic/171263?replies=3 There's also a published book that explains how to use the Custom Fields to add podcasts by naming the field 'enclosure': http://books.google.com/books?id=dXnJgJl8lxQC&pg=PA231&lpg=PA231&dq=wordpress+enclosure+custom+field&source=web&ots=-cbuYTQp3a&sig=a_fNOln46ON3i3K3GLunIc2yswQ&hl=en&sa=X&oi=book_result&resnum=1&ct=result

If the feature of deleting enclosures not linked within the post content is never going to be removed, I would recommend adding warning to the Custom Fields area that says enclosure fields will be deleted unless they are also linked within the blog post content.

Another related issue, adding multiple enclosures to 1 blog post is problematic and the practice in WordPress should be stopped. There are folks that believe that by putting 2+ enclosures in a blog post/feed, that iTunes (and all other podcatchers) will download them all and merge them together. This is a myth, only one of the multiple enclosures will be downloaded by particular clients and it is not consistent which enclosure will be downloaded. In some cases like iTunes, only the first enclosure that is supported is used, where other podcatchers like Google Reader grab the last enclosure. The current practice to grab all of the media links and make them into enclosures is a flawed one for this reason. If you need reputable sources why this is not a good practice, read what Dave Winer says about the subject 5 years ago (http://www.reallysimplesyndication.com/2004/12/21), read the RSS2 specifications at www.rssboard.org, and also refer to the warning given at feedvalidator.org (http://www.feedvalidator.org/docs/warning/DuplicateEnclosure.html). The other inconvenience with this feature is when you add links to media in your posts and you don't want them to become podcast episodes. You can't link to media in WordPress unless you intend to podcast them, which is a big limitation in my opinion.

My recommendation would be for the logic in WordPress to change to the following:

if( !enclosure for post ) {
 scan post content for a media link
   first media link found; insert as enclosure; break;
}

If there's not already an enclosure for the blog post, scan the post content and grab the first media link found to add as an enclosure. If there is already an enclosure, don't add more and don't delete the existing one.

comment:2 @scribu6 years ago

  • Keywords needs-patch added; enclosures removed
  • Milestone changed from Unassigned to 2.9

comment:3 follow-up: @amandato6 years ago

scribu, do you need me to create a patch for this?

comment:4 follow-up: @markjaquith5 years ago

  • Milestone changed from 2.9 to Future Release

comment:5 in reply to: ↑ 4 @animepulse5 years ago

Replying to markjaquith:

Why was this pushed back. It's a simple revision of a previous "fix" that created the problem in the first place. For a "major" level issue isn't 2.9 the logical place to include this?

comment:6 in reply to: ↑ 3 @scribu5 years ago

Replying to amandato:

scribu, do you need me to create a patch for this?

Yes, that's why I added the needs-patch tag.

@animepulse: it was punted because it doesn't have a patch and 2.9 is very close to being launched.

comment:7 follow-up: @jamiefehr5 years ago

I have been using enclosure custom fields without links in my blog post since it's inception years ago, I have several hundred posts that are formed this way. I was dumbfounded when all of a sudden my enclosures were being deleted on publish, there is no warning? I spent hours looking into things before I finally stumbled upon this little report. This is important, DON'T DELETE MY CUSTOM FIELDS WITHOUT WARNING! I set them up as I did for a reason. Resolve this.

comment:8 in reply to: ↑ 7 ; follow-ups: @westi5 years ago

Replying to jamiefehr:

I have been using enclosure custom fields without links in my blog post since it's inception years ago, I have several hundred posts that are formed this way. I was dumbfounded when all of a sudden my enclosures were being deleted on publish, there is no warning? I spent hours looking into things before I finally stumbled upon this little report. This is important, DON'T DELETE MY CUSTOM FIELDS WITHOUT WARNING! I set them up as I did for a reason. Resolve this.

If you want to manually add enclosures then you should not be using the custom fields that WordPress uses for automatic enclosures.

It would be quite simple to create a plugin which supported manual enclosures which were not linked in the post body - the automatic enclosure support works so as to implement enclosures in an easy to use automated way.

comment:9 in reply to: ↑ 8 @animepulse5 years ago

Replying to westi:

If you want to manually add enclosures then you should not be using the custom fields that WordPress uses for automatic enclosures.

It would be quite simple to create a plugin which supported manual enclosures which were not linked in the post body - the automatic enclosure support works so as to implement enclosures in an easy to use automated way.

The "automatic enclosures" that you reference only appeared with this change, which broke backwards compatibility big-time, considering there are books published referencing using custom fields to create enclosures for attaching media files, such as podcasting. And this bug isn't about creating enclosures, it's about wordpress automatically deleting them.

comment:10 @hakre5 years ago

Looks like the update routines were missing to automatically convert older blogs to the new methods?

comment:11 in reply to: ↑ 8 ; follow-up: @jamiefehr5 years ago

Replying to westi:

If you want to manually add enclosures then you should not be using the custom fields that WordPress uses for automatic enclosures.

I need to use the enclosure tag, because I want the files to show up in a podcast, and according to the documentation, wordpress automatically podcasts media files in an enclosure custom field. But I didn't want to put the links in my blog posts because I wanted to work with them using php in the theme.

Years go by and everything works exactly as I want it to and exactly as I understand it should.

Then all of sudden after an upgrade, when I try and create a new post with a custom field, every time I publish it gets automatically deleted. I discover that if I publish the post and then later add the custom field leaving the page without updating the post things work as I would like. Then when trying to schedule some posts and have them all fail on publish I get really frustrated. After some extensive searching I finally come here and realize that some one else had requested a change to how things work that destroys how I want to work with wordpress.

This is really aggravating. I hacked the specific function of the wp core that causes this back to an older version but this is less than ideal. I want to see this "feature" changed.

comment:12 in reply to: ↑ 11 @hakre5 years ago

  • Milestone changed from Future Release to 3.0

Replying to jamiefehr:

I hacked the specific function of the wp core that causes this back to an older version but this is less than ideal.

Can you create a patch of your fix, even if it is not ideal? That might help others as well as it might help to better understand the problem.

If the [11315] did not fix properly / broke expected behavior, this needs to be updated.

@jamiefehr5 years ago

comment:13 @jamiefehr5 years ago

ok, I went and followed the instructions I found on the wordpress site to submit patches. I see resolution got moved to 3.0 which is satisfactory. The function I am using is verbatim from the 2.7 release and I am using it in a production site with 2.9 just fine so there is some testing. Thanks for your help.

comment:14 @scribu5 years ago

  • Keywords has-patch added; needs-patch removed

To enable syntax highlighting, please give a .diff or .patch extension to your patches. Thanks.

@technosailor5 years ago

Try this diff.

@technosailor5 years ago

I don't understand the issue, but here's the patch as a diff

comment:15 @nacin5 years ago

  • Milestone changed from 3.0 to Future Release

comment:16 @jamiefehr5 years ago

The issue is that I have about 700 posts with enclosures that aren't linked to in the body of the post because I use php to get the link and style it apart from the post, and the way wordpress works at the moment I if I edit or create a post that has an enclosure custom field that isn't linked to in the body it gets automatically deleted, a behaviour introduced in version 2.8. I am not changing the way I work things and I would really like to see resolution, I am still having to revert the do_enclosure() function to an older version every time I update my install.

comment:17 @animepulse5 years ago

  • Resolution set to worksforme
  • Status changed from new to closed

@jamiefehr,

I know that this says "Future Release", but it was fixed in 2.9.

comment:18 @nacin5 years ago

  • Milestone changed from Future Release to 2.9

comment:19 @animepulse5 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 2.8 to 3.0

I guess I spoke too soon. This is now broken again in 3.0. This is so frustrating to have a stable platform like this break, fix and then break again.

comment:20 @dd325 years ago

  • Milestone changed from 2.9 to Future Release
  • Version changed from 3.0 to 2.8

reseting milestone/version

comment:21 @kevine4 years ago

  • Cc kevine added
  • Version changed from 2.8 to 3.2.1

Any chance of this ever getting fixed *again*. It was fixed at one time and broke again.

This is still really a big deal. I'm getting lots of people writing to me about it on my blog. Deleting content = Bad.

Worse, while I offer the solution on my blog for editing the functions.php file, the change gets wiped on each upgrade. This results in people losing content without knowing until they realize they need to re-edit the functions.php file again.

Even worse, people are putting up upgrading WordPress, because they think things break when you do this.

Really, this was such a horrible decision to do this, and I can't believe the problem continues.

comment:22 @dd324 years ago

  • Version changed from 3.2.1 to 2.8

Resetting Version field; Please note: The Version field is used to track when a bug was first reported, not that it relates to a current version as well, It is expected that any version between "version" and "milestone" is affected by a ticket.

comment:23 @sacornwell3 years ago

With the release of 3.3 this is still a major issue. I manage a network of blogs that use "enclosure" to pass images via the RSS feeds. It would be great if we could get this fixed so we would not have to touch root files after every upgrade.

comment:24 @nacin3 years ago

I hate having content deleted as much as the next person. This is just awful. We never should have been using an unrestricted meta key that was editable/addable via the UI. The moment it was reported that [11315] ended up deleting manually added enclosures, it should have been reverted and a more compatible solution should have been found.

Possible way out:

  • We assume that all current enclosure meta keys are valid. On upgrade, we update every enclosure meta_key to be _enclosure. This makes it protected, immediately.
  • We update the custom fields box to show _enclosure meta keys, in a special un-edited form.
  • We filter on the metadata fetch for 'enclosure' and prepend any '_enclosure' fields.
  • On save, we continue to delete _enclosure keys that are no longer linked, as well as invalidating them if they are no longer audio or video, as well as updating the URL if there is a redirect we can follow, and updating the mime type or content length if it changes.
  • On save, we take any new 'enclosure' meta keys at face value.

Other possible way:

  • For all automatic enclosures, we include an extra line of data that indicates it is linked from the post. Only enclosures that have this data can be deleted automatically. All enclosures with this data are made read-only in the custom fields UI.
  • All existing enclosures are therefore protected, unless they are linked, at which point they will end up being considered "automatic" links, and then unlinked, at which point they will be removed.

Perhaps there is an amalgamation between these two ideas. I'm probably missing quite a bit here. As I posted in the support forums, I have little experience here. And so that said, since this ticket is three years old, I wouldn't expect a quick fix.

comment:25 @amandato3 years ago

Re "Possible way out", would break existing podcasting plugins. You definitely want the plugins to store episodes in the same way as WordPress does without the plugins, otherwise you end up with the PodPress mess, when PodPress breaks podcasts go dark because they store episodes in a proprietary custom field. If you continue to do the auto deleting, whether or not the enclosure is hidden or not would delete data that other plugins have populated.

Re "Other possible way:", keep in mind that there are two popular podcasting plugins that store the enclosure in custom post type "enclosure" because that was what was documented as the way enclosures are to be stored in WordPress years ago. Podcasting has gone beyond just 3 lines of data for an episode, and now uses the 4th line of the enclosure to store a serialized array of other data. The "include an extra line" method would have serious ramifications.

I proposed a solution, it's in the first reply to this thread 2 1/2 years ago. Its simple fix, keeps the auto add logic for automattic's wordpress.com podcasting support, removes the auto delete logic and also fixes the problem of multiple enclosures, which are a no-no if you really are podcasting.

Keep in mind how ill-thought out this auto enclose feature is. So many bloggers (let alone podcasters) link to media files in their blog posts without ever thinking that the media link would automatically become a podcast episode.

The perfect solution is a new option checkbox in WordPress settings somewhere that would by default (not checked) not do the do_enclose logic, and when checked, would do the do_enclose logic, and limit it to only 1 media file (read my reply from 2 1/2 years ago why you can't just have an endless number of enclosures per post).

nacin, If you're the responsible developer at WordPress.org that can fix this, please contact me at cio [at] rawvoice.com I can save you a lot of time and tell you what is and is not possible, as far as what would work for the podcasting community.

comment:26 @chriscct77 months ago

  • Keywords needs-nacin-feedback added

Nacin: what is your current line of thought regarding this ticket? Did you ever settle on a path of logic for the patch for this?

Core team: Not sure what to tag a needs a specific commentor feedback so I just invented my own tag for that (is there a preferred tag for something like that?)

comment:27 @hlashbrooke5 months ago

There's obviously still no movement here, but I've found a way that seems to work with regards to working around this issue. If you delete the meta field called _encloseme from the post then do_enclose() won't run and the enclosure field won't be deleted. It took quite a bit of searching through core to find this, but a simple solution is to run delete_post_meta( $post_id, '_encloseme' ); as early as possible on the save_post hook for any post where you would like to keep the enclosure custom field.

That might not be the cleanest solution, but it looks like it works consistently for me until this is sorted out in core.

comment:28 @amandato5 months ago

I don't think adding more database writes is a good idea (delete, update, inserts write to the database). You are welcome to see what we did in PowerPress. We replace the do_enclose function with our own. We have a setting in PowerPrsss so the podcaster can select either to auto enclose the first media link in the post content, last media link or no media links in blog post content. It also does not delete enclosures.

I do recommend that future podcasting plugins adhere to the same format, e.g. first 3 lines are the file size, content type and full media url, and the 4th line is a serialized array of extra meta data such as duration, iTunes subtitle, etc... A good example is when you switch between the "Podcasting plugin" and "PowerPress plugin", there's no episode data to import or export. Worst case if no podcasting plugin is present the first 3 lines of data is still there and added to your wordpress feeds.

Note: See TracTickets for help on using tickets.