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.

 

ankit-sitecore-download

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

/App_Config/Include/zCustom.config
/App_Config/Include/events/zCustomEvents.config
/App_Config/Include/etl/zCustomEtl.config

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)

Sitecore-patching

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

http://%5Byour-localhost-name%5D/sitecore/admin/ShowConfig.aspx

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 🙂

Advertisements

Test changes without publishing to web DB in Sitecore

In your development environment, did you ever felt that publishing is not providing a great value, but acting like a hindrance?

PublishItem

In Sitecore you can directly test your changes without publishing your changes to web DB, and configure Sitecore to use content from master DB.
This can be done in two ways:

  1. If you don’t have any custom Site configuration config file exist, please go to App_Config/Include/LiveMode.config.example file and rename it to LiveMode.config or
  2. If you have custom Site configuration file exists, you can change the database value to “master” from “web”.

Please make sure to revert your changes, before deploying the solution to QA or production environment.

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)
{
section.SectionInformation.UnprotectSection();
}
else
{
section.SectionInformation.ProtectSection(“DataProtectionConfigurationProvider”);
}
// Save changes to the Web.config file.
config.Save();

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″?>
<connectionStrings>
<!–
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=”tracking.live” connectionString=”mongodb://localhost/tracking_live” />
<add name=”tracking.history” connectionString=”mongodb://localhost/tracking_history” />
<add name=”tracking.contact” connectionString=”mongodb://localhost/tracking_contact” />
<add name=”reporting” connectionString=”user id=user;password=password;Data Source=(server);Database=Sitecore_Analytics” />
</connectionStrings>

After encryption, this is how the file looks:

