{"id":2068,"date":"2015-02-13T15:57:53","date_gmt":"2015-02-13T15:57:53","guid":{"rendered":"http:\/\/sitecore.robhabraken.nl\/?p=2068"},"modified":"2015-05-02T08:10:18","modified_gmt":"2015-05-02T08:10:18","slug":"setting-up-content-staging","status":"publish","type":"post","link":"https:\/\/www.robhabraken.nl\/index.php\/2068\/setting-up-content-staging\/","title":{"rendered":"Setting up content staging"},"content":{"rendered":"

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\u00a0could\u00a0easily\u00a0provide 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\u00a0content staging environment, in\u00a0which the indexes play an important role.<\/p>\n

Why content staging?<\/h3>\n

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\u00a0restrictions\u00a0like 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\u00a0want to publish it, to prevent colleague editors from accidentially publishing their unfinished content.\u00a0Stalemate! 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..<\/p>\n

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.<\/p>\n

The solution<\/h2>\n

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.<\/p>\n

Demarcation<\/h4>\n

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\u00a0server and multiple delivery servers, this\u00a0content\u00a0staging 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.<\/p>\n

\u00a0What it takes<\/h4>\n

1) Duplicate your web database and rename it with a _Staging postfix\u00a0and\u00a0add a new connection string to your ConnectionStrings.config file accordingly:<\/p>\n

<add name=\"staging\" connectionString=\"user id=sitecore;password=secret;Data Source=(local)\\SQLEXPRESS;Database=DemoSitecore_Staging\"\/><\/pre>\n
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:<\/p>\n
<!-- Staging -->\r\n<database id=\"staging\" singleInstance=\"true\" type=\"Sitecore.Data.Database, Sitecore.Kernel\">\r\n  <param desc=\"name\">$(id)<\/param>\r\n  <icon>Network\/16x16\/earth.png<\/icon>\r\n  <securityEnabled>true<\/securityEnabled>\r\n  <dataProviders hint=\"list:AddDataProvider\">\r\n    <dataProvider ref=\"dataProviders\/main\" param1=\"$(id)\">\r\n      <disableGroup>publishing<\/disableGroup>\r\n      <prefetch hint=\"raw:AddPrefetch\">\r\n        <sc.include file=\"\/App_Config\/Prefetch\/Common.config\" \/>\r\n        <sc.include file=\"\/App_Config\/Prefetch\/Webdb.config\" \/>\r\n      <\/prefetch>\r\n    <\/dataProvider>\r\n  <\/dataProviders>\r\n  <proxiesEnabled>false<\/proxiesEnabled>\r\n  <proxyDataProvider ref=\"proxyDataProviders\/main\" param1=\"$(id)\" \/>\r\n  <archives hint=\"raw:AddArchive\">\r\n    <archive name=\"archive\" \/>\r\n    <archive name=\"recyclebin\" \/>\r\n  <\/archives>\r\n  <Engines.HistoryEngine.Storage>\r\n    <obj type=\"Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel\">\r\n      <param connectionStringName=\"$(id)\" \/>\r\n      <EntryLifeTime>30.00:00:00<\/EntryLifeTime>\r\n    <\/obj>\r\n  <\/Engines.HistoryEngine.Storage>\r\n  <cacheSizes hint=\"setting\">\r\n    <data>20MB<\/data>\r\n    <items>125MB<\/items>\r\n    <paths>5MB<\/paths>\r\n    <itempaths>100MB<\/itempaths>\r\n    <standardValues>4MB<\/standardValues>\r\n  <\/cacheSizes>\r\n<\/database><\/pre>\n
3) Add a\u00a0publishing 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:<\/p>\n
\"publishing-target\"<\/p>\n
 <\/p>\n
