Introduction to Sitecore Patching

There are several instances when you make updates to your Sitecore.config file, changes can include:

  • Adding new pipelines and processors for any custom feature implementation.
  • Updating/overriding the default values for some of the setting values like cache sizes and etc.
  • Adding new Sitedefination for your Sitecore instances.

So, to make any of the updates mentioned above, we have to perform following task(s):

  • Code changes (class file updates) and/or
  • Configuration file(s) changes (this is to make sure we register the changes in Sitecore)

Once you are done with you class and config changes, we need to register the changes in Sitecore, this is required so that Sitecore can identify the changes you made, and the functionality works as expected.

There are two approaches for registering the custom updates in Sitecore:

  1. By adding/updating the config changes directly in Sitecore.config file (not recommended)  or
  2. Creating a patch file (with extension .config)  which includes all the changes required, and placing file under App_Config/Include folder, we can create separate sub folders as well.



Both the approaches works fine as expected, but there is an issue with approach 1.

How would you handle the updates in Sitecore.config file when you are planning for an upgrade later?, provided that you made several changes to Sitecore.config file, it may results issues after the upgrade.(think about it carefully before making changes directly to default Sitecore.config file)

How about if we think about creating a patch file, and putting all our changes there?, and this works well even if you are going for an upgrade at later stage, as you are not adding/updating anything on default Sitecore.config file directly, all the custom changes are coming as part of your patch file(s), This also helps in easy maintenance and troubleshooting.

Patch files are merged with Sitecore.config in alphabetical order. This means configuration in a patch file named a.config will appear before configuration in a patch file named b.config.

If the same configuration is found in multiple patch files, the configuration from the last patch file processed is the configuration that is used.

We can create as many patch files as we want, it all depends on the feature/requirement(s) and the way you want to organize your configuration files in your solution.

For example – you can create separate patch file for any Import functionality we have in the system, and this includes all the settings that needs to be added for specific one, also, there can exists separate patch file which includes custom indexes if exists any?

Note: Patching only works on the Sitecore configuration section, no other file or section can be patched with this.

Place in solution where patch files are placed, i.e under “App_Config/Include” folder


Sitecore patching can be used for following operation(s):

  1. Adding a new setting
  2. Deleting a setting
  3. Adding or updating an attribute.
  4. Inserting an element before a specific element.
  5. Inserting an element after a specific element.

Simple example of Sitecore Patching:

This will set the default database for your website to master, this helps in testing the application without publising changes to web db
(Make sure to revert it back once you are done- and never make this change in QA/Production)


How to see the result after Patching?

Now, how we can see the file which includes all the patches which we have applied, there is no physical .config file which can be used, In order to see the final result, please use this URL


Sitecore patching is an important part of day to day development, and we should leverage this as much as possible, to make sure we can make the system more stable and maintainable.

You can learn more about Sitecore Patching here:

Thanks and let me know if you have any feedback/comments on the same.

Happy learning 🙂


fixing end of string expected at position error in Sitecore

Recently while verifying some of the components in Experience Editor, I observed that while adding datasource to the renderings, it was throwing “End of string expected at position 75” error.

I checked following things to troubleshoot the issue:

  1. If Datasource location specified in the rendering exists or not, and it exists.
  2. If Datasource template is defined in rendering or not, and it was there.
  3. Check the errors in log file, and there was an error there, please see the below screen shot what error it was.log
  4. Following error was visible in front end while adding datasource.end-of-string-error


It turns out Sitecore doesn’t like hyphens “-” in query path, and few other which includes:

  1. If you query contains keyword “and
  2. If query contains keyword “or
  3. If query contains hyphen “

In my case when i checked the query and it contains keyword “and“, which was basically failing and not allowing me to add  datasource from Experience editor.


In order to fix this issue we can add escape character “#” before and after of the items that contains any of these keywords or hyphen “-“, so, for example:

Before : query:./ancestor::*[@@templatename=’SitecoreRoot’]/Global//Modules/Image and Media Module

After : query:./ancestor::*[@@templatename=’SitecoreRoot’]/Global//Modules/#Image and Media Module#

After making this change, the issue was fixed.

It seems this issue was there in Sitecore 6, but it can be replicated in Sitecore 8.1 (rev 160302) as well.

I have raised this with Sitecore support team, and they have registered this as Wish/Feature, so, we may see this issue resolved in coming product versions.

