Sitecore Docs - Tech Tips by GS

The Problem We have a module which has subitems under datasource item. To visualize, the item hierarchy in Sitecore content tree looks like this -  Page Item     Content Folder Item          Datasource Item               Subitem1               Subitem2 According to the feedback from content authors, it has been observed that when they open a page in the experience editor and subsequently lock it to make edits on Subitem1 and Subitem2, the lock is applied not only on the page but also on the Datasource Item, Subitem1, and Subitem2. However, the issue arises when they unlock the page item, as the lock on Subitem1 and Subitem2 is not released. This poses difficulties in situations where another content author needs to make edits on Subitem1 and Subitem2. The Analysis Initially, our investigation focused on any customizations in the local Sitecore instance that could poten...

Do you know when the SXA module is installed, the Item Bucket Settings from  /sitecore/system/Settings/Buckets/Item Buckets Settings are not considered This is because SXA has its own provider for buckets. You can find this defined in /App_Config/Modules/SXA/Foundation/Sitecore.XA.Foundation.Multisite.config: <setting name="BucketConfiguration.DynamicBucketFolderPath" value="Sitecore.XA.Foundation.Multisite.Buckets.SiteBucketPathProvider, Sitecore.XA.Foundation.Multisite" patch:source="Sitecore.XA.Foundation.Multisite.config"/> 

Is sxa_site cookie necessary for Sitecore website? If you are working on a requirement for cookie consent of your site, this question will definitely strike your mind. You would like to know that "sxa_site" cookie is not really necessary for Sitecore SXA websites. According to Sitecore support team, the website still works in case you remove the cookie. So, this is not one of the necessary cookies for cookie consent. Ever wondered what sets this cookie for Sitecore SXA sites? Following code in snapshot is used to set the cookie in Sitecore.XA.Foundation.Multisite.Pipelines.HttpRequest.StoreSiteNameInCookie processor- Even knowledge of such little things can be highly useful when handy at time. Hope you like it!!

 The Problem Recently, we encountered a weird problem where one of our sites in Experience Editor will resolve to default website and not to the correct site. This happened when an author or developer opened Content Editor and tried to select one of the pages in the SXA site and then clicked on Experience Editor in Publish tab to open the page in Experience Editor, the page opened with the following errors -  On checking the logs, we found that logs contains following entries for each SXA site -  We never saw these kind of errors earlier in our logs.  The Solution We started validating what is wrong with our site definitions. To our surprise, everything configured in site definitions appeared normal except the fact that a recent change was introduced to enable Enforce version presence. We soon found out a KB from Sitecore talking about the same problem - https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1002873 According to it -  An S...

The Problem Recently, a Sitecore developer reported an issue where he could not get more than 100 values for a facet field in SXA search component. He tried updating Query.MaxItems and also  XA.Foundation.Search.QueryMaxItems but still did not get more that 100 values for the facet field. The Research I started looking into this out of curiosity. I checked Sitecore configs and did not find any other setting which could be affecting it. I realized soon that this was most likely something limited on SOLR side. On researching, I found out that indeed this is related to SOLR default settings. Below is the snapshot from documentation about it and more info can be found here -  The Solution So, on your SOLR Server, edit the solrconfig.xml for the index you are using. It is found in the conf folder of your index. Find the requesthandler you are using, for e.g. "/select", and add <str name="facet.limit">-1</str> as in snapshot below -       Repeat th...

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 fin...

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...

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...