Recently Steve McGill asked me if I'd tried using SIF's certificate creation when automating Solr setup for Sitecore. I realised I'd not put any effort into how this might work – and that seemed like an excellent excuse for some research...
A while back I wrote a couple of posts on the subject of how code pipelines can work in a more functional .Net world. I've made use of those patterns in some code of my own, and I've found these posts have generated quite a lot of questions from readers here and followers on twitter. But I've never been quite happy with the implementation in my own code...
Ever been asked to set up a Reverse Proxy to allow a particular URL on your website to fetch its content from a site somewhere else? It's not an uncommon requirement, but it seems to cause some configuration challenges too. Having been drafted in to solve some issues with just such a setup recently, here's a quick description of the stuff I need to remember next time I get this job:
Working on a couple of personal projects recently, I've been reminded again how helpful I find the profiling tools that Visual Studio's debugger gives you. As you may have guessed from some of my previous posts, every so often I get to worry about the performance of .Net code at work – but it's useful for any sort of project, not just Sitecore. And investigating some issues in my own code, memory snapshots and deltas helped me out again. So maybe they could help you too?
Recently I was writing about the changes to Java licensing that Oracle are enforcing in 2019. It's not an uncommon reaction to the challenges that the new license introduces to start thinking about alternatives to how you might manage search for your Sitecore deployments. So what can you do?
It's Christmas, and I'm dreaming of a festive sherry, while I slog through my last working day of the year. So hopefully you can forgive me the flagrant clickbait headline... 😉
But you'd have to have your head in the sand not to have noticed that Oracle are changing the licensing terms for their builds of the Java runtime. They've decided that they want people and businesses to pay for the fastest access to support updates for Java. But as Sitecore developers, many of us make use of Solr – which relies on Java. So what can we do?
There are some things in Sitecore that you just take for granted will work. Loading items is a good example of this. I'll admit that user error can get in your way, but usually if you can see an item in the content tree, you can write code that will load it without issues. So I'll admit I was pretty confused when I came across a scenario recently where this did not appear to work correctly. In case anyone else hits this challenge, here's what happened:
This is one of those issues where I feel like I should have worked it out faster than I did. Computers are relentlessly logical. If you tell them to ignore something, they're going to ignore it, even if that does confuse your content editors...
There's been a bit of discussion (I might even go as far as to say ranting 😉 ) on the subject of not using "fast query" in your website code recently. I'm a supporter of this idea – but I came across an issue recently that points out why it's not always easy to be confident that you're not making use of it indirectly...
So, for the benefit of Google:
So while battling the jetlag that hit me pretty hard getting back from Sitecore Symposium, this issue came popped up in my bug queue last week. QA reported that a certain component on a test page was not allowing one field to be edited. It had worked in the past, but the behaviour suddenly changed so that one field no longer got the "you can edit this" overlay in Experience Editor. It took me longer than it should have to work out why...