It is often acknowledged that content needs to be reviewed by people who do not know Sitecore or do not work with Sitecore on a regular basis. To tackle this, we've outlined 3 details to keep top of mind during implementation:

A common client scenario is the need to send an internal URL to members of the team to allow them to preview content before it is live on the website. The scenario often includes the condition that there should not be a requirement for that user to log into Sitecore. 

For those familiar with Sitecore, Sitecore does have a built-in preview mode. The caveat with the preview mode is that you need to log into Sitecore to leverage it.

In Sitecore 7.2, Sitecore added support for pre-production publishing. You can read more about it, including how to configure it, directly from the Sitecore team over here.

Sitecore does a good job of explaining the implementation; however, there are a few additional pieces you should keep in mind:

1. Publication must still be fired to publish the item to the preview site

– even though you assign preview publishing targets on a workflow state. This is the classic case of an item being in a state that allows it to be published, but without a publication action, nothing happens. There are couple of ways we've approached this issue:

  • Content Authors have access to the publication menu and can manually trigger a publication. We don't often recommend this approach unless we are dealing with power users.
  • The preferred method, add publication actions to the workflow states and/or commands to target the preview publishing target. This means that the content is actively published as it is moved through workflow. The Content Author does not even need to know that this additional functionality is present, the content simply shows up in the preview site.

Below is a screenshot of a publication action configured on a state. Note how the targets parameter scopes the publication to the preview pre-production site only. There is a performance gain by doing this, since at this stage there is no need to add overhead of publishing to all environments since we know we only want to publish to the preview environment.

3 Sitecore Pre-Production Publishing details

2. Don’t forget about related items!

Remember, a Sitecore page's content is the sum of its many parts. If you want someone to preview your content, it is also important to publish the page's related items since a typical page's content is assembled by components and datasources. Note in the screenshot above that related=1 is included in the parameters to ensure all related items are published to the preview site as well. Keep in mind, this assumes that those items are all in a state that can be published to the preview site.

If you want to read more about component publishing, you can check out this post: Sitecore publishing & the component conundrum

3. Content may edits occur without moving an item through workflow

All of our scenarios above make a fairly big assumption that content only needs to be previewed after a workflow action is performed. A Content Author may create/edit content in a workflow state and want feedback on that content before moving it through workflow. In such a scenario, here are few ways to possibly tackle this issue:

  • As noted previously, Content Authors can be granted access to Sitecore publishing to manually publish their content. Again, this approach is only advisable with system power users.
  • Create an __OnSave command on the workflow. An __OnSave command fires every time a Content Author hits save. This command would house a preview auto-publish action that would be fired every time the Content Author clicks the save button. Although functional, this implementation can create a chatty system that may adversely affect performance. 
  • Create a Preview command in the workflow that the user can manually fire. This command references the current state meaning you are not advancing the item through workflow. Much the same as the __OnSave command except the user must manually choose to fire it, rather than it being fired automatically. The challenge with this approach is simply human behaviour and remembering to fire it.

There you have it, a few additional pre-production publishing implementation details to keep in mind.

comments powered by Disqus