I wasted a few hours recently when I did something which seemed entirely reasonable with Rule-Based Config in Sitecore and it did not work the way I thought it would. Here's an explanation of what I did and what happened as a result, so you can avoid making the same mistake as me...
There aren't that many places where RSS gets used these days (Shame! It's still good!), but that doesn't stop the occasional requirement for it coming up in projects. Recently I was having some discussions about how a client's site could offer RSS for their content which included custom UTM codes in the feed links. That's not too tricky to achieve with Sitecore, so here's an example of what you might do.
I had another "things work differently in containers" moment recently. One of the fun points of changing the approach to your deployments is that sometimes you have to look differently at how some core configuration issues too. And this seems like an issue others will encounter too:
Some time back I did a load of work on performance diagnostic work on some poorly performing Sitecore websites. (Which was the basis of a talk I gave a few times) I've recently had to look at some similar issues - but the world has moved on. I now have Visual Studio 2022 as my diagnostic tool of choice, and the websites are commonly hosted in Azure PaaS web apps. So what do you have to do these days to diagnose likely places for your code to be stuck?
A colleague pointed me at an interesting issue recently, where trying to switch the Sitecore Desktop to view a "preview" database for a Publishing Target on a client's website caused a crash. The reason for this appears to be an interesting issue it would be fairly easy for others to trip over, so this seemed a useful thing to write up:
I'm not much of a front-end person. While I can do JavaScript and CSS if I need to, I tend to have to spend quite a bit of time in Google remembering all the key facts. But every so often I find myself needing to do some client-side code, so anything that can make that job easier seems like an interesting idea. Recently I came across the htmx framework - which offers a way to do common AJAX-like dynamic front-end tasks with little ceremony, and pretty much zero JavaScript. So I figured I should have a hack about and see if it's of any use with the sort of "traditional" Sitecore I'm confident with...
To customise a very old joke, there are only two difficult issues in IT: Naming things, Time calculations, and off-by-one errors. And adding containers into the mix raises even more fun. I recently hit an issue where containerised Sitecore needed to use a different time zone to the physical servers it was hosted on. So what can be done to configure this? Here's two things that can help:
A while back I wrote up some notes on a problem some people were seeing with Sitecore's SolrCloud developer container that I'd been unable to fix. It was the worst sort of technical problem, happening irregularly on some computers, but never rearing its head on others. So it's taken me a while to get around to coming up with a fix for this. But if you've suffered from the problems described in my previous post, this is an option for you:
A requirement which comes up every so often is that external systems need to know about changes to content that lives in Sitecore. As with most technical problems, there are a variety of ways that you can solve a problem like this, and they all have different pros and cons. One of my colleagues has been working on a project like this recently, and the approach required there meant we bumped up against an interesting configuration challenge. If you're writing code that monitors content changes you might need to think about this:
Most of the time when I want to explore the filesystem of a Sitecore container, it's pretty easy. I can use Visual Studio's container browser. But that only works when a container is running - and if it's based on a job image this may be a very brief window - too brief to find and explore the file in question. So what can I do?