Operating a Cache You Cannot Live Without: Diagnostics and Manual Control for the Managed Cache Layer

There are only two hard things in Computer Science: cache invalidation and naming things.

Phil Karlton

The line gets quoted to death because it keeps being true.

In the previous post I described a transparent managed caching layer for Sitecore XM/XP that wraps any serializable result set with almost zero ceremony. Template-based auto-flushing, custom delegates, cross-instance propagation via the event queue. We ended up leaning on it for nearly every expensive recurring computation in the solution: Solr result sets, generated links, filtered and sorted lists, custom item resolvers, multi-source aggregations. Once a cache layer is load-bearing across that much of an app, Karlton’s first hard problem stops being theoretical.

A Generic Managed Cache Layer for Sitecore XM/XP That Almost Writes Itself Into Your Code

Sitecore XM/XP solutions accumulate expensive recurring computation over time. Index queries, link generation, lists that need to be sorted and filtered, custom item resolvers, multi-source aggregation. Each of these recomputes the same answer on every request, and most of the time the inputs have not changed since the previous publish. The opportunity is obvious: cache the output and invalidate it when the underlying content actually changes.

In our case the symptom that finally forced the issue was Solr query quotas. The client’s solution leans heavily on Solr for content aggregation, faceted search, and product listings, and was hammering it hard enough to bump against the allocated limits on a regular basis. Scaling Solr is neither cheap nor instant. But Solr was just the loudest example. The same recompute-every-request pattern applied to several other paths in the solution that were not yet in pain but would have been the next bottleneck.

Can I Lick It? A Periodic Table Guide

I saw this on a t-shirt and had to know whether the verdicts hold up. I did what any responsible nerd in 2026 would do. I asked AI to fact-check the lickability of every element on the periodic table. Hover any cell for the why.

Please do not actually lick any elements. Not even the green ones. Yes, the chart says gold is fine. Yes, you can technically eat gold leaf. But “technically safe to lick” and “a good idea” are two very different categories, and this blog post is not a permission slip.

Making the SXA Site Provider Asynchronous for Sitecore XM/XP at Scale

One of the things I love about Sitecore XM/XP with SXA is that site definitions live in items rather than config files. You add a site, you rename a site, you delete a site, and nobody has to restart the application. The SXA site provider reads from the content tree, rebuilds its internal site dictionary, refreshes MVC routes, clears caches, and the instance is ready. Elegant.

Until you have two thousand sites.

Reducing Sitecore SQL Server Calls by 7-10x with a Caching Data Provider

While profiling a Sitecore XM/XP 10.x solution I noticed something that made me do a double take. Hundreds of SQL calls per single page request. Not complex queries either - simple, repetitive child item lookups hitting the database over and over again.

This turned out to be a missed caching opportunity in Sitecore’s SqlServerDataProvider. Specifically, the GetChildIdsByName method gets called every time Sitecore needs to resolve a child item by name under a given parent. On a content-heavy site with deep trees and lots of renderings, that adds up fast.

App settings in environment variables in Sitecore.

Creating back-end integrations is inevitably linked with having to authenticate against a remote endpoint. Be that a Rest API, FTP or an APM - secrets (credentials, api tokent, shared secrets) of some sort will be involved in the process.

Those credentials must be stored somewhere. At this point I hope no one even considers hardcoding those but even if you extract them to configuration - having them exposed in your repository may be a bad idea and is frowned upon by tools like SonarQube.

Roll out multilingual item branches en masse using Sitecore PowerShell Extensions

I’ve received this nice comment on one of my earlier posts and I thought it might warrant a blog post since it is a nice little challenge and might be useful for more scripters in our community.

Hi Adam, thanks for the pointers on PowerShell! There’s one in particular I’m hoping to get some help with, if that’s ok? I have created a Branch Template in Sitecore, and I want to deploy it under every item in the Content Tree that uses one particular page template (about 200 instances of deployment, in this case). For an added bit of fun, there will be several different language versions being deployed along the way, so I guess that prevents me doing a blanket rollout. Could you please recommend a script that is along the lines of “Add this Branch Template under this Item ID in the following named language codes”? I realise I would then be repeating that line 200 times with varying parent item ID and languages, but I can live with that if that’s the easiest way to do it. Many thanks for your help! Phil Neale

Read More · Comments

Do not turn Sitecore Media Request protection off and protect older Sitecore versions with ImageGuard

The post is related to the image resize vulnerability fix introduced in Sitecore 7.5. To read more about the Sitecore fix go to the Release notes page and search for ?Media request protection?. While I was holding off for a number of months on the publication of the post as it puts the attack vector in plainer sight that I would like it to be (while the community figured out how to work with Media Resizing in a neat way) - but recently I’ve seen voices raised considering turning the Media Request protection off which I hope you will not be doing after reading this post. The post will also tell you how to enable such security on your older versions of Sitecore. So here’s the story…. At some point in Cognifide we have performed a research around Sitecore security and one of my colleagues (Marek)  found out that you could easily kill any Sitecore instance by performing an image resize attack on it. While the CMS did some rudimentary checks and limited the values of height and width you could still perform an attack by harvesting the images from the site and perform multiple parallel & iterative size increase or just plain use the scale parameter to achieve any image size. A result of such attack would be a a denial of service due to 100% CPU & memory usage and would potentially allow for filling the server drive by creating the endless number of scaling calls. Marek was even kind enough to provide a proof of concept code that confirmed the hypothesis by performing attack on a few of our internal servers. The program would load the home page; parse to find images linked from it and perform resizing of the images in a number threads.

Turn your Sitecore PowerShell reports into applications with Action Scripts

In one of my previous posts I described how to create reports in Sitecore PowerShell Extensions (SPE for short) that allow you to leverage the joint power of Sitecore and PowerShell to deliver complete and elegant reports in little to no time. In this post I’ll tell you how to take this a step further and operationalize them into full blown Sitecore Desktop applications. The secret sauce is in the actions you can place on the report, the additional parameters that I haven’t mentioned in the previous post, and the use of Sitecore rules engine with some rules that come with SPE. For the purpose of this post I will limit the scripts to samples that are (mostly) in the vanilla SPE deployment. Let’s begin with describing the actions and how you can configure them to appear in your reports.

Rapid API prototyping for Sitecore with PowerShell Extensions

This post describes how you can deliver JSON/XML/HTML APIs quickly with Sitecore PowerShell Extensions. Technically this was also available earlier but the API was not refined to the state it is now. As Sitecore is constantly progressing from predominantly serving as a  CMS towards becoming a mobile and web application delivery platform (which is very apparent by the recent increase of SPEAK popularity, the introduction of Item Web API and the app centric nature of the new Sitecore 8 interface there is an increased need to rapidly deliver APIs for those those front end applications to work seamlessly with the CMS back-end. PowerShell Extensions can help you with that move by enabling rapid prototyping of APIs that are either JSON or XML in nature.