Enclosure Custom Fields are automatically deleted

[animepulse]

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?

[amandato]

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.

[amandato]

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

[animepulse]

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?

[scribu]

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.

[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.

[westi]

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.

[animepulse]

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.

[hakre]

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

[jamiefehr]

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.

[hakre]

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.

[jamiefehr]

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.

[scribu]

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

[technosailor]

Try this diff.

[technosailor]

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

[jamiefehr]

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.

[animepulse]

@jamiefehr,

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

[animepulse]

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.

[dd32]

reseting milestone/version

[kevine]

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.

[dd32]

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.

[sacornwell]

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.

[nacin]

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.

[amandato]

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.

[chriscct7]

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?)

[hlashbrooke]

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.

[amandato]

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.

[amandato]

It's been 20 months since the last reply to this thread. Any thought by WordPress core devs on addressing this problem?

My recommendation is to restore the behavior otto42 referenced years ago (​https://web.archive.org/web/20150926173355/https://wordpress.org/support/topic/problem-with-the-built-in-podcasting-functionality) allowing for manually entering enclosures and not deleting them if the media url is not present in the blog post content. I would also ask that the practice of auto creating enclosures be revisited and be removed from core. It is problematic because it does not limit the enclosures to 1. As of today there is no podcast client application that can deal with multiple enclosures in a feed.

[fakeologist]

Did something recently change? Enclosures have been missing from my feed since the beginning of September 2016.

[amandato]

Just following up on the status of this bug. Now that Google is indexing all feeds with media assuming it is a podcast, it is dangerous that feeds have media in them simply because someone put an audio mp3 in the post content. WordPress users are most likely not aware that their blog/website may now be getting picked up by Google as a podcast and then appear within Google search results as such both in web search as well as in the Google Podcasts app.

Android app: ​https://play.google.com/store/apps/details?id=com.google.android.apps.podcasts

Also Google Podcasts works on Google Home devices.

Basic info about Google Podcasts: ​http://podcastersroundtable.com/google-podcasts/