<?xml version=”1.0″ encoding=”utf-8″?>
<connectionStrings configProtectionProvider=”DataProtectionConfigurationProvider”>
<EncryptedData>
<CipherData>
<CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAA2ivFsj7cNEaM7QEbCTKmIwQAAAACAAAAAAAQZgAAAAEAACAAAAAhdGbhIMVnCuLPqxeQN8XGwAwUQAAJxH+/HDKbuXL70AAAAAAOgAAAAAIAACAAAAA7VJJIQ1/LGK2vEPieVV4MAh7sFiLEBf0rbHNQOqObocAKAAA+aDLJMlW2QCwkMiggfcUmw6DQA+jCZ6ivu5VduLr7iKQgoI6XdAV4SRlaJt3mS4ZSWmFEsllJI/Gkw74cknBjV82msfjdne+RMWWCMmsyW3a6NmMmtS0g4mQBBBELnqDx8FzSyZfUbUnTkIMixLLLM9H3tVcVebMXSb4SRn4Vzsi2y2Ux+Has3AEKwNfUSf2cqWAqrqXz+WnusSZpEaS6U6RmkKe5P3llacPtfAQGoqTvrxDTF49V/H/q013ZUCLUO6r9GvALNv0v4Q4PWeUe64i2TCRVIRh2anAdlqUtkw1UWMQfbwJLeyGjn4SMAF2fC2ixnqKh29pbfvYe9vQqkDGda9SyRGNL3brWYeL3PS1rFLlL4bnMf3BORLL0rDGzqNwHoLczXB56VhzYRceALyB+tN303Mqv13U6UAUwz1E6e8fYw6sYNR5/b3PL5nYgew8sHKKMysHfmzLrgiLaRxtZOLFp8unus8V0K5BaJck6iprRtNJ7jJuZ5OkRWgYhZ4bXeWjN9z386NVaiPfLPypoyo8tP252+lGpWZID7WtbSkdDXpRZ5VzojiGDZRu+8/vyLfxACM6Or8u+b3YDqLfrBbQE/JklDjxx2ZriskU9lf1lkXgSFa45PlJAfCr8nIldNUvVojKZDmbUP5aiNqiI/0CiZ8RZLQ3N1zBsISdK3VTOOF5WYdulpRq3ZH4FvU/QtqY6Bk1mPrb59TIx/appq86SIcygQats1mHuZ0/WN4oCwVfhQaN9t91G7vinxYluR6ljZkBfky1x6HYNcj+TGp2WAK6Y9+ATiOfbOHs+vgunQA1575He3uHCxMZuU0YeU1HEE5xnEvhG3aiLMkUc0h5wX0vvjgen2WC5xpRbN4vL4sqvcSsGXIt/smkz/h+rvS2LTl+fXx1p+QSZnoA2Gi5ooAaO3W0egda21nACp08kAzSJAuiivIqvmEpDkrn41TCG2HFgh2WErcc42xCUnEZ80drTzjCTP0fW9Q/qmudnz8OioXt5Ftifzj44fpSZcfCzH0uVMiFrwwx9RNjdAiIBUxDaqnygRtHXh3eXw8ofIkHikMzwXXw8CB7WAaGfNgHJpICG8Uj4AgWzV9Q59FkG6RAjEAtAXU1vFGEQbRY+bbeGobI5epXMvZmJaLnhQmrlGDE4XgwwoaXmEkTxM16hukmXqcys3yUL1v+1VHsvAnA4Ng+aixOBaQjlGkXTv2zHEHH4NM1oAQ106KgpzuXbRNogv9RgRO2aXlaNAHmR3Z08v7hEmh9vwMdR7sSkKwP4RB3EIkF4ScBsFN++G8ZmdFVx7biPCx+tzXCUsy9yFWHQ/eqsfKuvVqVd6RzTpgLTXilTpT2gcqbDKMdm9qm2gUkuN/SvL7wyY1Lciuv/E65RS2EgoLOLZ5DOWe3YMOmTSnpwpqj4wXfeh+mbNJF9ejjXmceOUfr6BEvhMB3mjF8onJHFq1M+NV7EeW8i4SdGxiGxSURW9SVxB37Rkdikn4/TjIIE5n3+h90By9VIWuUgBRJ1XEy7HnUyShM/0WSyx89pvWU5LZeHr/mkLAdLyo4O+L8LdzC2QYsjy+fI/Smx2DuDyJvCJU/fE1ikm//G6va12uI/ZoeqCiJX4m9yKcNyJT8OrCzhKK4PN/P+05raC6oyu4qNvMunR4PGUc3BHziimAFuXkUjONfNlkwZn1CMdGmW8JOxycVXqS6QMhJpwBnOcyHKutnNFbKjlzXwhhiVEKZr46/MmTkrrePHyfpvjeZZwD3ZFsLr6O7qYd5qpv/7Jb9RPRKDFDqzc9XSdn0kLH8uYBQxrI7vVhQIgLIOwNbODXvtY0fjrrrfdzFm2zpIkxx164yZgBRDlSW1QhlSGMTzO+5sUO8LUb1aJiXHj4s/gITI5yX7AB8PBXAlgEikBcKJuiqq5IyiKdLWRNCEmmCI4ocVl/CliZ8iruK7S8ei+GFpCkOHBjrTwEcLM7vV+z0FT1zjJVLWJ4luurbQcvEiyNHUymeprpk6NKfj2b6WyZCAlzlpLWyNONfQCDtSYcfcXtwf8fmdOZeI0M43BlgnT8SHW/ujHrNWpVTofw1u+Iso8/Hy1BwgFMD1JXXvuEKK+DaQEqrP6zbPRHTgMXTayvQW5rmuWIUSOJGdUgEhMoTGIQs7jY5sv24PunM0wpYZag+EZm1LzqtWwmHB8IQ/DRqY1ioCiDY1xum/nk3OVblMnhAwH2mJHj7nsXY7+H45q4fSW21fy1dksQgAW9P8T+PQeLdflAhtmUQLBNEAmnXOk6pRvVmeJ60yHqQFV7N0KHnCnnPRu/YSZLQrjGoX0dz0s9jZRVzxiflc+241gQVE8ygk3uL0wtsDvoA7Dq1FNKgHSjffcmQoHaOA/ESt6TD0XM+IzIhtcSz3SAL0OB3JIVaMjF7vcK7INRPPsSR6s7wmm+0kjYfi/tueQq8O2dWxSvMl78bZvehfy7PdBhQ+70AgtKOeev5o/OUlI7/V9wEBYwVjkz053p2/B4tijOgjy/hygFsQry4gdZh8PsqeEAP8h4gXlJ76QgszffTI0K9Heiwc5ptwrP6BVr2j1wL95FI5mLgsMWLx1N+8G1rwvhM5DCSVtYqkPtwn9cjLaRgO+K5eyfDFHN+qyKNZ2seiJ0xl1DvUVK0Be5/FjRoCT1V4GLDLAGZ1hJKGoM5zYkh2XuF8soXQ8v+Hdzmb+JaEuXGvhLnTMuIC9Rd+dV/BFUfEscctONdlLfNmobqO83xxuxRIULEPVTXBEBrMXMRnmRa6HPm9KURgbGzJFiTn3oG1g+jCLYfVfE6FcF+29oPsXwsWy5EePdFJXcG7m4RmTYitlWApBE7SfqFhMLK+SXH1OZiZ2GvszIWp3NdEF0bpZXvM6MdFQgtzhrdWpEevRgaXCfFHBv2w3rh2II8hpYXVCs5Vpy7uHzZ99yZULWAZbd/PtuDOoaNtXcJQTxjJcHiAqivpDFknbHrbMwjjuByFjoPLqUCbaGDN0LsPV9yNNQaBXSCGMeW/5eSfLcMMjZHCM8j9rNXiixnc5/hk3kc8EpooduJBm8z1pxEI6rA2+zAZVsK9qH9ydiR/yt7EH+CEBZGmN411ybZiCyx1EHRxE1hL0lXbKzQAqLJQOthKukou5DNhlePPm+hDkV9Y1elPXOkO4tSrdoqTKd0XYNmUHeAcca1C7BOY5D6sRfn/4PHSM2NYdMIlkeIyLyMDnPzm1Wu/7ArAZJUJ7D8aLreeNsI3d48bIO/j/GtAdCLTN6sBo21R8B8tVv0qbbic83D8P8EDodHEJvxHUtEPBYjpFgloek+ToPnHH7aHUqSXtFH5EI1bbp2zNdVpwB4kJ9beC6Y8foR81NAKVlNjeCSVmrW2+ZUw19CSMLiiMh8DCG5jQvZ5ejBqmIGpHYZEIc5yQLxb5AlSbYeNEH6MsCh6mhpBfWXbTKJxUhZvFuaBh0+UgI0sRB4OQ2vJ0TtgRRnCiFnOlszBqiiEH5MbAFwWtFS/mNWPFi76HNN3YF2sL4QtrlqLw6TcVuGIRCqWkZasb7hdwdMarV0A8fCx996PwMsWPdQ8StVjXqz567yzev5d1T3tbSrzdo8HgLwIAIdLQOxP1JnNlnLqwXW0k37CFZyUjwWV3ZfiXJN1tIolul1ogf5modPF3YB0aS4FQAAAAB6C3jSoZh6M0ltHxa/HTqQUTSQexkdlI/5baIOQQx/dmJEoTWBa/D2JTHAwYhTQa/psamG03lzeKsm0jetzACw=</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>

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 🙂