I hope this helps somebody.

Happy learning 🙂


Versioned-Unversioned and Shared fields in Sitecore

This blog contains information about items, more importantly languages of items, versions of items in languages, and sharing the values of individual item in different supported languages and numbered versions.

This post is focused on explaining the differences between Versioned,Unversioned and shared fields in Sitecore.

Versioning of an item is controlled in three ways:

  1. Versioned fields
  2. Unversioned fields and
  3. Shared fields


Versioned fields:

By default all the fields are versioned, which means the the field value will be different across different numberd versions and different language versions as well,
example of numbered version-  title/description and etc, or any such field whose field will be different across different languages/versions.

Unversioned fields:

There are certain fields whose value is same for all the numbered versions for a specific language, such as “Country Name”, “Employee Name” and etc, if we want to have such configuration, we should make that field as “Unversioned” in template definition.
When this(“Unversioned”)  checkbox is selected, the field has the same value for every numbered version within a language, but may have different values between supported languages.

Shared fields:

When the field value doesn’t change across languages and number versions, we should mark that field as shared, shared field value will be common across supported languages and versions.
When the Shared property is set, changes to the field value in any language or numbered version of the item will be reflected in all the other language versions and numbered versions.Example- “Id” or some unique identifier which will be commons across languages and versions.

I hope this helps someone in understanding the core concepts and versioned fields.

Please let me know your feedback, or your thoughts on the same.

Happy learning 🙂

Securing Sitecore connection strings

There are scenarios where we don’t want to compromise with the security of our application resources, this includes Connectionstring.config file as example, If someone compromised CD servers, they will have access to Connection string file and can use the details in a wrong way.

There are ways we can secure the connection string in Sitecore, in this blog post I would like to give an example of one of the approach which can be used:

Please see the sample code snippet, to encrypt and decrypt  connection string file.

Configuration config = WebConfigurationManager.OpenWebConfiguration(“~”);

// Get the connectionStrings section.
ConnectionStringsSection section = config.GetSection(“connectionStrings”) as ConnectionStringsSection;
if (section.SectionInformation.IsProtected)
// Save changes to the Web.config file.

Few points to note and consider:

  • This approach uses System.Web.Configuration namespace to work.
  • We access application’s web.config file via OpenWebConfiguration method.
  • We access connectionStrings section of the web.config file via GetSection method.
  • Encrypt and decrypt the sections.
  • Save the changes.

This is how the connection string.config file looks before encryption:

<?xml version=”1.0″ encoding=”utf-8″?>
Sitecore connection strings.
All database connections for Sitecore are configured here.
<add name=”core” connectionString=”user id=user;password=password;Data Source=(server);Database=Sitecore_Core” />
<add name=”master” connectionString=”user id=user;password=password;Data Source=(server);Database=Sitecore_Master” />
<add name=”web” connectionString=”user id=user;password=password;Data Source=(server);Database=Sitecore_Web” />
<add name=”analytics” connectionString=”mongodb://localhost/analytics” />
<add name=”” connectionString=”mongodb://localhost/tracking_live” />
<add name=”tracking.history” connectionString=”mongodb://localhost/tracking_history” />
<add name=”” connectionString=”mongodb://localhost/tracking_contact” />
<add name=”reporting” connectionString=”user id=user;password=password;Data Source=(server);Database=Sitecore_Analytics” />

After encryption, this is how the file looks:

<?xml version=”1.0″ encoding=”utf-8″?>
<connectionStrings configProtectionProvider=”DataProtectionConfigurationProvider”>

If we want to decrypt the section, we can use UnprotectSection()  and can review the connections, once we are good we can again encrypt the setting using ProtectSection() method.

We can also secure the setting using aspnet_regiis.exe tool.

I hope this helps someone, who is looking for something similar, please let me know for any questions on this, happy to discuss more.

Happy learning 🙂

MongoDB authentication in Sitecore

Securing application data is critical for any client and business, and the same principle applies to Sitecore application as well.

One of the most important component of Sitecore is MongoDB, which is where we store all Experience(xDB) related data, MongoDB was shipped into Sitecore’s ecosystem from Sitecore 7.5, and it’s very important to make sure the data stored in xDB is secured, and only authorized uses has access to the data.

Recently, we heard about thousands of MongoDB data being hacked, so what’s the reason behind it? any guess? it’s simple- all those DBs were not configured to be secure and anyone can access it.

