Sitecore publishing html cache clear error after upgrade from 8.2 to 9.3

Few days back i was working on upgrading some of the features developed on Sitecore 8.2 to Sitecore 9.3, as a prerequisites i setup Sitecore 9.3 blank instance and the site was up and running, so far so good.
As a next step i deployed the upgraded feature to 9.3 website and tried to load the Sitecore after login- and boom… got error=An+error+occured error… of-course there is no clue from the error where and what went wrong.


Also- there were several errors related to Sitecore.Publishing.HtmlcacheClearer in the logs.

Exception: System.Exception
Message: Could not resolve type name: Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel (method: Sitecore.Configuration.DefaultFactory.CreateFromTypeName(XmlNode configNode, String[] parameters, Boolean assert)).
Source: Sitecore.Configuration.DefaultFactory.CreateFromTypeName(XmlNode configNode, String[] parameters, Boolean assert)

After spending some time figuring out the root cause of the issue, came to know that sitecore 9.3 has inbuilt event handler to clear the cache on publish.

Check the below sitecore page for more details:

I checked the feature and saw that there was a patch present in the config which was added to clear the cache.


I removed the custom patch to clear the cache and page started working fine.

So, if you are working on any upgrade project (for sitecore 9.3),  scan the solution and check if it has any custom patch to clear the cache, if exists remove the patch as it’s not needed anymore and handled by Sitecore in standard installation.

Hope it helps!

Happy learning 🙂

How to publish specific version of an item in Sitecore

Did your client ever asked you to make specific version of Sitecore item live in website?, considering we have several versions exists for specific item in Sitecore and client wants to publish specific version and not the latest one.

When we publish an item in Sitecore- it always publish the latest and greatest version, how about if we want to publish previous or some old version?


We have a quick solution for this- we can make use of Sitecore Publishing Restrictions and make all the version unpublishable except the one which we want to publish in the website.

For example- If we have four versions available for specific item and out of four we want to publish version #2 in the website, in this case we can just go to Sitecore->Publish->Change and unpublish version no #3 and #4


After this change when we publish this item- version #2 gets published, screen shot below for ref.


Later if we want to publish version #3 or #4 we just need to make these versions publishable and we should be good to go.

Hope this helps.

Happy Learning 🙂

Handling dot(.) in 301 URLs with SXA Redirects

Recently for one of our project we were adding 301 Redirects in Sitecore that is based on SXA, created SXA Redirect map Item based on “Redirect Map” template and starting adding the URLs(old and new URLs mapping).

What we observed that 50% of the URLs had dot (.) in it with specific extension (for example- .oldextension), so when we tested that entry that didn’t worked as expected because of Sitecore not processing that specific extension.

The same scenario has been listed here as well-

So- what’s the solution? how to handle dot (.) in the old URL and redirect to new URL using SXA?

There are two options we have:

Define static rules using IIS URL Rewrite module

In this case what we can do is- create different rules for handling different URLs and redirect to the target URLs directly from IIS, assuming we have the following URL mapping:

Old URL- http://site.local/category.oldextension and New URLhttp://site.local/categorylanding– we can use the following IIS rule to handle the redirect.

<rule name=”301RedirectRule1″ stopProcessing=”true”>
<match url=”^(category.oldextension)$” />
<add input=”{HTTP_HOST}” pattern=”^site.local$” />
<action type=”Redirect” url=”http://site.local/categorylanding&#8221; />

In the above case we won’t be using SXA Redirects to handle 301 redirects, how about when we have several hundreds of items? I think it doesn’t make sense to keep adding all the static URLs to IIS, so to support this we can go for second solution which is listed below.

Add the specific rule to remove the dot from the URL

In this approach we write an IIS rule to remove the dot from requested Old URL, for e.g. we change http://site.local/category.oldextension to http://site.local/categoryoldextension

<rule name=”Remove Dot For Redirect” stopProcessing=”true”>
<match url=”^(.*[^.])\.oldextension+$” />
<action type=”Redirect” url=”{R:1}oldextension” />


