Press enter to see results or esc to cancel.

Setting up content staging

Some time ago Sitecore offered the staging module, but since 6.3 it isn’t available anymore. Recently, one of our clients asked for such functionality and I thought we could easily provide this by simply adding a publishing target. In general, this proved to be true and the solution works great, but there are some things you should know to create a fully independ content staging environment, in which the indexes play an important role.

Why content staging?

Having a preview function in Sitecore, some people wonder why you would need a separate staging environment. The answer is equally logical as surprising. Because Sitecore let’s you preview the page in the way it would be presented after a publish action, it respects the publish restrictions like date ranges and the non-publishable status of a version or an item. That’s nice, and by design, but we always teach content editors to make new content unpublishable until they want to publish it, to prevent colleague editors from accidentially publishing their unfinished content. Stalemate! You cannot preview your changes unless you’ll make your item publishable, but you do not want to yet, because it is still in preview..

Using a separate content staging environment, we let editors publish their content to a separate website (where it is publishable), without any publish restrictions or the risk of publishing content publicly too early in the process.

The solution

We will create a separate content staging site for content editors in this blog post, by adding a publishing target and a separate set of indexes for this publishing target.


We will only set this up for the production environment, so the test and acceptance environment will not be changed. They keep their single publishing target. Furthermore, having a content management server and multiple delivery servers, this content staging environment is only applicable for the content management server. So that’s our target environment: the content management server within the production environment needs an extra content staging website.

 What it takes

1) Duplicate your web database and rename it with a _Staging postfix and add a new connection string to your ConnectionStrings.config file accordingly:

2) Add a new database definition to your databases node in the Web.config. The id of this node must be equal to the name of your connection string node:

3) Add a publishing target item in your “system/Publishing targets” folder in the master database. You can point towards the actual database via the same id or name as mentioned in the previous steps:



4) Add an alternative site node to access the staging environment, be sure to change the database property. If you have more sub domains or websites you want to stage, you can include new entries for those sites as well:

Of course, you can configure your HTML cache, HTML and data cache sizes the way you’re used to or like best; these examples only show what’s needed for the creation of the staging environment and use the basic Sitecore configuration as a starting point.

So, this basically creates the new publishing target and adds it to your Sitecore client in the following places. A new database:


And a new publishing target in all publishing dialogs:



But more importantly, when you click on “Change” in the Publish ribbon at the Restrictions chunk, you will see a list of checkboxes for each publishing target on the third tab:


Initially, those checkboxes are unchecked, meaning that the item will be published to all publishing targets by default. By selecting this publishing target, you will prevent other editors from accidentally publishing the item to the world wide web, without setting publish restrictions that prevent you from previewing the item.

If you now publish an item, the message you’ll see asks if you want to publish to “every publishing target”, but since this publishing action respects the publish restrictions, this actually means “to all allowed publishing targets”. Despite this message, the item will not be published to the Internet (web database):


You can now visit the staging website on your content delivery server and test your new content without any restrictions!


But we have one more challenge, as I explained in the introduction of this article: indexes. Our site uses indexes for overviews of data sources (data types, like news or products), it uses indexes for populating dropdowns and for building up the FAQ section for example. So we need to separate them too. It might not be the case for your implementation, at least to this extent, but indexes sure are an integral part of your website and I think this solution comes in handy for almost all site implementations.

5) The following step consists of adding a configuration file for the new staging index:

Let’s call this new file Sitecore.ContentSearch.Lucene.Index.Staging.config to accompany the already existing Core, Master and Web configs for Lucene.

6) … but as you can see, we’ve used a new publishing strategy in the above configuration, so this wouldn’t work without adding the following section to the Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config as a child of the indexUpdateStrategies node:

You have to define a new strategy for your staging database, because the onPublishEndAsync strategy is only watching the event queue from a single database, being the web database by default. So you have to copy that strategy definition and define your own strategy that points towards the new staging database. If you would have multiple publishing targets or databases besides the default web database, mind that you should add a strategy for each of them.

7) Add a SearchContext helper class to retrieve the index that belongs to the current context programmatically. I quickly threw together a class and property that return the currently applicable index, which comes in handy when you query the index a lot from your code:

You can now easily get to the index that belongs to your current context by typing:

 Targeting the content management server

8) As mentioned before, this staging environment shouldn’t be available on your delivery servers, nor should it be active on the test and acceptance environment (in our case). Since we are always using multiple specifically targeted builds in Visual Studio, we can add this line to build configurations of environments that do not need a staging version of the website:

Tip: we do not use the “Debug” and “Release” builds that VS defaults to, but we have a build type for each target enviroment, like “Development”, “Test”, “Acceptance”, “Production Management” for the content management server(s) and “Production Delivery” for all delivery servers. This way you cannot only maintain multiple Web.config (and other config) translations to alter your config files per target server (like the different URL’s in the sites section), but you can also keep all those deltas within your version control system of choice and you can also add specific project configurations for each environment.

You can now remove the new site node within the Web.config translations of the servers that do not need the staging environment:

This, of course, also applies to your connection string configuration.


As you can see, Sitecore is really flexible in setting up different content previewing strategies. A separate staging website, only available on your content management server, is easy to configure without having to setup a whole new server. This extensive blog post (it turned out a bit longer than I intended to..) should help you getting up and running pretty fast, but if you run into anything that isn’t complete, or compatible with your process, I would like to hear from you and I’ll see if I can improve my article.



Comments are disabled for this post