Disaster Recovery region in Azure for Sitecore 9.x

In case you are worried about an Azure region going down and want to make your Sitecore Azure infrastructure not dependent on a single region, deploying a region for disaster recovery could be an option…

Obviously, depending on the complexity of your website, Sitecore resilience may be the minor problem in case of a region failure and further conversation should be taken to ensure that your infrastructure and data can be available across multiple regions….

As you can imagine, if your site is relying on Sitecore Analytics for personalization features your task won’t be trivial due to the Sitecore architecture, however, is a fair assumption and common practice to have analytics turned off on the DR region…

A typical DR region for Sitecore, would need the following elements:

  • Content Delivery server
  • WebDatabase
  • Redis cache (you could consider switching off if budget is an issue)
  • Search (assuming that is mandatory to have search available in case of DR)

My recommendation to provision a DR region on Azure PAAS would be to use the XM scaled scripts to provision a new environment in your favourite “backup” region and then delete the unrequired resources:

  • Identity server
  • Content Management Server
  • Master Database

The following Powershell script shows how to run the clean up of these resources…


How to hide Publish Site in Sitecore

This is one of my top tricks on Sitecore…

Sitecore comes OOB with Publish Site feature, but in reality, a “normal” content author will never need that button, and within my personal experience, several times Sitecore Administrators have forgotten that button enabled, and Content users have published the site thinking to publish a single Sitecore item….

Therefore my recommendation is to remove the permission of Publish Site button for standard content authors to avoid performance issues and avoid unrequired issues…

The simpler way to remove the Button is via permission at the following path within the three….



Sitecore Form QuickStart


As you probably are aware within Sitecore 9, WFFM was deprecated and Sitecore Form was introduced…

On the base that I do not particularly believe in Marketers building forms, I had fun migrating a few simple forms as part of the migration that I was running, but I do not think that would be an achievable task for dummy content editors/marketers…