Once we have the above rule set- we can just add the above URL(without dot in it) in SXA redirect and then the redirect should work as expected.

Advantage of above approach is that we just have to set one rule and all the URLs are managed directly in Sitecore and content editors can make the change as and when required.


Hope this helps!

Happy learning 🙂


Sitecore go live checklist

Are you all done with the development activities, all issues fixed and validated by team? do you follow any checklist to review/validate before go live for your Sitecore websites, many organization follow some template (list of activities) to validate if all the activities/steps has been taken care and we are good to proceed and it differs organization to organization and developer to developer.

Here are some of the things we can check as part of our go live prep activity:

  1. Disable default Sitecore credentials (admin/b)– make sure either admin/b has been disabled or updated with strong password.
  2. Protect admin pages under /sitecore/admin/ folder for e.g if you have created any custom utility or aspx page to execute any task it should be restricted.
  3. Sitecore Client license is added and not the development license- double check if Sitecore client license has been deployed in the production environment and not development license.
  4. Custom Errors are working fine- make sure custom error pages are working as expected like 404, 500 etc and no yellow screen page is displayed if any error occur.
  5.  Check 301 redirects are working before go live.
  6. Email check– Search throughout the application for places where emails are sent, make sure all test email address has been removed and client webmaster email address is added.
    1. Test again if mails are going.
  7. Production code version– Check if production has latest version from source control.
  8. Connection string details– make sure connection string has production specific settings like DB servers and port details.
  9. Publish test– Test Publishing to all targets and see if it’s working well.
  10. Rebuild all indexes.
  11. Check if site search is working and right index is being use for CM and CD servers.
  12. Sitecore scheduler check– If any scheduled tasks exists, verify if the time set is correct and the scheduler is hitting.
  13. Minified version of CSS and JS has been used. (depends how CSS/JS has been managed)
  14. Cache bursting is in place to solve the issue of browser caching- this is not mandatory but good to have.
  15. Quickly checking site pages and check there are no server errors.
  16. Check there are no errors in the logs.
  17. No hardcoded and test values- if any static values are required get it from Sitecore dictionary instead.
  18. Experience editor is working fine and check if we are able to add/modify the components from Experience Editor.
  19. Tune the cache size (data/prefetch/item and html caches)- this is done after running the load test and reviewing how caches are performing.
  20. Check there are no console errors.
  21. Check if static assets is being served from CDN (if CDN is used)
  22. User roles has been created for managing different section of the site.( should be done based on roles and not users)
  23. Rebuild link databases.
  24. Favicon is added, if it’s a multi-site application- check correct Favicon has been used for individual sites.
  25. Verify analytics scripts.
  26. Check for robots.txt file and make sure it has right values.

This is NOT the final and complete list-but just an attempt to show some of the common things to verify before we go live and helps us in the prod prep activity.

Hope it helps!!

Happy learning 🙂


Cleaning up Sitecore Publish and Event queue tables to handle memory problems

As you all know that Sitecore Recommends that the no of rows in History, EventQueue and PublishQueue tables be less than 1000 records, this would help to prevent any timeouts while the cleanup agent runs.

Another setting we have for Publish/EventQueue agents is how long to keep the data and the default value is set to 30 days.

But when we have frequent item sync operations from third party systems or within Sitecore (followed with publish)- this would make Publish and Event queue grow which impacts cleanup tasks we have by default (to cleanup publish and event queue table) and memory spiking issues.
In such cases we should consider to optimize the settings we have by default- for example :

For PublishQueue we can set DaysToKeep to 2 and for EventQueue we could set the IntervalToKeep to 04:00:00, but this will vary as required, this is applicable when we see we have more records present in both the tables and as a result we started seeing timeouts and DTU spiking issues.

We can also execute SQL script which is available on CMS tuning guide to remove the records from both the tables.

This is really important to keep an eye on the Publish and EventQueue table so that we can avoid any possible downtime issues and make the system stable as much as possible, obviously- there could be other reasons also which leads to bad performance and memory issues but this is always worth to check.

