Next's Link component from Next.js can prefetch pages when the component enters the user's viewport or is hovered. This allows for faster client-side transitions.

However, this prefetch functionality breaks down when the Headless site is loaded through Experience Editor, Sitecore Pages, or a non-editor experience such as a preview. This leads to excessive calls to the backend that report as 404s.

Hovering over a link in Sitecore's Skate Park demo site in XM Cloud, the network tab in developer tools shows the request triggered from the prefetch fails.

This is due mainly to prefetch requests operating relative to the site domain. If the site were loaded on Vercel, this would work as expected.

Next.js provides a way to disable prefetch on the Link component with:

https://nextjs.org/docs/pages/api-reference/components/link#prefetch

Depending on where Next.js is deployed, this prefetch could be set by environment variable:

However, the Link component in Sitecore JSS is limited in the props it feeds back to Next Link. Prefetch is not an option, as shown below.

Only workarounds can address the issue until Sitecore provides an elegant way to fix these requests in this context.

Another workaround is to use Next.js experimental configuration 

This allows not having to remember to set this on every Link component. However, as indicated, the setting is experimental, and there is little documentation on exactly what this setting does if it only impacts Link components.

If experimental settings do not sit well with you, another option exists.

The Next router for prefetch can be updated to unset the async function responsible for triggering the request.

This approach was suggested in the Next.js community as described in this issue 

https://github.com/vercel/next.js/discussions/24437

All these options can work depending on how they best resolve the issue for your Sitecore environments. Disabling prefetch in either lower environments or preview environments does not degrade the experience or is not a critical feature for editors. Hopefully, Sitecore can determine the best fix for this issue and make it into a future release.

If you need to follow up with Sitecore Support on this issue, this is a logged issue 

https://github.com/Sitecore/jss/blob/main/packages/sitecore-jss-nextjs/src/components/Link.tsx

https://nextjs.org/docs/pages/api-reference/functions/use-router#routerprefetch

Sitecore JSS Link and Prefetch

 (Sitecore 9.1 and above) and in Sitecore 

 when the Path Cache under Cache Key Indexing was enabled on Content Delivery servers on Sitecore.

The issue occurs when an item is unpublished and later published to the publishing target or the Web database. The changes would not be available on Content Delivery servers for components dependent on them. It wasn’t until an Application Pool Recycle that these items became available.

For the components dependent on finding the item in the target database, these components would get the Sitecore Item by the path. As the developer community recommends, getting an item by path is not the best option. Sitecore maintains a path cache where the determined path of the item is mapped to its Item ID. Getting a Sitecore Item by Item ID is always better. But, sometimes, you can't get around it.

Cache Key Indexing is usually enabled for large solutions. It was enabled on the solution because Sitecore Support recommended it due to the large content database size and to solve a previous problem. But, ultimately, we found that Path Cache on Cache Key Indexing is something we could do without.

💡 Sitecore Documentation on Cache Key Indexing - 

https://doc.sitecore.com/xp/en/developers/102/platform-administration-and-architecture/enable-cache-key-indexing.html

As part of troubleshooting, cache clears were inspected by reviewing records in the Event Queue table after a publish, and event records were processed by the Content Delivery servers.

After validating that the Event Queue was getting processed, a different approach was attempted by changing how the Sitecore Item was retrieved. It was found that the problem would show when 

Sitecore.Context.Database.GetItem("/sitecore/content/.../myitem")

 was used. The issue would not occur when 

Sitecore.Context.Database.SelectSingleItem("/sitecore/content/.../myitem")

 will depend on the Item Cache. Upon inspecting the Item Cache, it would show the item on the Content Delivery server. So what is the difference between 

After Sitecore Support did a bit of digging, it turned out to be the Path Cache. Inspecting the Path Cache on the Content Delivery server would show the path entry with the expected Item ID like 

 when the path has never been in the cache.

But, when the item is unpublished, the path will be stored in the cache with an empty Guid.

After republishing the item, the ID is never updated.

The Path Cache would not clear with the Cache Key Index enabled. 

Disabling the Path Cache under Cache Key Indexing solved this problem.

This issue is expected to be fixed at some point with later releases or a cumulative patch. The reference number of the bug report is 157425.

Path Cache Key Indexing Bug

In the previous post, we covered some of the gotchas with upgrading Sitecore CLI and how the Management Service may have dependencies that current projects may have dependencies on (for example, NuGet packages). If that post was missed, read more about it 

. For Sitecore CLI to work, the correct version of Management Service must be installed.

This post will cover more on dealing with the Management Service module installed on the Sitecore container with Docker.

. For Management Services, two places define how the Docker image for the module is brought in and apply it to your Sitecore container.

Additional information about how to set up your Sitecore modules with Docker can be found here: 

https://doc.sitecore.com/xp/en/developers/102/developer-tools/add-sitecore-modules.html

 container. This stands for the Content Management instance running under Docker. If Docker runs a Sitecore container configured for a Standalone role, target that container for these changes.