4)\u00a0Add an alternative site node\u00a0to 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:<\/p>\n
<site name=\"website_demo_staging\" hostName=\"www.staging.demo.local\" targetHostName=\"www.staging.demo.local\" virtualFolder=\"\/\" physicalFolder=\"\/\" rootPath=\"\/sitecore\/content\" startItem=\"Demo\/Homepage\" database=\"staging\" domain=\"extranet\" allowDebug=\"true\" cacheHtml=\"false\" htmlCacheSize=\"10MB\" registryCacheSize=\"0\" viewStateCacheSize=\"0\" xslCacheSize=\"5MB\" filteredItemsCacheSize=\"2MB\" enablePreview=\"true\" enableWebEdit=\"true\" enableDebugger=\"true\" disableClientData=\"false\" language=\"nl-NL\" \/><\/pre>\n
Of course, you can configure your HTML cache, HTML and data cache sizes the way you’re used to or like best; these\u00a0examples only show what’s needed for the creation of the staging environment and use the basic Sitecore configuration as a starting point.<\/p><\/blockquote>\n
So, this basically creates the new publishing target and adds it to your Sitecore client in the following places. A new database:<\/p>\n
\"new-database\"<\/p>\n
And a new publishing target in all publishing dialogs:<\/p>\n
\"publish-item\"<\/p>\n
 <\/p>\n
