Jeremy Davis
Sitecore, C# and web development
An issue that crops up fairly often in web agency work is that you have to work on code for older versions of Sitecore. Most of the time this is fine, but sometimes in between the Sitecore version getting released and you doing this work, stuff changes in Windows that makes this setup harder than it should be... This has been a challenge recently as some of my fellow developers now have Windows 11 on their laptops, and they're having to work on Sitecore 10.2 projects. And out of the box, SIF or SIA won't install in that scenario these days. Having had to help a couple of people with these issues recently, I figured it might be worth automating the fixes with some Powershell, so it's easier in the future. And maybe that automation might help you?
I've written a few things about diagnosing memory issues in Sitecore over the years, but one topic I've not covered in detail is anything around "how to spot when it's not piles of your own objects that's causing the issue". Problems like leaking handles can have an obvious link back to the custom code that you can spot fairly easily in diagnostic data. But not all memory issues do. I was discussing a possible example of this with a colleague recently, and it seemed like another thing to write down...
When I was writing about dealing with memory analysis for Sitecore recently I focused on a site running under Auzre PaaS. But what if you're working in Docker locally? A good question it turns out...
Recently I got a fun question from a fellow dev: After pulling some changes and doing a sync of serialised data they were expecting to see some forms in the Experience Forms editor so they could work on them. But nothing was showing up... The root cause here is a bit of a classic issue that many people will have seen before, but it still seemed worth writing it up. Even if just to emphasise that this has been around for a while and it's still a thing even if you're using containers.
I wrote about diagnosing some issues with static event bindings in a previous post, and talked about finding these issues of "subscribing more than you unsubscribe" with memory dumps. But finding this sort of a problem before it becomes an issue is better if you can, so what techniques might we use for that?
After my recent delve into memory optimisation for non-work code, I spent some time recently investigating a memory issue in a production Sitecore site. The outcome of that was an issue which can be a common problem for .Net code. So in the hope of seeing it less in the future, here are some notes on what I saw and how you can avoid the same trap...
Symposium is over for another year. I have mostly recovered from the jet-lag now and I've wrestled my inbox into submission at work. So it's time to write up my thoughts on the conference. I took about 35 pages of notes over the course of the week, plus countless photos of slides. So from all that what stuck out as interesting to me?
I quite often clone Sitecore's Docker Examples repo and spin up a Sitecore instance to experiment with. It's a quick way to create a disposable site which I can easily configure and deploy little bits of test code to. But recently I did this and noticed some odd warnings. So here's what happened and why, to help you avoid the same issue...
Data Template inheritance. Most of the time it's great and a powerful tool to help you define your content schema effectively. But there are a few places where it can trip you up - and one of the interesting ones is duplicated field names. I found myself chatting about what actually happens and how this might affect PowerShell scripts and headless code recently, and it seemed worth writing down...
I had a moment of frustration recently, when I spent a while looking for a Data Template in a particular Sitecore site and couldn't find it because a previous developer had set a Display Name. As a result of moaning about this Corey Smith reminded me of a way I could have helped myself here, and it seemed like something to share...
