This is not a big bug but could cause some headaches.
When you delete a media node from directly inside the Media section, it does not update the DAMP listings. However, once you delete the media node from the Recycle Bin, this updates the DAMP listings.
I update the DAMP listings in the media delete event. This event only get's called when you empty the recycle bin. When you first delete the media item it only get's moved. I decided not to update the media item in this event, because it still exists.
As a admin user, I would expect that if I put the media item into the recycle bin, it will be removed from the site - perhaps it is sensative content. If I restore the media item, I would expect to see the item return to the site.
Maybe in the XML or in the list of ids there is a way of setting this up (eg xml has recycledMediaItem node/attribute for restoring media items and for list of ids, there is another list of ids for the recycle bin to be able to restore it if it is moved back into the media folder).
One thing I also noted, is that when its moved to the recycle bin or to another folder location, the parentId is not updated, so its not possible to check based of its location in the media folder
I agree with Hamish, about delete/restore. I would think the xml node name for deleted items should be completely different, so a 'normal' xpath or razor query will simply not return items that are in the recycle bin.
Perhaps if this would be too much of a change, then make it a configurable option, however I think you'd save users some potential embarassment by removing deleted items (how obvious does that sound?), I guess if they can jump through hoops to get to them then that's ok, as long as it's not the default.
I think it would be up to the developer to deal with this if selected media are stored in CSV format.
I know you guys are right, but if you move a media item only the parent id is updated. For example if you move a folder which has 20 children you need to update the DAMP xml of those 20 children. This can be a very heavy process and only to update the parent id. That's why I decided not to add this.
If you use the normal media picker and move a media item to the recycle bin it also stays selected in the picker. With DAMP the same thing happens. If it's moved to the recycle bin only the move event is called and I just explained why I'm not updating in that event :).
If you want the parent id to be updated I recommand to only store the id and not the full DAMP xml. Than you can use libery.GetMedia to get the xml with the newest parent id (at least in most situations). You could also write your own event which updates the DAMP xml when you move a media item. Here you can see which events are currently used: http://damp.codeplex.com/SourceControl/changeset/view/81602#1765747. You could add your own dll with your own events and do it there.
One big advantage of DAMP is that it means media items to not hit the DB when a page is rendered (better for performance). If we needed to hit the DB just to see if the image has been moved to recycle bin that would negate the advantage.
You're right, in saying we can add our own event to handle things how we want. Although we wouldn't be able to show an item as deleted in he DataTypeEditor, nor possibly would we be able to do the fancy 'restore' part. (it's a shame there isn't an even specifically for moving to recycle bin)
DAMP makes sure no DB is hit when you display and image, but these days Umbraco itself also has some good solutions for this. If you use library.GetMedia in XSLT the image is also cached (so only DB call on the first load) and if you use Model.MediaById in Razor the image is fetched from examine (since 4.7.1.) which also won't hit the DB. So it's also fast to use DAMP and only store the id.
When you delete the media node in Media, DAMP doesn't update
This is not a big bug but could cause some headaches.
When you delete a media node from directly inside the Media section, it does not update the DAMP listings. However, once you delete the media node from the Recycle Bin, this updates the DAMP listings.
Hi Hamish,
I update the DAMP listings in the media delete event. This event only get's called when you empty the recycle bin. When you first delete the media item it only get's moved. I decided not to update the media item in this event, because it still exists.
Jeroen
As a admin user, I would expect that if I put the media item into the recycle bin, it will be removed from the site - perhaps it is sensative content. If I restore the media item, I would expect to see the item return to the site.
Maybe in the XML or in the list of ids there is a way of setting this up (eg xml has recycledMediaItem node/attribute for restoring media items and for list of ids, there is another list of ids for the recycle bin to be able to restore it if it is moved back into the media folder).
One thing I also noted, is that when its moved to the recycle bin or to another folder location, the parentId is not updated, so its not possible to check based of its location in the media folder
Sorry the last statement is when DAMP is saving the imformation in XML, it doesn't update the parentId in the XML when moving media around
I agree with Hamish, about delete/restore. I would think the xml node name for deleted items should be completely different, so a 'normal' xpath or razor query will simply not return items that are in the recycle bin.
Perhaps if this would be too much of a change, then make it a configurable option, however I think you'd save users some potential embarassment by removing deleted items (how obvious does that sound?), I guess if they can jump through hoops to get to them then that's ok, as long as it's not the default.
I think it would be up to the developer to deal with this if selected media are stored in CSV format.
I know you guys are right, but if you move a media item only the parent id is updated. For example if you move a folder which has 20 children you need to update the DAMP xml of those 20 children. This can be a very heavy process and only to update the parent id. That's why I decided not to add this.
If you use the normal media picker and move a media item to the recycle bin it also stays selected in the picker. With DAMP the same thing happens. If it's moved to the recycle bin only the move event is called and I just explained why I'm not updating in that event :).
If you want the parent id to be updated I recommand to only store the id and not the full DAMP xml. Than you can use libery.GetMedia to get the xml with the newest parent id (at least in most situations). You could also write your own event which updates the DAMP xml when you move a media item. Here you can see which events are currently used: http://damp.codeplex.com/SourceControl/changeset/view/81602#1765747. You could add your own dll with your own events and do it there.
Jeroen
One big advantage of DAMP is that it means media items to not hit the DB when a page is rendered (better for performance). If we needed to hit the DB just to see if the image has been moved to recycle bin that would negate the advantage.
You're right, in saying we can add our own event to handle things how we want. Although we wouldn't be able to show an item as deleted in he DataTypeEditor, nor possibly would we be able to do the fancy 'restore' part. (it's a shame there isn't an even specifically for moving to recycle bin)
Thanks for your help Jeroen.
Hi Murray,
DAMP makes sure no DB is hit when you display and image, but these days Umbraco itself also has some good solutions for this. If you use library.GetMedia in XSLT the image is also cached (so only DB call on the first load) and if you use Model.MediaById in Razor the image is fetched from examine (since 4.7.1.) which also won't hit the DB. So it's also fast to use DAMP and only store the id.
Jeroen
Oh really, that's pretty neat. :-)
It's since 4.5 that some library methods are cached after the first call:
library.GetMedia
library.NiceUrl
library.GetMember
I even made a package for that :).
Digibiz Load Cache 2.0
Jeroen
is working on a reply...