We have moved to GitHub Issues
Created by Martin Griffiths 15 Oct 2015, 13:32:14 Updated by Sebastiaan Janssen 06 Sep 2018, 18:04:49
Media sent to the recycle bin shouldn't continue to have a accessible URL.
What did you expect to happen? The url become unavailable, media moved to an inaccessible area of the file system.
What actually happened? File still available on the saved URL.
The media is still live until the recycle bin is emptied. I think this should remain as is, or some thought put into how to deal with media in the recycle bin. If the media is physically deleted, moved or renamed when moving to the recycle bin, there may be pages where the images will 404 on both the front end and in the back office.
Perhaps some warning in the back office to indicate the media item has been deleted?
I'm seeing this in 7.4.1 too - I have a media picker that points to a Media item that's been trashed, and nothing on the picker indicates that the image has been put in the recycle bin.
Technically, I think, the ''folder'' that contained the image was trashed - not the actual image. End result should be the same of course...
We are experiencing the same problem as Chriztian describes. Many of our clients first discover that a media is still used on their website, when the recycle bin has been emptied and not when the media is deleted. This is because the media is still accessible when it is "only" deleted. And then when the recycle bin is emptied, it is too late to restore the media.
I think a solution to the problem could be, that when a user deletes a media, then a web.config is add to the media folder. This web.config should be setup to disallow access to any files in the folder. Preferably to return a 404 if possible. And of course this web.config should be deleted if the media is restored from the recycle bin.
A little follow up to Thomas' answer: Blocking access to the folder would make sure that the trashed media wouldn't be accessible in the frontend (which is what we want). But it will also block access for editors in the backoffice from seeing the media in the recycle bin.
So trashing a media could work something like this:
An editor trashes the media located at
The file (and any related thumbnails in the same folder) should be moved to a sub folder - eg.
When the media is now accessed through the backoffice, Umbraco knows to look in the "trashed" foler)
If the media is later restored, the file(s) are simply moved back to the
I don't think we're quite there on the ideas front. Would it not be better to take the deleted item(s) out of the media folder altogether so that NO url of any kind is present for it? The non served up folder could still be called trashed and retain the original file/folder structure to allow for undos.
This issue has been raised by our authors too. They noticed that, even if a document is deleted and all links removed, it's still available via a Google search because the URL is still valid.
Our customers also complained about this issue in a 6.2.3 installation. They delete the media item, but people can still access the file from google. Media protect is not used in this site.
FYI: we're almost done completing the move to the new issue tracker as announced here: https://umbraco.com/blog/a-new-take-on-the-umbraco-issue-tracker/
I am closing the issue here on the old issue tracker, but it will continue on the new issue tracker. The new link is: https://github.com/umbraco/Umbraco-CMS/issues/2931 On GitHub, in the right-hand column, you'll find a "subscribe" button to be notified about updates to this issue.
Backwards Compatible: True
Affected versions: 7.7.3
Due in version: