Jeremy Davis
Sitecore, C# and web development
The other day my copy of Docker Desktop on two different work laptops prompted me to update. And neither would work properly after the update completed. In case this issue is affecting others, here's the saga of what I saw and two ways it can be fixed:
I was hacking up an app as a personal project recently, and decided to try out the latest preview (Number 7) of ASP.Net Core for .Net 7. I happened to be deploying this project to a server which had never run ASP.Net Core before, and that deployment left me scratching my head for some time. So in case this issue hits others, here's what happened to me:
One of the challenges you often deal with using software that's under active development, is that as you take the lastest updates you can find that they subtly change (or break) the behaviour of the tool - affecting stuff that used to work for you. I had a classic example of this recently with this blog. An update to the Statiq engine fixed something in the core library code and created a subtle issue for my website. Since the docs for Statiq don't make this obvious, here's some information for anyone else finding this problem:
Following on from my recent post about how I was able to mess up my life by getting Marketing Automation connection strings wrong, I hit another interesting issue with MA – this time around content languages...
I got a fun support ticket recently, for a client on Sitecore v8.1 whose analytics processing had stopped working. Their outstanding queue of raw analytics data that needed to be aggregated was slowly growing, and some functionality which relied on the existence of recent analyics data had stopped working. Trying to fix this caused me to look at two issues which are related to how Web Forms for Marketers data is processed in analytics – and these seemed like issues that other people who do support work might need info on...
There's been a bit of discussion (I might even go as far as to say ranting 😉 ) on the subject of not using "fast query" in your website code recently. I'm a supporter of this idea – but I came across an issue recently that points out why it's not always easy to be confident that you're not making use of it indirectly...
So, for the benefit of Google:
As time goes on, something I've noticed is that as Sitecore evolves it is taking a greater reliance on search integration – making things like Solr ever more important. And that leads to an exciting new set of issues you come across if, for some reason, your search service is not available.
I wasted some perfectly good development time recently when some of my renderings vanished from published pages, thanks to this.
Something I've learned over the course of many years working in IT is that when you hit a difficult to explain problem it's very easy to say "it's the runtime's fault!" or "that's a compiler bug" to cover for the lack of explanation for your problem. The vast majority of the time, it's not true though. It's just a subtler bug in your own work that you can't see yet.
Every so often, however, it is true. And it turns out the issue I discussed the other week about Sitecore rendering a Razor error when you asked for a media item may well be an example of this.
If you spend your life working with software, you can't help but collect a few stories of issues that defied your understanding – and I came across a great example with Sitecore recently. I haven't managed to decide if this is an issue that can happen to others, or whether it was completely specific to the setup of this particular site. But since I got few useful results from Google when I was trying to solve this, I figure it's worth writing about it just in case someone else sees a similar problem in the future...
It's nearly Christmas, and before I head off for a bit of a holiday, here's a quick bug issue you might encounter. Despite the increasing power and sophistication of the search technologies in Sitecore, sometimes we still need to fall back to good old-fashioned Sitecore Query. A common reason for this is because the query you're writing depends on the structure of the data, not its content. Recently a colleague of mine pointed out some issues to me with the way some queries are resolved, which I thought might be of interest to others.