Thought of sharing it here- hope it would be useful for someone who experience the similar issue.

Happy learning 🙂



Sitecore Item Audit Tool

We have come across many times when we were asked to audit the Sitecore application, which includes Sitecore content audit and solution audit and provide a summary of the complete implementation and see if everything is done as per Sitecore best practices or some compromises has been done.

This article is focused towards item audit which includes checking the templates/renderings/placeholders/content and many other aspects of the Sitecore content tree and item management.

As i got this request quite few of times now- so i thought let’s try to build a tool which can help us is understanding the Sitecore content(item) side of it and give us some actionable items to look and see if there is any scope to improve.

The main idea behind building this tool is to at least get some details from different Sitecore content  types and check if everything is well in place, normally when we review the existing Sitecore implementation these are some of the things which comes to our mind, which includes:

  1. How many page templates exists and how many of them are actually used.
  2. How many data/features templates exists and again how many of them are actually used.
  3. If standard values has been set or not.
  4. If insert options are set
  5. If template icon is set
  6. Different rendering available and if datasource-location and datasource template has been set if it’s a global rendering.
  7. If placeholders allowed controls are set to make sure we can add the components from Experience Editor and etc.

The tool is aligned to solve above points only and it’s just a start, i will continue to make updates to the tool to make it more useful.


Sitecore Marketplace-

How to use:


There are different parameters on which you can generate the report, as i mentioned above report is based on:

  1. Page templates
  2. Data templates
  3. Feature templates
  4. Renderings
  5. Placeholders

Fields description:

  • Root path/ID(Page Items)- This field is to specify Path or ID under which your page items(which has presentation) exists. For example- If you site structure is Sitecore->content->home (under which you have all your page items) then you would have to set the ID of home item or path of home item to this field.
  • Page template folder path/ID- This field is to specify the folder path or ID under which you have your page templates created, for example- if your template structure is- /sitecore/templates/Project/SiteName/Page Types, then you would have to set this path or ID of this to this field. If you have multiple locations where your page templates are stored, then you can pass multiple IDs or paths to this field. Root path/ID(Page Items) field is required to show the correct report of page templates and once done you will have the following details from each template:


  • Page template folder path/ID to exclude– This field is to specify the folder path or ID which you want to exclude from your Page template report. Note– Only one path/ID is allowed to set here.

So- now when we have access to this page report we can see what are the things missing and what is required to fix them, Also- it’s not that we have to fix all the highlighted items as few things are requirement based, but this report provide you that starting point which you need to make your implementation follow best practices.

Similarly we have other reports also, for example- Data template report.

  • Root path/ID(Global Items)- This field is to specify Path or ID under which your data items(global/data items) exists. For example- If you site structure is sitecore->content->Global (under which you have all your global items) then you would have to set the ID of Global item or path of Global item to this field.
  • Data template folder path/ID- This field is to specify the folder path or ID under which you have your data templates created, for example- if your template structure is- /sitecore/templates/Project/SiteName/Content Types, then you would have to set this path or ID of this item to this field. If you have multiple locations where your data templates are stored, then you can pass multiple IDs or paths to this field. Root path/ID(Global Items) field is required to show the correct report of data templates and once done you will have the following details from each template:


  • Data template folder path/ID to exclude- This field is to specify the folder path or ID which you want to exclude from your data template report. Note- Only one path/ID is allowed to set here.

This is how feature template report look if you solution is helix based:


Renderings Report:


Placeholders Report:


Common folder template Report: (Items that are based on default folder template)


We can generate the report based on our requirement, if we want to generate the page template report from specific location and you don’t want to include all the templates, you can just select that specific folder item and generate it.

I will keep adding more features/improvements to it based on the feedback, but i am sure this as our preliminary audit can give us a good visibility about the item management and best practices.

Please let me know for any questions.

Happy learning 🙂

Sitecore profile and pattern cards