In the environment variable in the example above, the Docker image for Management Services is set to 4.1.0. In this effort to upgrade Sitecore CLI, the Docker Image must be 5.1.25. To find the right image, Sitecore publishes a list of images here:

https://raw.githubusercontent.com/Sitecore/docker-images/master/tags/sitecore-tags.mdhttps://raw.githubusercontent.com/Sitecore/docker-images/master/tags/sitecore-tags.md

The image for this is listed here in the Docker images from Sitecore:

5.1.25-1809 | 10.0.17763.3406 | 1809 | amd64 | windows | sha256:e365ce2096dadf26386a5f170d7d0b8905a5fb51124f369c43f67c81211cd854 | 10/12/2022 16:30:25 | 10/12/2022 16:30:25|

 and update the Management Services reference.

Applying the changes may not be as easy as bringing the containers down and back up. First, the Management Services Image is set within the environment file. In this case, it has no impact when the container is brought up. Second, the CM container is based on an image built with the previous Management Services module, so the image must be rebuilt for the CM container to have the appropriate updated version.

Let's work out a couple of Docker commands to address this.

We won't have the image for 5.1.25, so let's ensure we have it.

 is a placeholder to replace the name of the container instance running Sitecore (Content Management or Standalone).

 in subsequent commands to address the running container. If the container is stopped and removed, this step and the next step will be unnecessary.

  3. Stop and remove the container so the image can be removed.

 is a placeholder to replace the image built for your Sitecore container.

 is important as the build may take the cached image. Additionally, the name 

 should match the name used in the Docker Compose file for Sitecore.

This will start whatever is not running. To target the CM container, the service can be specified.

Applying the changes across the team may not be as easy as pulling the latest from source control. Also, as we found out, they cannot just bring the containers down and back up. First, the Management Services Image is set within the 

 file, and this file is not tracked by source control. Second, they need an easy way to rebuild and start their new CM container.

A PowerShell script can be checked in for every developer to run after they pull the latest.

We need the PowerShell script to handle everything:

 to the newer version of the image and pull the image.

Remove the image that was built for the CM container.

We can combine everything we did to get our Docker container setup with additional helpful steps. To update the environment file, the script must utilize 

. Version 10.2.7 was used for this script.

Next, the steps to handle the container and the image.

https://gist.github.com/edames/6ecf42761e7cf31152143e89d493fa81

The blog post is part of a series of blog posts on how to upgrade Sitecore CLI with Docker and manage the tooling with deployment tooling. Going back to our process diagram:

This series will touch on these areas and how upgrading Sitecore CLI requires more to think about.

If automated checks are part of the process to validate a healthy branch, these checks will need to be validated that the upgrade for Sitecore CLI has not impacted that automation. The next blog post will touch on some of this.

Upgrade Sitecore CLI and Docker

Pipelines are a great illustration, and how Sitecore items flow from development to production is a critical process to keep things moving.

When we upgraded to Sitecore 10.2, Sitecore CLI was embraced as the new development workflow and deployment tool. Sitecore CLI promotes Sitecore items the development team builds as part of the CMS. Below are some of the workings of how we used Sitecore CLI. Many steps are excluded for brevity...

What is highlighted where Sitecore CLI is used:

Plugins depended on 4.1.1, and we needed to go to Sitecore CLI 5.1.25 as the 

Updating the tool and the plugins was the easy part.

First, we need to make sure we meet our dependency on .NET Core 6, so we run:

If we are at least 6.0, we can move forward with upgrading. Most developers may have this by default on their workstations if they install a later version of Visual Studio. If you need to, pick up the appropriate version here: 

https://dotnet.microsoft.com/en-us/download/dotnet/6.0

Now we can proceed with upgrading the tool:

dotnet tool install Sitecore.CLI --version 5.1.25

https://sitecore.myget.org/feed/sc-packages/package/nuget/Sitecore.Cli

 to use the correct versions of the plugin:

Finally, we need to install the Management Services package on the Sitecore instance that matches the version we are updating to: 

https://dev.sitecore.net/Downloads/Sitecore_CLI.aspx

If you have Sitecore running under IIS, then Sitecore Package is the way to go. Download the package under 

Sitecore Management Services Module ZIP Package

From here, we should be able to complete the following:

 is excellent if you want to see what happens without doing anything.

If everything goes well, then you should have some success messages in green such as:

[master] Discovered 3 changes after evaluating 286 total items.

But here is where things get tricky. If you are a good developer and want the rest of your team to use the latest and greatest, you want to ensure you test. So you publish your Visual Studio solution and test Sitecore CLI...

After going back through the previous steps and double-checking, the upgrade was at a loss. The message needed to be more evident regarding where the issue was occurring. But, the clue was when the project was published in Visual Studio.

For us, it is more challenging than looking at one project. We have at least 20+ projects in the Visual Studio solution.

So, we went to the Management Services package we installed earlier on the Sitecore instance and reinstalled it. Sitecore CLI started working, so we must have something we are using in our solution that Management Services depends on.

Opening up the Sitecore package, we can see we had these assemblies:

Searching through every reference in every project, we found that our project that extended GraphQL depended on 