It would be great if MongoDB installation itself comes with an option, where we can secure our data while installing it, like how we do it for SQL.

Even though, we can go back and secure the data  by setting up users/roles and permissions, but it’s always great to do it it first place.

We also have to see and make sure that Connection string used for MongoDB is all protected with credentials, so that only authorized users can access it.

As part of this blog post, i would like to cover the steps which we can follow and make our Sitecore application more secure.

  1. Create MongoDB User
    1. Follow the below command to create the user.
    2. db.createUser({user: “mongoadmin”,pwd: “mongoadmin”,roles: [ { role: “userAdminAnyDatabase”, db:”admin” },{ role: “root”, db:”admin” }]})
    3. We just created a new mongouser- “mongoadmin” under database “admin”, and has given all rights to this user by assigning role “root“.
  2. Verifying the User
    1. If we want to verify that user gets created or not, we can use the following command for the same:
    2. db.auth(“mongoadmin”,”mongoadmin”)
    3. This should return 1, if the user is authenticated.
    4. We can also see the list of all users by running following command:
    5. db.getUsers()
  3. Assigning specific roles to unique collections
    1. We shouldn’t be giving “root” level access to the user, and it should be more specific to the database and collection.
    2. For example: we can give read and write access to analytics database in Sitecore.
    3. In order to do that, please login to mongo shell and switch to admin.
    4. use analytics
      db.createUser({user: “mongouser”,pwd: “mongopassword”,roles: [ { role: “readWrite“, db:”analytics” }]})

    5. In this case we created a new user called “mongouser” and assigned “readWrite” role to it, and is specific to “analytics” database.
    6. In the same way, we can do it for other three databases also.
  4. Connection string updates
    1. This is how the default connection string looks like:
    2. <add name=”analytics” connectionString=”mongodb://localhost:27017/sample_analytics” />
      <add name=”” connectionString=”mongodb://localhost:27017/sample_tracking_live” />
      <add name=”tracking.history” connectionString=”mongodb://localhost:27017/sample_tracking_history” />
      <add name=”” connectionString=”mongodb://localhost:27017/sample_tracking_contact” />

    3. After making updates to connection string, and adding required username and password details to it, this is how it looks:
    4. <add name=”analytics” connectionString=”mongodb://mongoadmin:mongoadmin@localhost:27017/sample_analytics?authSource=admin” />
      <add name=”” connectionString=”mongodb://mongoadmin:mongoadmin@localhost:27017/sample_tracking_live?authSource=admin” />
      <add name=”tracking.history” connectionString=”mongodb://mongoadmin:mongoadmin@localhost:27017/sample_tracking_history?authSource=admin” />
      <add name=”” connectionString=”mongodb://mongoadmin:mongoadmin@localhost:27017/sample_tracking_contact?authSource=admin” />

    5. This is how the format looks like:
    6. mongodb//[username:password@]host[:port]/database?authSource

If we are trying to access MongoDB without passing valid credentials, we get this error in the log, please see the screen shot for ref:


Once we pass the valid credentials, this error will go off.

It’s always a good practice to authenticate MongoDB in local environment as well, this helps us in setting the habit for it and we can uncover any issues well in advance.

I hope this helps in getting the understanding about how we can secure and authenticate MongoDB, and how to create users/permissions for the same.

There is a great article in MongoDB documentation, around setting up auth for Mongo and setting up users, creating roles for the same, please consider reviewing this as well, this is great source of information.

Thanks, and please let me know for any questions, happy to discuss more.

Happy learning 🙂

Content managed favicon in Multisite Sitecore solution

There are scenarios when we want to configure content managed favicons for multiple sites in the same instance of Sitecore.

I have implemented this for one of our client, so thought of sharing the same with the community.

In my case, we have separate Site settings node created, which has all site related information, from the below screen shot you can see we created a new field called “Fav Icon” which is of file type.


Once we have the field available, content authors can content managed the fav icon based on the site requirement, please see the screen shot for ref:


In the below code snippet, we are trying to fetch the sitenode based on start node(home node), and once we have sitenode, we are fetching site settings node from where we can get “Fav Icon” Url value.

 public static Item ContextWebsiteRoot
     Item contextItem = null;
     Item webSiteContext = null;
     if (Sitecore.Context.Site != null && Sitecore.Context.Database != null)
        Item homeNode = Sitecore.Context.Database.GetItem(Sitecore.Context.Site.StartPath);
        webSiteContext = contextItem.Parent;
        // Use webSiteContext to get "Fav Icon" url...
        // We don't have to use .Parent, if "Fav Icon" field is created directly 
        // under home node.
     return webSiteContext;