Recently we were discussing around Sitecore personas, profile cards and pattern cards on how we can provide a connected and relevant user experience to our end users based on behavior and activities performed by the user on the site.

I later created a video of that so that it can be used as reference by others when needed,  here is the video from my youtube channel.


Hope it helps!!

Happy learning 🙂

Installing Sitecore 9.2 using Sitecore Install Assistant (SIA)

So we have Sitecore 9.2 available now, with Sitecore 9.2 we have two options to install :

  • Sitecore Installation Framework (SIF) and
  • Sitecore Install Assistant (SIA)

Sitecore Installation Framework (SIF) is the same old way to Install Sitecore since version 9, as part of this post i would like to go over the new way to Install Sitecore i.e using Sitecore Install Assistant (SIA)

So- let’s get started.

Step 1: Download the files (SIA)

You can download the Installation files from here- (Please login before downloading the files)


Step 2: Create resources folder and extract the files there.

In my case i have created folder SIA under “D:\Deploy\SC9Install”


Step 3: SIA Config Updates

Before you run and execute setup.exe file you can update some of the settings of SIA using setup.exe.config file and some of the settings which you can update are as follows:

  • SQL Server name
  • SOLR root
  • Solr Serverice

Step 4: Time for action

Right click on setup.exe and click on “Run as administrator” and you will be prompted with welcome screen where you will have basic details on what’s required to complete the installation successfully. Click on start and you will be navigated to prerequisites screen.




Click on Install and wait for all the prerequisites to get installed.


Once all the prerequisites are installed you can see the below screen:


Click Next and proceed for Sitecore Settings, populate the details which includes solution prefix, admin password and license file.


Click Next and populate SQL server details


In the next screen verify the SOLR details, if you have updated setup.exe.config file with the SOLR details it will be pre-populated for you here:


In the summary screen validate the details and make sure everything is correct.


Next screen- validate if we are good to proceed for the installation.


Click on Install, it will take a while to install.






You can now login to Sitecore:


And with this we can also see the new SITECORE in the login screen 🙂

Hope this helps!

Happy learning 🙂



Setup and Install SOLR 7.5.0 for Sitecore 9.2

It’s super easy to Setup SOLR 7.5.0 for Sitecore 9.2 and with the gist shared by Mark Cassidy  here, it will take just few seconds to install and make SOLR up and running.


I have used the same and updated few parameters like:

  • Solr Port
  • Solr Host
  • Solr Version (7.5.0)- (This is prerequisite for Sitecore 9.2)
  • OpenJDK Version

Ran the script and few seconds later SOLR 7.5.0 was up and running.


SOLR admin was up and running.


Thanks to community members contributions.

Hope this helps!

Happy searching 🙂


you-must-have-a-user-with-the-same-password-in-master-or-target-server error while installing Sitecore 9.0.2 in SQL 2017-fixed

Recently I upgraded my machine and installed SQL Server 2017 and after upgrade i got stuck in well known “same password in master or target server” error while installing Sitecore 9.0.2 instance.

Unable to connect to master or target server ‘sitenameXP_Processing.Pools’. You must have a user with the same password in master or target server ‘sitenameXP_Processing.Pools’.

SQL Version:

Microsoft SQL Server 2017 (RTM-CU15) (KB4498951) – 14.0.3162.1 (X64) May 15 2019 19:14:30 Copyright (C) 2017 Microsoft Corporation Express Edition (64-bit)

Sitecore 9 setup was not new but there was something different with SQL Server 2017.

All the installation prerequisites were in place, checked this post by BrandonMBruno and this was good too.

Microsoft Web Deploy dynamically loads SQL Server Data-Tier application framework, SQL ScriptDOM and SQL CLRTypes components using automatic version detection but in my case Web Deploy has not installed the correct version of SQL Server Data-Tier application framework.

So- I installed the correct version of SQL Server Data-Tier application framework from here:

This fixed the issue for me, so i would suggest to check if you have the correct version of SQL Server Data-Tier application framework installed if you run into similar issue.

Hope this helps!

Happy learning 🙂