Sitecore Skills

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.

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.