Ghanendra's Tips

Everyone loves using Sitecore PowerShell Extension i.e. SPE due to the flexibility it allows to work with Sitecore. Those who are working on SXA must be already aware that SPE is a prerequisite to SXA. In fact SXA has many inbuilt scripts which help in managing the SXA tenant and sites. These SXA scripts are accessible through Scripts item that appears in an item's context menu.  Note - Context menu is menu that opens up when you right click on an item (as in snapshot below). So far so good! One day we realized in our live environment that even content authors can access the Scripts item in context menu and they have complete access to SXA scripts  like Remove Tenant, Remove Site, Add Site Language etc.  We realized this could create potential problems on live environments. Just imagine a scenario about an unaware content author who encounters these options and decides casually to check that what can Remove Tenant script do. Scary, right! So I started working on finding a way to h

Do you know that version 10.1 onwards, Sitecore is storing default items as resource files. This is an interesting update as the files on disk are binary-serialized item data using Google’s ProtoBuf specification – in this case using the ProtoBuf.Net library for .Net. Why to store item as resource files? Sitecore has lots of  out-of-box items like sitecore/content/Home which are present in Sitecore databases. Sitecore has changed this approach to store these items on file system as resource files as ProtoBuf data to solve the complexity related to upgrading the Sitecore instances especially in containerized environments. If you have an instance of Sitecore 10.1 or above running, you will find these below files. Default Sitecore items are part of these files now -  How do they help in upgrades? In containerized solution, code and config updates are wrapped in Docker Image. When the out of box Sitecore items are placed in resource files, they get updated as part of Docker Image itself. T

Let me start this blog with a question - Is there a limit on number of sites Sitecore SXA can support on a single Sitecore instance? If you search an answer for this, you will see the below - Bear with me, the answer to this question is not a simple 'No' in current state of Sitecore and SXA module. We will discuss more on this in this post.  THE PROBLEM We have upgraded from Sitecore 8.1 to Sitecore 10.1 and migrated our vanilla Sitecore sites into SXA sites. We started migrating some important sites to SXA and then we planned to move rest of the sites to SXA. Things were fine until the number of SXA sites hosted on our Sitecore instance were small. As we moved our rest of the sites to our new Sitecore instance, we started observing that the Sitecore site in IIS will continuously restart without giving much idea about why it is happening. THE SOLUTION We thought this can be a machine specific issue due to memory etc. and may be the issue wont reproduce on other developer machin

We have recently upgraded our Sitecore form Sitecore 8.2 to Sitecore 10.1 and have migrated vanilla Sitecore sites to SXA sites. So far so good! Then what's the problem? THE PROBLEM One random day, a content author (lets name him GhanSingh) opened a page in Experience Editor, edited it and then saved it. May be he didn't like his changes and he thought of checking older versions of the page. He went to the page in the Content Editor and tried to check old versions of the page and to his surprise he saw something like this -  Do you notice how older versions of the page also show same Statistics data (last modified date, last modified by etc.) as the most recent version. In fact, the content author thought his actions has created multiple versions of the page and he has no way of reverting back to older versions as he don't see them anymore in the drop down. Any guesses what caused it? THE SOLUTION We thought it may be some custom event handler that gets triggered on item:sa

Sitecore Publishing Service  (SPS) is an opt-in mechanism for high-performance publishing in large scale Sitecore setups. This module increases publishing throughput, reduces the amount of time spent publishing large volumes of items, and offers greater data consistency and reliability. The module also improves the user experience and provides better visual feedback to the user on the state of the publishing system. If you don't use SPS yet and if your publishing tasks take longer than expected, SPS module can be highly useful to you. In this blog, I am going to share a recent experience related to configuring SPS in scaled environment. There is a specific step in installation guide which needs to be performed explicitly in scaled environments and if you miss it, you may have problems publishing related items with the page. THE PROBLEM In our case, publishing worked correctly but none of the related items of published page got published. We reached out to community on slack and als

This post intends to get you familiar with how Sitecore manages SelectRendering dialogs found in  Experience Editor , how  Sitecore Experience Accelerator (SXA)  module is able to override those dialogs and how we can still use vanilla Sitecore based SelectRendering dialogs even after installing SXA module. We are working on upgrading our application from Sitecore 8.2 to Sitecore 10.1.1. We have 100+ sites in our  existing   Sitecore instance and we are moving them from vanilla Sitecore sites to SXA based sites. Problem While testing the pages in Experience Editor, we noticed that the SXA based SelectRendering Dialog is different from vanilla Sitecore 10.  For e.g. when you click on Add Here to add a rendering  on your page  in Experience Editor in Sitecore 10, below dialog opens up -  Due to the structure in our legacy Sitecore 8 application, lots of tabs started appearing in SelectRendering dialog which looked confusing as in snapshot above. This also created another problem. With so

This post intends to get you familiar with where Sitecore keeps code for dialogs that are rendered in Experience Editor and how they can be modified using a problem we solved recently. PROBLEM We may want to hide some out-of-box elements in Sitecore's Experience Editor for meeting specific business needs. In our case, w e were upgrading from Sitecore 8.2 to Sitecore 10.1.1 recently and migrated our vanilla Sitecore sites to be SXA site.  We decided to keep content author experience in Sitecore 10 instance as close as possible to Sitecore 8 so that we don't end up re-training our content authors spread globally almost in every country. Obviously, SXA presents a slightly different interface in Experience Editor and we started finding workaround for them. We observed that, in Experience Editor, while creating/selecting a rendering's datasource, there is a new  Clone Current Content option which didn't exist in Sitecore 8 as in snapshot below -  This option was new to Conte