But\u00a0more 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:<\/p>\n
\"publishing-settings\"<\/p>\n
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\u00a0accidentally publishing the item to the world wide web, without setting publish restrictions that prevent you from previewing the item.<\/p>\n
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\u00a0publishing targets”. Despite this message, the item will not<\/strong> be published to the Internet (web database):<\/p>\n
\"publish-message\"<\/p>\n
You can now visit the staging website on your content delivery server and test your new content without any restrictions!<\/p>\n
Indexability<\/h4>\n
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.<\/p>\n
5) The following step consists of adding a configuration file for the new staging index:<\/p>\n
<configuration xmlns:patch=\"http:\/\/www.sitecore.net\/xmlconfig\/\">\r\n  <sitecore>\r\n    <contentSearch>\r\n      <configuration type=\"Sitecore.ContentSearch.ContentSearchConfiguration, Sitecore.ContentSearch\">\r\n        <indexes hint=\"list:AddIndex\">\r\n          <index id=\"sitecore_staging_index\" type=\"Sitecore.ContentSearch.LuceneProvider.SwitchOnRebuildLuceneIndex, Sitecore.ContentSearch.LuceneProvider\">\r\n            <param desc=\"name\">$(id)<\/param>\r\n            <param desc=\"folder\">$(id)<\/param>\r\n            <!-- This initializes index property store. Id has to be set to the index id -->\r\n            <param desc=\"propertyStore\" ref=\"contentSearch\/databasePropertyStore\" param1=\"$(id)\" \/>\r\n            <configuration ref=\"contentSearch\/indexConfigurations\/defaultLuceneIndexConfiguration\" \/>\r\n            <strategies hint=\"list:AddStrategy\">\r\n              <!-- NOTE: order of these is controls the execution order -->\r\n              <strategy ref=\"contentSearch\/indexUpdateStrategies\/onPublishEndAsyncStaging\" \/>\r\n            <\/strategies>\r\n            <commitPolicyExecutor type=\"Sitecore.ContentSearch.CommitPolicyExecutor, Sitecore.ContentSearch\">\r\n              <policies hint=\"list:AddCommitPolicy\">\r\n                <policy type=\"Sitecore.ContentSearch.TimeIntervalCommitPolicy, Sitecore.ContentSearch\" \/>\r\n              <\/policies>\r\n            <\/commitPolicyExecutor>\r\n            <locations hint=\"list:AddCrawler\">\r\n              <crawler type=\"Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch\">\r\n                <Database>staging<\/Database>\r\n                <Root>\/sitecore<\/Root>\r\n              <\/crawler>\r\n            <\/locations>\r\n          <\/index>\r\n        <\/indexes>\r\n      <\/configuration>\r\n    <\/contentSearch>\r\n  <\/sitecore>\r\n<\/configuration><\/pre>\n
Let’s call this new file\u00a0Sitecore.ContentSearch.Lucene.Index.Staging.config<\/strong> to accompany the already existing Core, Master and Web configs for Lucene.<\/p>\n
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\u00a0Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config as a child of the indexUpdateStrategies node:<\/p>\n
<onPublishEndAsyncStaging type=\"Sitecore.ContentSearch.Maintenance.Strategies.OnPublishEndAsynchronousStrategy, Sitecore.ContentSearch\">\r\n  <param desc=\"database\">staging<\/param>\r\n  <!-- Whether or not a full index rebuild should be triggered when the number of items in the EventQueue exceeds the number specified \r\n        in Config.FullRebuildItemCountThreshold. -->\r\n  <CheckForThreshold>true<\/CheckForThreshold>\r\n<\/onPublishEndAsyncStaging><\/pre>\n
You have to define a\u00a0new\u00a0strategy for your staging database, because the\u00a0onPublishEndAsync strategy\u00a0is 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.<\/p>\n
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\u00a0that return the currently applicable index, which comes in handy when you query the index a lot from your code:<\/p>\n
public static class SearchContext\r\n{\r\n    public static string GetSearchIndex\r\n    {\r\n        get\r\n        {\r\n            var index = \"sitecore_web_index\"; \/\/ default\r\n\r\n            if (Sitecore.Context.Database != null && !string.IsNullOrEmpty(Sitecore.Context.Database.Name))\r\n            {\r\n                switch (Sitecore.Context.Database.Name.ToLowerInvariant())\r\n                {\r\n                    case \"master\":\r\n                        index = \"sitecore_master_index\";\r\n                        break;\r\n                    case \"staging\":\r\n                        index = \"sitecore_staging_index\";\r\n                        break;\r\n                }\r\n            }\r\n            return index;\r\n        }\r\n    }\r\n}<\/pre>\n
You can now easily get to the index that belongs to your current context by typing:<\/p>\n
ContentSearchManager.GetIndex(SearchContext.GetSearchIndex);<\/pre>\n
\u00a0Targeting the content management server<\/h4>\n
8) As mentioned before, this staging environment shouldn’t be available on your delivery servers, nor should it be active on the\u00a0test and acceptance environment (in our case). Since we are always using multiple specifically targeted builds in Visual Studio, we can\u00a0add this line to build configurations of environments that do not need\u00a0a staging version of the website:<\/p>\n
<ExcludeFilesFromDeployment>App_Config\\Include\\Sitecore.ContentSearch.Lucene.Index.Staging.config<\/ExcludeFilesFromDeployment><\/pre>\n
Tip:<\/strong> we do not use the “Debug” and “Release” builds that VS defaults to, but we have a build type for each target enviroment,\u00a0like “Development”, “Test”, “Acceptance”, “Production Management” for the content management server(s) and “Production Delivery” for all delivery servers.\u00a0This way you cannot only maintain multiple Web.config (and other config) translations to alter your config files per target server (like the different\u00a0URL’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.<\/p>\n
You can now\u00a0remove the new site node within the Web.config translations of the servers that do not need the staging environment:<\/p>\n
<site name=\"website_demo_staging\" xdt:Transform=\"Remove\" xdt:Locator=\"Match(name)\"\/><\/pre>\n
This, of course, also applies to your connection string configuration.<\/p>\n
Conclusion<\/h2>\n
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\u00a0run 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\u00a0my article.<\/em><\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
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\u00a0could\u00a0easily\u00a0provide 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 […]<\/p>\n","protected":false},"author":9,"featured_media":2151,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[39],"tags":[40,42,43,41,21,20],"class_list":["post-2068","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to","tag-content","tag-how-to","tag-indexes","tag-preview","tag-publishing","tag-sitecore"],"jetpack_featured_media_url":"https:\/\/www.robhabraken.nl\/wp-content\/uploads\/2015\/01\/scaffolding.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/posts\/2068","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/comments?post=2068"}],"version-history":[{"count":74,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/posts\/2068\/revisions"}],"predecessor-version":[{"id":2149,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/posts\/2068\/revisions\/2149"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/media\/2151"}],"wp:attachment":[{"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/media?parent=2068"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/categories?post=2068"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.robhabraken.nl\/index.php\/wp-json\/wp\/v2\/tags?post=2068"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}