Jeremy Davis
Sitecore, C# and web development
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...
Another helpful addition to the "scripted installs" functions I've been looking at for the last few weeks is the ability to trigger a full rebuild of a search index. Last week we looked at deferring the indexing of items installed by a package to try and help speed up the scripted install of packages. So it makes sense to be able to trigger a build as well...
The other day a colleague remarked on how much time was wasted navigating down to the search index rebuild options in the Sitecore 6.6 Control Panel. While there are a variety of other ways of triggering a search rebuild, (Sitecore Rocks for example) it was suggested that having a button on the Ribbon (as per Sitecore 7) would be helpful in this case. So here's a quick set of instructions for one way it can be added:
I've written before about filtering data in Lucene searches if you're still using Sitecore 6.x. Having been doing more legacy work on this front over the last couple of weeks, I've got a couple of new things to add. Previously, the search work I'd been doing had relied on the default "relevance" sort order, or LINQ OrderBy clauses. However recently I've needed to enable some more complicated sorting, which has lead me to a few new (to me, at least) discoveries.
I had to deal with a bug report in some Sitecore 6.6 / Advanced Database Crawler search code recently, relating to items with publishing restrictions not disappearing from search results until another publish occurred. It struck me that there's not much written about how publishing restrictions interact with search, so I figured I should take a bit of time to write down what I'd found while sorting the bug.
A while back I wrote up the faceted search example I'd presented at the London Sitecore User Group, and commented that ASP.Net WebForms wasn't really great technology for providing that sort of UI. I noted that it would work better if it could be implemented using Ajax-style UI.
Having finally had a chance to work out a basic pattern for building JSON web services using the sort of technology that's easily available in basic Sitecore 6.6 websites last week, I've now had a chance to get around to implementing a prototype of how the faceted search might be built with client-side processing.
Last week I spoke at the London Sitecore Technical User Group, and discussed my experiences working on a project that had to provide a Faceted Search UI in Sitecore 6.6. As part of my example, I talked about how you can build Facets using Lucene when you don't have access to the newer search APIs available in Sitecore 7.x, and about how you can make your search UI configurable by editors to improve their user experience. And I said I'd post my example code and explanation. So here goes:
Some time back I worked on a website which made extensive use of two bits of technology:
When the project was originally specified, these two things were thought of as individual aspects of the project and not much thought was put into the idea of bringing them together. But as the project progressed one of my colleagues realised that editors were basically being asked to enter the same data twice in some areas of the site. Once when they configured the metadata to drive the search facets, and once when they set up profile cards. We'd failed to spot the strong overlap between the data being entered in these two areas of the site.
As an experiment in "can it be done?" I tried to see if it was possible to index your DMS Profile Card data in Lucene, to allow it to be used as search facets. This never ended up in the actual project, but I thought it might be of interest in case anyone else finds themselves with a similar need.
