Last week I highlighted a sometimes overlooked Tridion feature, the “Schedule Publish Phases Separately” option in the publishing dialogue. In my post I mentioned that one issue I’d noticed with this feature was what happens when the rendering phase of publishing is successful but deployment fails. In situations like this you’re at risk of losing a lot of rendering, and if you were under a time constraint this can be a pretty big inconvenience. However, with some forethought and just a little creativity, you can recover and take advantage of all the rendering you’ve done.

To understand how we can get our rendered content, we need to understand a little bit of what happens to our content when it’s being deployed. Rendered content comes out of Tridion as a zip file containing all of the information the deployer needs to make your changes, whether they’re destined for the file system or the broker. It’s this zip file that’s the key for what we’re doing, so the first thing we need to do is find where Tridion is putting this file. We can do this by checking the cd_deployer_conf.xml file for your deployer. In here you should find an entry that looks like this:

<Queue>
<Location Path=”c:\tridion\incoming” WindowSize=”20″ Workers=”10″ Cleanup=”true” Interval=”2s”/>
</Queue>

This entry gives us two pieces of information we need. The location path, which is where Tridion is going to be placing the zip file we’re after, and the cleanup setting. Here’s where the forethought I mentioned comes in; to have any chance of recovering our rendered content we need to set the cleanup option to “false”. Otherwise the deployer will remove any old zip files once they’ve been fully processed, whether they succeed or fail. Once this has happened you’re out of luck, so I’d suggest if you’re scheduling phases separately it might be wise to set cleanup to false to be safe.

Now that we’ve checked our deployer configuration we can check out the incoming folder.

As you can see, there are a few folders created here. Ordinarily, you’d hope to see a folder for your successful publishes, but for now we’re concerned with failed publishes, so we’re going to focus on the failed folder. Looking in here we see that I have a zip file.

This was the result of a publish where the rendering and transport phases were successful, but the deployment failed (in my case because I deleted important nodes from my storage configuration file), which is the exact scenario we’re discussing. This zip file still has all the rendered content changes, it just hasn’t been properly deployed. Luckily, we can give the deployment another go, by simply dropping the zip file back in the incoming folder, where Tridion would ordinarily place it during publishing. Of course, we don’t want to do this until we’ve confirmed that the deployer is back online and we can publish successfully.

As soon as we drop our zip file back in the incoming folder it should get processed and end up in our successful folder, meaning the content has been successfully updated.

Crisis averted!