Jeremy Davis
Sitecore, C# and web development
It's only a few weeks until Sitecore Symposium**1 kicks off for this year. My presentation is taking shape nicely (more of that later) but I've also been considering what I'll be watching from the rest of the conference... So if you're looking for inspiration, or still on the fence about buying yourself a ticket, here's what I'm looking forward to around this year's event:
Every so often pretty much every developer ends up in a situation where they're looking at a bug that manifests on one platform, but not on another. The sort of bug where you end up spending hours looking through log and config files for a subtle difference. I found myself looking into just this sort of bug recently, but on a site where (to my frustration) the config files were full of comments and whitespace differences across platforms that made diffing really hard ** . Spotting that subtle bug-causing difference is pretty much impossible when your diff is full of noise... So how can we fix that?
In theory, the magic of Dynamic Placeholders lets us have a container component placed onto your page more than once. That didn't work in the old world of "static" placeholders, because the rendering engine didn't like two placeholders with the same name. But despite it's benefits, the dynamic implementation has an annoying edge case – you may not be able to enable caching for your container component. I had a client bump into this issue recently, so I spent some time considering approaches that might help them address this issue.
I've been working on an international deployment of Sitecore recently, and resolving some problems around how publishing raises remote events has demonstrated that there are some things about the publishing process that I didn't entirely understand... I doubt this is a common scenario, but it still seems worth writing down what I've learned – So here's another crib sheet for my future self:
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 had another of my fun chats with Sitecore Support recently, for an issue that seemed to get no useful results in Google when I looked. So, as is my way, I'm filling that search-engine void today. This turned out to be entirely my fault – but it seems like the sort of mistake that others might encounter too... So if you've deployed a distributed instance of Sitecore and found Marketing Automation was behaving oddly, read on...
I hit an interesting issue recently: Some code that worked fine on a QA instance of Sitecore had been deployed for UAT and was now failing with an odd error message. Whilst this issue was entirely our fault, there wasn't much in Google about the error messages I was seeing, so I'm trying to correct that problem today...
I've been looking at adjusting SIF scripts for a production deployment recently, and realised that sometimes you'd like SIF to generate random passwords for you, but you need them logged so you can reuse them in scripts you're crafting for other roles. It doesn't do that out of the box, but it turns out it's actually quite simple:
One of the projects I'm working on at the moment came with a requirement to change Sitecore v9.1 from running with the default SQL Security accounts to trusted connections using specific Active Directory accounts that the client provided. While there's a bit of work to do to enable this, it shouldn't be too tough. But trying to be a bit clever, I hit upon an issue which seemed worth documenting...
I've been using VS2019 for all my personal development work pretty much since the first preview came out. For general coding and debugging it's been good so far – stable, and effective. And little things like git stash control from the UI make me happy... It got its full release recently, just before I spoke at SUGCON 2019 – where I said I'd blog something about how 2019 changed the performance measurement stuff that I was presenting. Having done some tests in the last few days, it's not looking so shiny any more...
