Jeremy Davis
Sitecore, C# and web development
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?
A while back I wrote a post about how you could extract the raw Solr query from Sitecore's ContentSearch APIs. Usually the queries hid behind LINQ operations, but there are times where having the raw text can be helpful - sometimes Sitecore's API doesn't support the operations you need. That work was done under Sitecore v10.0, but having tried to repeat it under v10.2, I discover it no longer works. There have been some changes under the surface of ContentSearch which require a different approach. So if you need to do this under v10.2, here's how:
After a bit more of a pause than most attendees of Symposium this year were expecting, Sitecore 10.3 is finally out in the wild now. And (to me at least) one of the most interesting changes is that the server-side event model for the CMS has been extended with Webhooks. What does that mean, and how can you make use of them? Well since I was lucky enough to get my hands on the "MVP Preview" of this release a couple of weeks back, I've had a chance to do some digging. Read on to find out...