Understanding Clones in Sitecore

There are scenarios when we want to replicate/duplicate entire content tree/individual items and create another structure in same Sitecore Instance, we also want to make sure that content can be shared from parent item to new item, in these scenarios and cases we can make use of Sitecore Cloning which helps to achieve the same.

Clone:

A clone is an item that is not just a copy of the original item, but one that inherits the field values from the original item. If we update a field in the original item, the corresponding field in the clone is also updated, this helps in implementing content sharing across sites/items in the same Sitecore Instance.

What can be cloned:

Here are the following items which can be considered for cloning:

  1. Complete site
  2. Section of site
  3. Individual Item

How to clone an Item:

In order to create a clone, please follow the following steps:

  1. Select the item which you want to clone from content tree.
  2. From the configure tab, click Cloneclone-tab
  3. From Clone Item dialog box, please select the location where you want to create the cloned item.
  4. Clone-Target
  5. Click Clone.
  6. Now go to the cloned item, and you will observe the “original value” next to the field, which explains that value for this field is inherited from parent/original item.clone-original-field-values

How to Unclone an Item:

In order to Unclone an item in Sitecore, please follow the below steps:

  1. Select the Item from content tree which you want to Unclone.
  2. Click on Unclone, from the configure tab.Unclone-tab
  3. Once we Unclone an Item, this item becomes an individual item which can be managed separately.

Breaking the Inheritance for Cloned Item:

As i mentioned above that we can Unclone an item, by which that item becomes a new item which can be managed separately.

But, we can also break the inheritance on field level, in order to break inheritance on the field level, just go to clone item and update any specific field value.

Once we update specific field value manually for any clone item, that field won’t share/inherit the value from parent/original item.

This is helpful in cases where certain field values to be shared from parent item, and certain field values managed separately in clone item.

Unclone-field value

In the above screen shot we can see that “Teaser” doesn’t show any “original value” text because the value was updated directly in the cloned item, but “Main Content” still inherits it from parent item.

Few points to note:

  • Before we take a decision what item/section should be clone, we need to do understand our content strategy.
  • For example- If we have to create a microsite which should be based on parent site, we can go for cloning, but, we also have to understand what are the different sections that needs to share the content, if only certain pages needs to be shared, we don’t have to clone the entire content tree(site), rather we can just clone specific pages/items.
  • Another example can be navigation, we want the navigation to be same for all the sites, but content differs, in this case we can just clone Navigation Items and not pages/items.
  • We can make use of field value inheritance, if the content of the clones items needs to be different, we can break the inheritance and add specific content to cloned item.

I hope this will help someone who is trying to do understand how clones work in sitecore, please let me know if you have any feedback or questions, happy to help.

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:

pagepreview

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- https://kb.sitecore.net/articles/986056

Happy learning 🙂