Jeremy Davis
Sitecore, C# and web development
It's easy to get distracted by all the shiny big features that get deployed in new releases of Sitecore, but every so often a little gem slips past almost without comment. Except in the release notes...
The one thing that is true of every aspect of IT is that it is always changing. And that change means that things you were confident of in the past may no longer hold true.
I was reminded of this while sitting in the pub with some developers recently, talking about querying for items by path in Sitecore. The debate about the best way to do this raged, but a common thread of the debate was that it is often said that the fastest way to find a set of items you needed is via a ContentSearch index. That assumptions has its roots in the time when most sites were using Lucene to run queries, and for queries with more complex matching rules. But does that hold true here?
Every so often you come across a small config change which does stuff you just did not expect. I hit an issue around this recently, which I figured I should document to try and prevent anyone else getting to spend time with diff, scratching their head for as long as I did...
When you're working with a "provider" model for services in your applications you get used to the assumption that everything follows the Liskov Substitution Principle and whatever provider you plug in will work in the same way. Unfortunately, for software our in the real world that's not always entirely true. Recently I came across an example of this which helped point out a bug in some search code in Sitecore...
One of the big things in IT security in recent times has been the successful attacks black-hats have launched against the infrastructure of cryptography. As we all come to rely on encrypted communications more and more, the vulnerabilities in old ciphers have become more of a problem to us developers and administrators. Vulnerabilities like Drown and Poodle are just two examples of a trend which means we all now have to worry about how our crypto is configured before we allow the internet to see a server.
But whenever you tie down security more tightly you risk causing problems when software relies on the thing you've just disabled...
I spent some time recently investigating why certain aspects of the Coveo for Sitecore search framework were broken on a client's server, and the answer ended up being directly related to crypto security. Here's what happened:
Every website needs to be able to deal with requests for pages which don't exist – some sort of 404 handling is a feature of pretty much every Sitecore project. But, as I discovered when sorting out an issue on a client's site recently, it's a bit of code which can bite if you're not careful...
Wild times in the Sitecore world, as the release of v8.2 is has brought a load of new features. One I'm particularly pleased about is that there is now an official NuGet feed for your Sitecore references. I've been asking pretty much every Sitecore employee I've spoken to about doing this for years now, and finally it's here.
So now I've read the release notes and finished a quick chair dance of joy, it's time to dive in and see what it's all about...
Following on from last week's "how to host private NuGet feeds in Visual Studio Online", this week we'll build on that to get some code to compile and some Sitecore.FakeDB tests to run and Hedgehog TDS to generate a deployment package in the cloud build.
While I've read plenty of articles in the past about configuring build servers for Sitecore projects, I've not seen much written about using Visual Studio Online. (Or "Team Foundation Services", or whatever it's called this week) Since the company I work for are in the process of transitioning all their development infrastructure to Azure, trying to get hosted builds working in VSO seemed like a userful area of research for me. This is the first part of what will probably turn into a few posts on the topic of how I got to the point of being able to run a hosted build for a Sitecore / TDS / FakeDB solution...
A colleague of mine has been looking at some custom page events and reporting in Sitecore 8.1 recently. One thing which came to light during this work is that some of the personalisation rule code in the product didn't appear to work as expected. In case anyone else is looking at this aspect of the software, he's a summary of the issue we were seeing, in the hope that it can help you avoid the time we spent looking into this:
