Jeremy Davis
Sitecore, C# and web development
Since the whole "Twitter's in something of a downward spiral" thing kicked off, I'd been musing over the idea that having embedded tweets in my blog might not be such a good thing long term. What happens if the mad billionaire at the helm suddenly decides that embedding tweets should be a paid feature, or the site has a long outage? The best alternative I had was to turn the tweets into images - so obviously I investigated how I could automate this. Turns out it was a fun feature to add to my blog editor...
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:
One of the interesting announcements from last year's Symposium was Sitecore's approach to how we might join up our composable applications. They announced that they were working on "Sitecore Connect" at this event, but didn't really get into detail of what it would be outside of "we're re-badging Workato". So what is that, and what does it suggest we might get out of Connect in the future? Read on, for an attempt at working that out...
I've been migrating a big chunk of .Net 4 code to .Net 7 recently. One of the few large changes I had to make was to replace some boilerplate generation that used T4 Templates with a Source Generator. (As T4 isn't entirely supported in latest .Net) But these work very differently, so that change involved a good chunk of work. But I messed this up in a way that caused a subtle bug. And while I may well get to writing about Source Generators later, that silly bug is also worth writing up. Even if it's just to remind me not to make the same mistake in the future...
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:
Computers. Very useful when they work, but wildly frustrating when they don't. Recently I had one of those moments of frustration (well, two days actually) with Azure Devops and its YAML-based build pipelines. The root cause here seems like one of those things that could well bite others, so here's what happened to me...
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:
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:
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...