In my case we don’t have the Fav Icon in the site home node, so we need to add some rule to get the correct item, and then reading “Fav Icon” field, but just in case, if you are trying to add “Fav Icon” field directly in home node, you don’t need to fetch any parent Item.

Here is the simplified version of it, when “Fav Icon” is added to home node.

 Item contextItem = null;
 Item webSiteContext = null;
 if (Sitecore.Context.Site != null && Sitecore.Context.Database != null)
      Item homeNode = Sitecore.Context.Database.GetItem(Sitecore.Context.Site.StartPath);
      var siteFavIcon= contextItem["Fav Icon"];


I hope this helps someone who is trying to implement something similar.

Happy learning 🙂

Configure Sitecore to update sitemap xml on CM and CD servers

In a scalable environment the expectation is to have multiple servers serving the content(s) to different regions(or sometime same region as well), the typical architecture is to have one content management server and atleast one content delivery server.

Sitecore provides “Sitemap XML module“, when we publish content(s) it will generate an updated Sitemap.xml file – basically, a listing of page(s) that a web-crawlers can use to crawl and index a site.


When we have content delivery servers set up as part of the configuration, we have to make sure that Sitemap.xml file also gets updated to CD servers which doesn’t happen by default, only content management file gets updated.

In order to make sure we Sitemap.xml file getting updated to the servers, we have to add following  to events section:

<event name=”publish:end:remote”>
<handler type=”Sitecore.Modules.SitemapXML.SitemapHandler, Sitemap.XML” method=”RefreshSitemap” />

This will updated the Sitemap.xml file in content delivery servers as well.

Note: Please refer this URL which explains about the same issue and resolution-

Happy learning 🙂

Resolving issue with page preview in Sitecore multisite configuration

With Sitecore multisite solution and architecture, we see site resolving logic might seem to work in unexpected ways sometime,and i encountered this issue couple of weeks back, here are few things to consider with Sitecore multisite configuration.

Let’s assume we have two sites in the same Sitecore instance, this is how the typical structure looks like:


In order to have two sites in the same Sitecore instance, we also need to add site node settings which is present as part of Sitecore.config now,this is how it looks:

<site name=”website” enableTracking=”true” virtualFolder=”/” physicalFolder=”/” rootPath=”/sitecore/content” startItem=”/home” database=”web” domain=”extranet” allowDebug=”true” cacheHtml=”true” htmlCacheSize=”50MB” registryCacheSize=”0″ viewStateCacheSize=”0″ xslCacheSize=”25MB” filteredItemsCacheSize=”10MB” enablePreview=”true” enableWebEdit=”true” enableDebugger=”true” disableClientData=”false” cacheRenderingParameters=”true” renderingParametersCacheSize=”10MB” />

<site name=”my-new-site”…../>

<site name=”website”….> is the default setting that comes with Sitecore, we need to add any new site added to system here, so that site can be resolved, in this example we added “my-new-site” to the list.

It is recommended to keep the Rendering.SiteResolving setting value at “true” for any multisite solution in order to ensure that cross-site links are built with the correct parameters.
Here, the Experience Editor and Preview mode are opened in the context of the site defined in the Preview.DefaultSite setting.

In my case, I observed the page preview mode was throwing error, and when i looked into the “Preview.Default” setting in Sitecore.config file, it was pointing to “website
We had “website” site node , but the location was no longer exists- it was pointing to /sitecore/content/home and we didn’t had any item in this location.

So, there are two options here to resolve this issue:

  1. Update the “website” site node start item in Sitecore.config to point to active site/ location or
  2. Update “Preview.DefaultSite” mode settings with an active site.

Note: Please make any updates to Sitecore.config using Sitecore patch file, so that we don’t mess up anything with the default configurations, and down the line didn’t face any issue with Sitecore upgrade as well.

Also, to make sure that items are opened in context of correct site, we must set the Rendering.SiteResolvingMatchCurrentSite setting to “true”

All configs related to site resolving can be found (“/App_Config/Sitecore.config” in Sitecore 8.x and web.config in 7.x)

Please read more about the site resolving here-

Happy learning 🙂