So, we upgraded them to the versions Management Services was using. After finding all the references and upgrading the versions to 

This series will touch on these areas and how upgrading Sitecore CLI requires more to think about.

The next post will be on Docker - 

https://www.ehrendames.com/upgrading-sitecore-cli-and-docker/

https://doc.sitecore.com/xp/en/developers/102/developer-tools/sitecore-command-line-interface.html

https://doc.sitecore.com/xp/en/developers/102/developer-tools/install-sitecore-command-line-interface.html

Upgrading Sitecore CLI for Developers in Local Environments

I ran into a dilemma recently with making some changes to the 

 that was purposed for a site in a multi-site Sitecore instance. With Solr, I was attempting to implement EdgeNGram for searching and realized adding a field mapping for a new field type in the index impacted all my indexes for the other sites.

Implementing EdgeNGram was fairly straight forward as 


was very helpful. However, I didn't want to introduce this to all the sites. So I needed some way to limit scope of my configuration change to only my site.

The field map matches to a new field type that was introduced in the site's 

 in Solr. However, I found that it would break all the other indexes since this field map was patched on the default Solr configuration.

To get around this, I created a duplicate of 

Sitecore.ContentSearch.Solr.DefaultIndexConfiguration.config

 and titled it after the site for example 

Sitecore.ContentSearch.Solr.MySiteIndexConfiguration.config

There are a couple of updates to the file that need to happen so we are not duplicating settings and so we have our own configuration for 

 and leave all the children in between them.

At the end of the file, we need to delete the 

 node as this will not matter and will only duplicate settings and pipelines.

We can also check the Sitecore logs to see if it is reporting any duplicate configuration when it starts up.

Next, we just need to update our index definition for 

 to reference the configuration and update our patch file for adding the field mapping.

 to reference our new configuration and not the default.

I found this to be a quick and easy way around limiting the change to indexes in Sitecore. The last thing I could have done was moved my field map to 

 instead of having an extra configuration file to patch the Sitecore config.

Minimizing Schema Changes to Sitecore Indexes

In recent work with Sitecore, Solr has been recently introduced to some development I have been working on. The work required writing several instances in which we needed to query Solr for some information. At this time, I wanted some way of profiling and logging how these methods were operating, but I didn't want to bog down my service class with dependencies on logging and profiling.

 which has been a fantastic book on design patterns and SOLID. Here I am going to apply a couple patterns to keep my code more adaptable and maintainable over time.

Design Patterns I will try to put into practice are:

Let's get started with an example. Below is a simple class that searches Albums based on keyword:

I have added an interface for the service class because interfaces are great to hand to a client and not be specific to some concrete class. The client doesn't need to know which class implementation I hand to it.

In order to not introduce profiling logic to my 

 method, I am going to introduce the Decorator Pattern. The Decorator Pattern has a couple of requirements to make this work:

MusicSearchService needs to become an abstract class while making the SearchAlbums method an abstract method.

ConcreteMusicSearchService needs to be created to override the 

 method which we will move the search logic to.

MusicSearchServiceDecorator also will need to be created to allow us to implementing some activity such as profiling away from the search logic.

Normally, I would have been more specific in naming these classes, but I wanted to what is the decorator and which is the concrete class. Since I was creating a decorator for profiling, I would have named the class 

. Also, I would have named the abstract class 

As part of profiling the search logic for albums, we want to utilize the stopwatch to measure the execution time. However, I may want to create an adapter class to wrap around the stopwatch implementation I want to use. In the future, there may be other implementations of stopwatch I may decide to use down the road. Or, as the Adapter Pattern suggests, I may have an implementation that may be incompatible to use and I may want to wrap around this incompatibility.

We will also create an IStopwatch interface to inject into the decorator class.

Let's update our decorator class to inject the stopwatch implementation:

Finally, what we can do next is implement a Logger Adaptive Class the same way and log the information we want from profiling.

At this point, everything has been written to be fairly testable. I can mock these classes and create some unit tests if I needed. I have also separated my profiling away from my Albums search implementation and my 

All that is left is to when to turn on profiling. There are several ways I could approach this such as utilizing some dependency injection with my service classes or let a factory class to my Music Albums functionality determine when to start profiling.

Initially, we can start with a factory class as follows:

Let's add some logic to determine when to profile. Here I added a grab a setting from Sitecore settings. This can be done independently by configuration or from a Sitecore content item. I am going to allow this to be injected into the factory class's 

Here is what I love about interfaces, the client doesn't need to know what I hand it as long it can expect what the interface tells it. Here, I've either handed it the concrete class or the decorator class depending when I want to profile.

 the author of Adaptive Code via C#. You can see another example of this in action at 

I hope this was practical. As I have been learning the concepts of SOLID, these design patterns have given me another tool to create some clean and maintainable code.

Posts

Sitecore JSS Link and Prefetch

Path Cache Key Indexing Bug

Upgrade Sitecore CLI and Docker

Upgrading Sitecore CLI for Developers in Local Environments

Minimizing Schema Changes to Sitecore Indexes

Separating Responsibility with Sitecore