Jeremy Davis
Sitecore, C# and web development
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...
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 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:
Recently, I caught sight of a discussion in Sitecore Slack where the lack of tooling for helping you build config patch files came up. For some reason that struck a chord with me, and having mulled over it a bit, I decided I'd have a go at making something to see if it could be done...
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?
Sitecore's config patch files are great. But sadly it's entirely possible to cause yourself headaches with them. I've written before about how it's possible that small typos can cause big issues. In that style, a colleage brought an issue to me recently which was an interesting new variation on this fun...
My first time having to configure Solr for Sitecore recently taught me a variety of new things. (I know – how have I managed to avoid it this long?) Most of the basics of the setup have been well documented elsewhere, so I won't repeat any of that. However setting up the site to use the Ninject DI container wasn't as smooth as the documentation suggested, so here are some notes on the issues I hit in case you find yourself stuck:
I've spent the last week or so working on the config changes necessary to migrate a client site running Sitecore v8.1 from using Lucene to Solr for its search infrastructure. I've not worked much with Solr before, so this has been a good opportunity for me to learn about how it works and how it gets configured. But when I deployed my changes from my local development environment to a central testing server I discovered some odd behavior which Google didn't help with. So, for the good of search indexes everywhere, here's what happened...
