Sitecore Skills

Yesterday I spent way too long trying to solve a problem with Sitecore Content Search.  It was a simple enough query, but strangely it worked in some cases but not others.

Recently I've been experimenting with the way Sitecore detects what sites are included in an instance. When Sitecore starts up, by default  it looks in the “Sites” node of the web.config and builds up a list of in-memory Site objects which are kept for the lifetime of the application. I was intrigued to see that, like many Sitecore subsystems, a provider approach is used. This means we’re able to replace the default behaviour with one of  our own.

As the dust settles on the 2014 Sitecore Symposiums in Las Vegas and Barcelona, there's lots to look forward to in forthcoming Sitecore releases. I made copious notes while attending the Barcelona conference, but to quote Michael Seifert's keynote, "experience is a lasting memory".  So rather than reeling off a summary of every single session I attended, in this post I'll reflect on my lasting impression of what's around the corner.

Recently, while poking around the Sitecore.Kernel assembly I came across a feature which allows you to inherit the properties assigned to one site into another. It's seemed like this might be useful for multi-site Sitecore implementations, but I hadn't heard of it before.

This post introduces a thesaurus module for the Sitecore rich text editor. I started this some time ago using Sheer UI, but never got around to finishing it. I've taken the opportunity to update it now as a way of getting to grips with Sitecore SPEAK development.

Last week I set up my first proper Visual Studio solution for Sitecore 7.2 a nd Sitecore MVC.  I thought I'd share a couple of problems that I encountered and I how I overcame them.

Most customers that I work with consider the provision of standardised lowercase URL's to be a basic requirement for their site. In this post, I discuss some issues that Sitecore developers face in trying to meet that requirement. I also provide some simple code snippets that you might find helpful.

As you probably know, Sitecore content editors are evil geniuses. They masquerade as reasonable, hard working professionals, but don't be fooled. The spend their days hatching diabolical schemes to uncover any remaining weaknesses in the platform, ready to gleefully spring them on you last thing on a Friday. In the last year alone I've had the following phone conversation more times than I care to remember:

Sitecore engagement plans contain an action for sending an email. In the action's settings there's an option to send the email to the "Current Visitors Email Address", but unfortunately this has a bug.

Sitecore users and developers occasionally ask how to find out when an item was most recently published or when it was first published. Unfortunately, the answer isn't as simple as you might assume.

Here's a quick one to correct an omission from my previous post where I detailed 3 rule conditions that respond to the presence of a cookie. On reflection I realised I should have included a corresponding action class. So here it is. As before, I haven't spent much time considering the practical applications. I'll leave that part up to you.

I recently encountered a situation where I felt it would be beneficial to use cookie values to influence conditional rendering in Sitecore. I assumed there must already be some code for this on the web. But after a Googling a few different keyword combinations I couldn't find anything, and by my reckoning that absence makes it suitable blog material.

Image by  by  Diorama Sky This post demonstrates a way of allowing Sitecore to dynamically select a link provider depending on the current context. It's partly inspired by  an article written by Craig Taylor  about developing multi-site Sitecore instances, with different teams (potentially different companies) working on each site. In situations such as that, I simply don't think it's possible to proceed unless you adopt strategies like the one I outline here.

When Sitecore receives a media request it goes through a few key steps to convert the URL in to a form it can use: Sitecore identifies that the request is for a media item because the path begins with a media prefix defined in the web.config. www.website.com /~/media /Images/kitten.jpg  The prefix is removed and replaced with the root of the media library. /media library / Images/kitten.jpg The file extension is removed. /media library/Images/kitten