Process for content deletion?

Question

In Tridion, once a Component, Page or Component Template is deleted then that information is lost forever. I've found that people are uncomfortable with the finality of this process so develop their own solutions in the event that this information is ever needed in the future. 99% of the time this information will never be needed again, but its that 1% that people cling to.

I've seen solutions such such as

• Move content to a "To delete" folder/structure group
• Rename content e.g. "Cat Photo" to "DELETE - Cat Photo"
• Have a field in the meta data marking it as deleted
• Back up the Tridion database periodically

Each one has it's pros and cons. Is there a solution that is considered "best practice"? How do you deal with deleting content? Is there a feature in Tridion that could help?

Answer 1

The philosophy of SDL Tridion in this is; when an item is not in use (a Component is not on a Page or a Page is not Published), it can be disregarded, and thus deleted.

So there is a protection layer against deleting items which are in use, and if they are not in use, deleting them means a complete cleanup action (including removing the history of that item, as if it never existed). There might be pages that still refer to the deleted item in a previous version, when you roll back to those versions, the link to the deleted item will be removed. For Schema's it is a bit different, but no need to go into so much detail now.

To prevent items from being really deleted by moving them in a safe location or renaming them, I tend to agree with you that it is in 99% of the times done to make editors feel good, rather than based on an actual need.

I personally never liked the move/rename strategy, since that tends to keep the content in a system which most of the time should just be removed. For customers that have a legal requirement to keep track of their content from past years, there is the Archive Manager. It doesn't store the CMS side, but the website only.

So as a solution to this problem I would suggest the following:

1. install content porter
2. make a regular (full) backup of your CMS database, something like weekly (you already do that right, but now keep them safe for a bit longer as recovery for deleted items)
3. simply have editors delete the content that is not in use, it is gone, but don't worry, we have a backup in case you absolutely need to have it back
4. when they ask for the content back, on a DEV machine, restore a database backup with a date before the item was deleted. use content porter to extract the item.
5. import the item back in your production environment

Now those are quite a lot of steps and also some work, but considering you will only need to do it in cases where it is absolutely required, it could be worth the effort.

The biggest downside of this approach in my view is the storage of your backups, you will need to discuss with your editors how long you need to keep a these archives (maybe you only need to keep one a month and not one for every week).

Answer 2

My 2 cents: Let's try to match your scenario with a typical web app using Database behind the scene (something similar to SDL Tridion CME + CM DB + Broker DB). Now, if there is a delete functionality on the web app, what it is supposed to do - Delete Forever. Now considering those 1% scenario, how do you architect to handle this scenario in a typical web app + DB solution? - There are many many solutions for it but may be the most common is have a proper Backup & Restore plan for your DB.

So my suggestion is to support such scenario instead of putting stress on precious resource, stick to the Backup & Restore process and have a proper plan (which may change on business context and requirement basis)