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:

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

Sitecore 8 Profiling Visitors for Beginners

The first step to deliver Personalisation for Anonymous Visitors of your web site is knowing your Visitors through the pages that they have visited…

Sitecore allow you to Profile your customers interests and behavior through the Profile framework where you can define the Profile Keys, Profile Cards and PatternMatch Cards.

In order to be able to fully benefit from this feature, you need to have XDB & Analytics enabled so that you can fully track your customer behavior.




As you can see, there is not always a clear classification, but often the definition touch multiple dimensions…

Once that you have defined your Profiles, it is time to TAG your content so that you can classify your visitors….



Once that you have defined your Profiles and Tagged your content you can easily identify your Anonymous visitors and start delivering personalized content based on the interest and behavior that you were able to track….

Some example of personalisation rules are reported here…





Integrate AKAMAI with Sitecore to deliver GeoIP personalisation

As probably not everybody knows AKAMAI offer as well GEOIP resolution capabilities based on MaxMind database.

OOTB Sitecore offer GeoIP personalisation based on their cloud service that consume MaxMind database, Sitecore charge customers for this service and in case you are not using Akamai, this could be an easy and effective way to have GeoIP in place without writing any code but just paying for Sitecore GeoIP service.

Therefore if you are already using AKAMAI and Sitecore GeoIP personalisation you should consider following this route…

In order to get AKAMAI to deliver personalisation you need to enable Content Targeting via property manager obviously you need to ensure that Content Targeting is included within your AKAMAI contract.


Once that you have this in place, you will simply get GeoIp information injected within your http header that should look like:

X-Akamai-Edgescape: georegion=263,country_code=US,region_code=MA,city=CAMBRIDGE,dma=50 6,pmsa=1120,areacode=617,county=MIDDLESEX,fips=25017,lat=42.3933,l ong=-71.1333,timezone=EST,zip=02138-02142+02238-02239,continent=NA ,throughput=vhigh,asnum=21399

In order to configure Sitecore to read the following header instead than calling the original service, it is recommended to implement your custom lookup provider. Implementing your custom lookup provider is fairly simple since you need to inherit from Sitecore.Analytics.Lookups.LookupProviderBase and override WhoIsInformation to read your information from the HttpHeader and return the information as within the whoIsInformation object.

using Sitecore.Analytics.Lookups;
using Sitecore.Configuration;
using Sitecore.Diagnostics;
using System;
using System.Web;
using System.Web.Hosting;

namespace xxx.Akamai.LookupProvider
    public class AkamaiGEoIpProvider : LookupProviderBase
        public string ExtractValue(string keyName, string headerValue)
            //ToDo: nice regex to Parse Value

        public override WhoIsInformation GetInformationByIp(string ip)

            WhoIsInformation information = new WhoIsInformation();
            var headerValue = Request.Headers["X-Akamai-Edgescape"];
            information.Country = ExtractValue("country_code", headerValue);
            information.PostalCode = ExtractValue("zip", headerValue);
            //etc etc to set all the value for the information object

            return information;

Once that you have implemented your lookup provider you would need to regiter within the web.config your own provider

        <patch:attribute name="defaultProvider">akamai</patch:attribute>
          <add name="akamai" patch:after="processor[@type='Sitecore.Analytics.Lookups.MaxMindProvider,Sitecore.Analytics']" type="xxx.Akamai.LookupProvider.AkamaiGEoIpProvider,xxx.AkamaiGeoIp">/>

Useful resources to consider when you implement a custom lookup provider are the following ones:

Sitecore GeoLiteProvider:

CircuitBreaker design pattern:

Akamai Edgescape Parser:

Sitecore 8 Personalisation rules for beginners

Probably most of you are already aware of what it means personalisation in Sitecore 8 but in case you have not heard about it, this post will give you a better idea of how Sitecore has implemented it…

Within Sitecore the easier way to deliver a Personalised experience is through Personalisation Rules at Rendering level.

The starting point is defining a page with one rendering and click on the Personalise button


From here you will be able to select your rule:


Once that you have selected your rule, you will than be able to select the actions associated to the conditional rendering that could be setting a different datasource, or Hiding the rendering or displaying a different rendering


Sitecore 8 allows the Developer to customise Rules but OOTB it comes with the following rules to personalise your content:

