Today’s story about the People website publishing an obituary of Kirk Douglas death (he’s still very much alive) made me instantly think of two things:
1. It’s amazing these websites have content like this backed-up and ready to go.
2. They should have been using Tridion, there’s a load of ways in which this could have been prevented.
So whilst I’d like to talk more about the content strategy around number 1 (it’s actually quite brilliant and I wonder who else is already written up), I’m going to be talking more how you can save yourself this embarrassment using SDL Tridion.
So how do you stop content from being published? Well there’s a number of ways some are out-of-the-box, some you can build yourself. Note: there’s probably no right or wrong in all of these suggestions, I’m just highlighting that a CMS can provide a lot of ways to avoid embarrassing stuff like this.
Workflow
Workflow is essentially a way to ensure that content is approved before it is published. There’s a couple of flavours of this:
Custom Workflow
SDL Tridion ships with a Visio connector and a load of shapes that offer actions and decisions, allowing you build a simple (or an insanely complex) workflow process, you can also provide automations here, for example if content is approved, it could be automatically published.
Until this content item is ready to be published it is classed as ‘in workflow’ which actually hides the item from content users in the system. Â If a user can’t see it, they certainly can’t publish it. – phew!
Approval process workflow
This is a really simple version of workflow that you can attached to a publishing target, for example you can specify that only content specified ‘Ready for live’ will publish to this example target ‘Live':
This is pretty handy as you may wish to have your staging target configured for ‘Ready for Staging’ so editors can review the content for Kirk Douglas to ensure it looks perfect within the website and the content is written as it should be.
Structure Group Publishing
It’s possible to specify that a structure group cannot be published.  This is actually really handy, you can have your Kirk Douglas page in here and feel at ease that the content will never publish, even if a user attempts to publish it.  This is perhaps the easiest solution, but it’s not as flexible as using an Approval Status as you wont be able to publish the content to any publishing target should you wish to check out the page in a real website scenario.
Custom Implementation
If you’re going to down the custom development route, you’re going to need to configure this as part of your content model, in the example ‘obituary’ schema below, I’ve specified a field where a user can input the ‘living status’ of the person in question:
 by selecting either ‘Alive’ or ‘Death’s Door’ in the above we now have the following custom solutions available to us:
A Template Building Block (TBB)
A simple TBB could be written to check if the value of ‘Living Status’, if the value is not equal to ‘Dead’ then we can throw an exception, or even do something a little bit more aggressive like send the details of the user attempting to publish to their boss 
– either way i’d recommend throwing the exception. Â Here we can also check the target that we’re publishing, so if we’re publishing to ‘Staging’ we can chose to allow the page to publish.
Event SystemÂ
The event system can fire when a user performs the publishing action, we can wire up some code to check the value of ‘Living Status’ to check that the item is set to ‘Dead’ then we can choose to abort the publishing and email the boss again to let them know some content almost went out.
I’m sure there’s some other alternatives out there, Tridion has a number of APIs available and we’ve not even touched on the Content Delivery API (the API on the website end) so that the website could choose not to display content in the event is has been published and not flagged as ‘Dead’.
Please feel free to drop some alternative suggestions in the comments.
As an added precaution Tridion (other CMSs do exist but are often less-flexible) could be configured to use another extension point such as a GUI Extension to check, when the user clicks the save button, that they are sure this person is dead (heaven forbid they make the grave mistake of getting this wrong 😉 ). Such that when the user clicks ‘Save’ we can pop a dialogue box asking ‘Are you really really sure this person has passed away?’ … giving the user that one last chance to back out.
And a final extension… have some custom code check with, say, an obituary webservice that someone is ‘registered’ before accepting the Save or the Publish event – you’d need to consider in the Content Model if you need to map the name, DOB and/or other fields to the relevant service as other Kirks make exist (or have existed).