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?

2 Answers 2


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

  • Thanks Bart, very useful. I wasn't aware of the Content Porter. The process we currently have is similar to what you describe, I use core service to move content between instances. I will take a look at the Content Porter. Commented Nov 13, 2013 at 9:31
  • The biggest disruption to this type of restore would be changes to dependencies. Bringing back content from a time that has the same BluePrint setup and unchanged schemas is easy. If authors need pages or content after schemas, paths, or other dependencies have changed, you'll want to confirm how much to bring back. Think of content porter as a very fast CMS user (who will complain if trying to create something with "prerequisites" missing). Commented Nov 13, 2013 at 18:33
  • As Alvin points out, using content porter to move actual content is always somewhat of a crapshoot. Regarding storage of backups, I would definitely recommend everyone have a long term storage plan in place for their backups, one that involves some sort of offsite storage of the backups and a rotation scheme such as weekly backups stored for 5 weeks, monthly's for 13 months, annuals forever. This is of course assuming you are not one of the many Tridion customers with backup/archiving storage requirements dictated by law. Commented Nov 13, 2013 at 20:18

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)

  • Is the precious resource the authors or the database? :-) Commented Nov 15, 2013 at 5:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.