Sitecore Rules are grouped in the following logical categories:

Campaigns: Condition based on the campaign defined, newsletter, landing page, etc
Channel: Condition based on the channel, web, mobile etc
Date: Condition based on the date & time of the visit
Device: Condition based on Device capability (it rely on NetBiscuit service charged separately)
GeoIp: Condition based on user geolocation (rely on Sitecore service based on MaxMind, charged separately
Outcomes: Condition based on the engagement plan status and outcomes triggered
Security: Condition based on user security context, eg.  is anonymous etc
Social : Conditions based on Social network information, in the case the user has a federated identity via social network can be used to personalised on the profile information
Visit: Condition based on the current visit (eg. goal / event, campaign, previous interactions, engagement value, search keyword etc)
Visitor: Condition based on previous interactions (require analytics to be enabled)



Sitecore as a Service… is it really a good idea?

Sitecore as a Service is the first thing that would come to the mind to a Developer / Architect who is not familiar with Sitecore.

The idea is pretty simple, the non Sitecore developer think: “I do not like products, I do not know how to use Sitecore, I do not want really use it, but I have to… therefore I am limiting the dependency and the role of Sitecore within my architecture”

Unfortunately most of Developers still understand Sitecore as a CMS rather than a Digital Martketing Suite and cannot really get the difference and the benefit of it…

If you have heard about this consideration and you have been in similar situation, this is the right post for you….

As you probably know, Sitecore architecture is pretty flexible and allow you to use Sitecore in a variety of way, consuming Sitecore through the OOTB web api to manage the items or write a custom webApi just to serve content items as a web service or a rest endpoint serving Json is fairly simple and you can find plenty of documentation about it. Other way to access your content structure is through the use of Dictionaries or customising your publish pipeline to create static Json/JS files is also a simple way to consume the content information.

The following approaches are considered a quick win for “non Sitecore developers” who think I will be in control of my website / application, Sitecore will just give me HTML via Json and I will do the rest without having to tunnel all my request through Sitecore pipeline…

Reality for Sitecore people is very different…. the reason for tunnelling all your request through Sitecore pipelines are multiple ones and before going for the “content as a service” should be really considered to tunnel all your request through Sitecore for the following reasons:

  1. Content structure and your website features are very bounded and you cannot decouple it. Decoupling it, you would loose a lot of benefits (eg. Seo, friendly url, linking content elements, etc)
  2. Page Edit mode you would loose it
  3. Page composition having the ability to control page structure on Sitecore open the doors to an infinite number of possibility for your Authoring team allowing them to control your application.
  4. Renderings associated to Content Items associating renderings to Content Items via Datasource allow you to test different configuration and permutation of your application and encourage re-usability principles within your code.
  5. Personalisation allows your content team to deliver a personalised experience is one of the key selling point of Sitecore, decoupling the content from the application would effectively prevent you to Personalise the experience through Sitecore. Sitecore echosystem leverage personalization of Renderings to show and Datasource to use via Sitecore rules.
  6. Content Testing is key in the digital age, continuos testing is the new culture and bypassing Sitecore pipeline force you to a Non Sitecore MVT testing approach.
  7. Analytics & Behaviour personalisation require your Sitecore implementation to tunnel all the request within Sitecore pipelines, moving out from it would mean effectively preventing your trading team to benefit from the great benefits coming from Sitecore

Having done these considerations, is fair to say that if all what you need from Sitecore is the Authoring shell to upload content and images and you are happy to consume Sitecore as Service, you would still benefit some of the features of an enterprise CMS


SQL Azure and Sitecore Retryer

If you are deploying Sitecore on Azure and you are using SQL Azure, you should know that you could experience some connectivity issue between your Sitecore instance and your database…

Therefore it is strongly recommended to enable a retry mechanism on Sitecore data provider to recover these intermittent connectivity issues.

This is the default configuration that you will find in your web config, and what you need to do is to switch disabled to false….

you can either keep the logging enabled/disabled to log these connectivity issues and change the interval setting, but I would recommend to keep the default value…

<retryer disabled="true" type="Sitecore.Data.DataProviders.Retryer, Sitecore.Kernel">
      <param desc="Number of tries">6</param>
      <param desc="Interval between tries">00:00:00.500</param>
      <param desc="Log each exception (should be used for debug only)">true</param>