In the previous blog article on this topic, I showed the topology for creating a WCM preview server. In that article I also showed how to automatically move content from the "draft" stage to the "publish" stage so that the content could be viewed "in context" on the preview server. The automatic movement was done via a JMS listener attached to the subscription event.
However, there is now a better and "out of the box" way to achieve that automatic movement without writing a JMS listener. It involves the creation of a new workflow stage and disabling that stage in the proper places.
This new method will rely on a new 4 stage workflow to achieve "in context" preview. The topology pictures in the previous article is still correct; there will be an authoring server, a preview server and the production rendering server. There might be other servers as well, but they are not relevant to the discussion here.
The standard content work flow will have at least 4 stages:
2. Preview - Publish (with a corresponding publish action called "previewPublish")
3. Production - Publish (with a corresponding publish action called "productionPublish")
The trick is that on the authoring system the publish action for the second stage, "Preview - Publish", is disabled. I will describe below how that is done. That action is enabled on the preview sever. It doesn't actually matter how the production server is set (since it only gets live items); but if you are paranoid you can disable the "previewPublish" action on production as well.
All draft content is syndicated to the preview server (as opposed to only "live" items). Only "live" items are syndicated to the production rendering server. So, on the preview server, content will automatically execute the "publish" action from stage 2. Since the publish action for stage 2 is disabled on the authoring server, the content will not publish on the authoring server until it is moved to stage 3 (Production - Publish). The content cannot, therefore, be syndicated to the production rendering servers until it reaches stage 3.
If issues or defects are found on the preview server with the new content, it can reverted back to the draft stage on authoring. If no issues are found, the new content can be moved along to the next stage (Production - Publish) and the reviewer wishes for content to be rendered in production.
Disabling the "previewPublish" Action
Disabling the previewPublish action is accomplished by going into the WAS Administrator console. That would be a Deployment Manager in a cluster or the WAS Admin console if standalone.
In the "WCM_WCMConfigService" Resource Environment Provider, create a new name "disableWorkflowAction" with a value of the action name; in this case "previewPublish". Restart the server. That action is now disabled. Moving an item to that stage is effectively a "no-op".
Due to a soon to be released CF in V8.5, both V8.5.x and V8.0.x should both have a time offset in the workflow action on all of the relevant scheduled move actions. You should edit each workflow action in 8.0.x and set the offset to 1 minute after the specified date. Consult this IC page for details. You need to create the work flow action with a "Date entered stage" plus an offset of 1 minute.
If you don't, you can get in a situation whereby the actions on the draft item are executed such that the content to be pushed immediately goes to the published stage. During the syndication process, this occurs within memory as a performance optimization on the subscriber. And when the item is finally ready to be committed to the database, it is already in a published state and will clash with the existing published item. This causes an unexpected deletion of the item due to an objectID clash.
Credit for this new method goes to Chet Tuttle for the idea and Kevin DeKorte for testing it with me.