Jeremy Davis
Sitecore, C# and web development
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 struck me the other day, that I've now been a full-time remote worker for more than ten years. As the technology for working away from company offices slowly gets better, I'd like to hope this approach to work was getting more common. After all, it has the potential to save companies money and it has the potential to give you back a couple of hours of your day that you don't need to spend commuting.
So just in case anyone else is thinking about trying working this way, I thought I'd have a go at setting out some of the challenges I've had to address over the last decade.
A while back I blogged about some of the issues of having Windows 10 computers using Windows Server Essentials as their backup target. Recently I installed the first major update for Windows 10, and this caused me more issues, which I figured I should document.
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.
After last week's work on installing the Coveo search service, this week we'll move on to how that script can be extended to install the Coveo REST API and the Coveo for Sitecore package.
Getting back to the the issue of installing things for a Sitecore development environment, this week I'm going to start tackling how you can add "Coveo for Sitecore" to a machine. While Coveo have provided some documentation on how this can be achieved, (for CES and REST APIs) they make they point that they don't offer support for this approach to installation. So this may not be right for everyone. But in case it's of use to you, here's the first part of my attempt at the automation:
Having been working on more automation with PowerShell DSC in the last week, I hit upon an interesting issue. For many operations, it doesn't really matter what user your script is executing as. Most local operations that only affect the current machine just work. However, every so often you come across an operation that you need to perform as a specific user. So how can you impersonate a different user for parts of your scripts?
In the past I've often renamed the default site entry from "website" to something more meaningful when creating the configuration for a project. If your instance of Sitecore is serving multiple websites, then it seems logical to me to name your site entries so they make sense against the purposes of these websites. However it seems that in the current version of Sitecore 8.0 this is a bad idea...