First challenge come with the list of forms, on Sitecore 9, I had to rebuild indexes few times to get the valid list of my Sitecore forms (this KB will help you… https://kb.sitecore.net/articles/891856 in my case my user was messing around with languages)


Form Elements are the common elements that you will use and 90% will be basic form elements https://doc.sitecore.com/users/91/sitecore-experience-platform/en/the-basic-elements.html


Styling a form, in theory, is really simple, see the image:


but in practice, if you need to change the markup, and in my experience, you will have to, the simpler way is going and editing directly the CSHTML of the view…  You can find these files in Views/FormBuilder/FieldTemplates

But obviously, you are free to extend your own fields, here you can find further information on how to do it: https://doc.sitecore.com/developers/90/sitecore-experience-manager/en/walkthrough–creating-a-custom-form-element.html 

Once you have created your first Sitecore form, it is time to add it to your page…

Your page MUST have an MVC Layout, and then you can use a Form Rendering…


Sitecore 9.1 initial release – what is new!

In the case you did not know, Sitecore 9.1 initial version has just been released, you can download it from:


and that’s what you need to know to consider upgrading to this version:

Key improvements:

  • Performance improvements (especially cold start-up time of CMS)
  • Bringing back support for Mongo to store Analytics
  • SIF 2.0 in the case you were not happy with the first version of SIF 🙂
  • Identity server (major internal architectural change across Sitecore products)
  • Cortex (Machine learning for content and analytics)
  • Content Tagging
  • Personalisation suggestions (still basic one, but it helps marketeer to understand the best way to personalise and optimise content to drive conversion)
  • JSS is finally with us 🙂
  • Generic SXA improvements
  • Native support to index binary files such as PDF (finally!!!!)
  • support for Solr 7.2.1


I have just installed it and it is hard to say my favorite one, but if I have to pick one, is certainly around CORTEX feature and what will allow developers and marketers to achieve…  I have also heard very positive feedbacks on performances improvements and that’s good to see the product evolving in the right direction…

you can read more about Sitecore 9.1 from Pieter’s blog here: http://www.pieterbrinkman.com/tag/sitecore-9-1-whats-new/

Sitecore Audit Trail – the easy way

One feature that my customers always ask me about, is the ability to know who as changed that specific page and when….

There are several reasons for this magic question, for example, the legal aspects of what you wrote on your website at a specific moment in time, could be used by customers to sue your client… a classic example is the T&C or privacy policy page that contains content provided by the legal team for an obvious reason…

In the case you are not aware and you think that customers forgot what you wrote, they may use the https://web.archive.org a kind of web history that keep track of most of the changes…

obviously, that’s a public tool, and unless you have not written the author name in the meta tag (quite unusual) you won’t know who changed that page…

Sitecore comes in your help with two OOTB approaches:

  1. Sitecore versions combined with Workflow will force your content author to create a new version of the item everytime that something got changed on an item so that you can have a more granular view of what has been changed from who… unfortunately versions do not play very well with publishing and obviously it increases the complexity and is harder to know if a specific version when exactly was published and when it was overseeded… in addition workflow are notoriously complex and make the team upset…
  2. History table, this is an OOTB feature being in place from Sitecore 6 until 9 (I think…) that keep all the changes that authors do to any item… Adam in his blog https://blog.coates.dk/2015/05/27/sitecore-history-table-how-to-control-how-long-the-entries-are-kept/ explain to you how to configure the duration period for keeping items in the history table… Note that from the history table there is no tool or UI that allow you to see what happened, but you need to go in the table on SQL and look for what you were searching for… obviously keeping history on the history table for 2-3 years, if you have a big team, it is going to affect the performance of your Sitecore instance…

However, my recommendation, in case you are on an enterprise project and workflow and versions are not an option is to log all the changes into a log file and then process the log file content in a NO SQL data repository… this approach comes with several advantages:

  1. it is scalable, you can have as many changes you want…
  2. it won’t affect performances of the CMS and it won’t pollute your DB
  3. it gives you data structured as you want… so that you can build your UI to see items changed today, or who is the content author that make more changes, review all the changes done from one user…
  4. Ability to have a free text search, eg. find out who has done any mis-spell and when on the web site…
  5. when an item was published and the content of the item
  6. it is super simple to hook into your code

the simpler way to get your logging hooked up is described in this brilliant blog: http://info.exsquared.com/ex-squared-blog/logging-changes-in-sitecore-made-by-content-authors

basically it attach to some Sitecore events, and use log4net to log on a text file, obviously you can configure it also on a different appender….

Next step, would be reading the Txt file with the audit information and upload the content on a NoSQL data structure for making it simple to search on…

Happy Logging, and end of excuses for content authors who update dodgy content 🙂

Sitecore Delete Published Items

Within Sitecore, the Delete button is the bigger mystery for non-Sitecore experts….

Everybody assumes that an author going in the Authoring console and Deleting an item, the item got deleted and Unpublished… but unfortunately, this is not the case….

In the case you want the item to be deleted and unpublished, you have to delete the item and have to publish the parent of the item — with sub-items —  just to remove it from a target database…

IMO Sitecore standard behavior should be to delete and unpublish, automatically but unfortunately this is not the case…

There are several possible solutions to this issue and this blog explain the possible customisation that you could do to mitigate the issue…

Introducing a new button:


Configuring Workflows: http://www.nonlinearcreations.com/Digital/how-we-think/articles/2016/02/Item-deletion-and-immediate-publication-in-Sitecore-8-and-8-1.aspx

My favorite option is to extend the Item Delete event to remove the item from the publishing targets as well…

This code explains how to do it…


 public void OnItemDeleted(object sender, EventArgs args)
            Item deltedItem = Event.ExtractParameter(args, 0) as Item;
public CleanUp(string itemId)

  // Get all publishing targets
  var publishingTargets = Sitecore.Publishing.PublishManager.GetPublishingTargets(item.Database);

  // Loop through each target, determine the database, and publish
  foreach(var publishingTarget in publishingTargets)
    // Find the target database name, move to the next publishing target if it is empty.
    var targetDatabaseName = publishingTarget["Target database"];
    if (string.IsNullOrEmpty(targetDatabaseName))

    // Get the target database, if missing skip
    var targetDatabase = Sitecore.Configuration.Factory.GetDatabase(targetDatabaseName);
    if (targetDatabase == null)

      DeleteItemInDatabase(targetDatabaseName,  itemId);


private static void DeleteItemInDatabases(IEnumerable databases, string itemId)
   foreach(string database in databases)
                DeleteItemInDatabase(database, itemId);
private static void DeleteItemInDatabase(string databaseName, string itemId)
      Database database = Factory.GetDatabase(databaseName);
private static void DeleteItem(Item item)
            if (Settings.RecycleBinActive)

MVT using Publishing Targets

I have been involved in a few enterprise projects where unfortunately I cannot easily enable XDB architecture and fully leverage Sitecore capabilities for MVT testing, therefore, it comes to the idea of getting creative with what I got and find an alternative way of helping the marketing team testing the effectiveness of their new content and the new functionality that they have in mind….

I guess that it is pointless to mention, the advantages of the Testing culture and the idea behind fail quickly… however all these principles & features are covered with Sitecore MVT and in case you have XDB enabled in most of the cases I would strongly suggest you to use the built-in features…

In the specific project circumstances, I have been asked to test the effectiveness of some new “label” within the Booking funnel to see the impact on conversion….

For the Tracking, we were not using XDB and Sitecore analytics but Google Analitycs do a good job tracking Conversion and events…

For trying the different variants, I have split the sitecore change across the 4 Publishing Targets that I have for scalability reasons…  you can read more about publishing target here

My architecture requires a CDN / Proxy (Akamai in my specific case) to split the traffic across my 4 Content Delivery servers and have a publishing target different for each of the Content Delivery server…

Each Variant can be assigned to one or multiple CDs so that you can have a simple A/B testing or a more complex MVT….

With this architecture and this setup, I was able to allow the marketing team to test their content experiment and help them to find the best variation and the winning experiment even without having to configure Sitecore analytics, XDB and so on, but just leveraging the existing architecture….

The change that you would need to implement is to send via a custom dimension to GA the name of the Content Delivery server for each page view / event / transaction…

the code to track the CD, would be as simple as:

ga('set', 'cd1', 'Level 1');

obviously, this approach comes with some trade-off….  since Marketing users cannot really know which test is running and risk to override a running test doing a simple content publishing…. Also from the reporting point of view, you would need to keep track of the publishing that your content team is doing to be sure that anything else is affecting your experiment…. Also, need to remember to switch off your experiments and align all the content on the publishing targets to have a consistent web site….


Untitled Diagram