Jeremy Davis
Sitecore, C# and web development
Most of the time when you need to cache things in Sitecore, it's handled for you with the built in frameworks for data and UI layer caches. Usually your problems are solved by tuning the sizes of the caches and configuring the right caching settings on your UI components. But what happens when you've got bits of data which you want to cache that are neither components or items?
The other week I was commenting on shooting myself in the foot with the configuration of Coveo's UI for Sitecore. Another issue that came up during that bit of project work was that in their default state, the facet components didn't respond to data in the URL. Having done a bit of digging, however, one of my colleagues found an answer to this, which I figured I should write down in case anyone else is stuck on the same challenge...
There are lots of scenarios where sorting the results of Sitecore API or search queries is easy. But there's one scenario that I've come across a couple of times can be a bit trickier than the usual "sort by date" scenario.
Quick one this week. Mostly to try and save my own blushes, because the issue here was completely my fault. For the first time on a particular project I was trying to do some Coveo development work. I had created a page based on the default MVC templates they provide for search, but when I tried to add a Facet in Content Editor, I found myself staring at this:
No picker for the field to facet on – so no way to make the Facet component work...
Every so often, the move from WebForms style projects to MVC ones throws up a challenging question. An issue which I came across recently, is how do you cope with a situation where two independent components on a page need to exchange data? In WebForms projects there we could connect them together via the Layout's Code Behind, and in front-end situations JavaScript can do a similar job for us. But the situation requires back-end code and we're using MVC it's a bit more of a challenge...
I've had a Raspberry Pi sitting under my desk for some time now, but things keep getting in the way of me doing much with it. But in honour of the whole "March is for Makers" thing, I decided I needed to finally do something more than boot it up and let my son tinker with Scratch on it. I'd also acquired a "Sense Hat" add-on recently, and something about the matrix display on that made me think of animated graphs. Now that the Windows 10 IoT build is gaining features, I thought I'd try installing that and building something that would let me graph website activity – with a view to how it might get connected to Sitecore...
Sometimes you find yourself investigating errors which are made more difficult to solve by the sheer weight of hits for a term out on the internet. Top of my list of things that are a pain to Google, is any sort of Stack Overflow exception. You can guess why, right? 😉 Having gone throught that pain recently, here's some notes on an issue I helped my colleagues diagnose recently which fell straight into that trap...
Having spent a bit of time recently looking at some of the new stuff included in the tools and frameworks for ASP.Net Core 1.0 and Sitecore's Habitat solution, one of the things that caught my eye is the Gulp task runner. So after a few days of poking around, here's a basic introduction for anyone else considering it for their Sitecore work.
I suspect a fairly common scenario for Sitecore developers is launching a new site which replaces an existing one with a shiny new design and content structure. It's a fairly common requirement of these projects that whoever is in charge of SEO will want redirects in place from important old URLs on the site, to new ones. They ensure that users who have bookmarks to the old pages don't see 404s, and try to keep the search engine rankings which had been acquired by the old site.
Another common scenario these days is for new websites to serve all of their pages under HTTPS, rather than just the "sensitive" pages as we might have done in the past.
When you combine these two needs together, you can end up with more complicated redirection rules than you might have needed in the past. If you're planning to make use of the the Url Redirect module from the Sitecore Marketplace, my experiences doing this might be of help to you:
It's nearly Christmas, and before I head off for a bit of a holiday, here's a quick bug issue you might encounter. Despite the increasing power and sophistication of the search technologies in Sitecore, sometimes we still need to fall back to good old-fashioned Sitecore Query. A common reason for this is because the query you're writing depends on the structure of the data, not its content. Recently a colleague of mine pointed out some issues to me with the way some queries are resolved, which I thought might be of interest to others.
