This post follows on from my introductory post about Sitecore configuration, where I talked about using settings and retrieving XML fragments. In this post I talk about how you can use Sitecore configuration to instantiate and populate objects of your choosing. This is useful for cutting down on the amount of mapping code you have to write, without needing to put attributes all over the place.
I’ve spent quite a bit of time looking into the way that Sitecore configuration can be used. It has some fairly novel features in it, and while it’s becoming less relevant as support for dependency injection in Sitecore matures, I don’t think it’s going anywhere. All the same, it’s quite useful for adding flexibility to your Sitecore customisations, or for piggybacking on to provide custom configuration for your own modules and sites. Continue reading
I did a bit of playing around recently with Sitecore’s
SiteProvider infrastructure. Our client wanted to be able to create new websites without needing a developer to set it up for them. The nuts and bolts of sharing templates and renderings is already well documented, so I’m not going to go into that. I am going to write a bit about how a custom
SiteProvider can be created to avoid the need for developers to add a new
<site> entry in the configuration. Continue reading
The HTML cache clearer does exactly what its name implies: it clears the Sitecore HTML caches. More specifically, it clears Sitecore’s HTML caches upon observing a publish end event. More specifically still, it clears the HTML cache of all websites that are registered with the HTML cache clearer upon observing a publish end event. There are quite a few posts around about how performance of the HTML cache can be improved (*cough* John West *cough*), but one thing that people don’t seem to mention often is how annoying it is to maintain the configuration correctly. This post outlines the method that I prefer to use, and it works pretty well for me so hopefully someone else will find it useful too. Continue reading
Today I had the dubious pleasure of seeing a Sitecore solution containing several hundred microsites. I spent a little while silently fuming at the developers for not using the inherits attribute, until it occurred to me that this attribute isn’t really documented anywhere. I’m not going to attempt to do so fully; I’ll leave that job (along with the many other undocumented attributes) to the Sitecore documentation team. I will provide a bit of detail on it, though, along with another option that would be a good alternative to the mass of duplicated configuration that I saw. Continue reading
I’ve always considered the rules engine to be a pretty cool part of Sitecore. In this post, I’ll talk about using the Sitecore rules engine in order to affect Sitecore placeholder settings in the page editor (or experience editor as it’s soon to be called). I’ve also put the code for this module (for want of a better word) as it stands in a GitHub repository.
A lot of people are familiar with the rules engine in the context of the personalisation functionality but don’t realise that, out of the box, it can be used for other things too. A few of the most useful (in my opinion) examples are: insert options, search index boosting, and tacking things on to various item events. I’m not going to spend too much time on the basics of the rules engine, for that John West has a good list of posts, instead I’m just going to write a bit about how I went about writing the module. Continue reading
Edit frames are a well-known part of the Sitecore page editor: they allow developers to show buttons around arbitrary parts of the page. Edit frames will take a single button root and then display all the buttons in that folder on a toolbar. From someone who uses edit frames quite a bit, I always used to find it quite annoying that I would have to duplicate buttons if I wanted to have the same button on different edit frame toolbars. After a bit of digging, I found a way to extend edit frames that would allow me to specify multiple button roots on each toolbar, allowing me to reuse groups of buttons. Continue reading
I spoke to a fellow MVP recently, Kern Herskind Nightingale and the topic of my blog came up, along with the fact that I hadn’t (at the time) updated for a while. The reason was my previous post about overriding rendering types. Originally, I had intended to use an example that would allow developers to add an interface to their sublayout classes and specify custom logic around building their cache keys. Continue reading
The topic of rendering types came up at the office the other day, and I wanted to write a quick post about them. Rendering types are a group of classes that Sitecore uses to build up the controls on its pages using the presentation settings. They handle the creation of the actual controls that Sitecore will use for rendering and allow for the Sitecore rendering engine to be extended. You can use this mechanism to extend Sitecore by modifying how existing types of rendering work, or by adding your own custom rendering types. This extension point can be useful for the times where you want to introduce functionality to Sitecore at a solution level; however I would typically recommend that you keep this to low-level functionality rather than high-level functionality, as your logic will be applied to every single rendering of your type in the solution, across all the websites. Continue reading
Pipelines are a very useful feature in Sitecore, one that I make use of a great deal. I see a great many Sitecore website solutions that create their own processors to add to the existing pipelines (or which override existing pipeline processors), but I very rarely see solutions that have created their own pipelines. Usually I only see it in modules. I think that developers might be missing a trick, as there are a great many things that you can do with a simple pipeline and it provides easy extensibility throughout the project lifetime.
Pipelines, to my mind, should be used to solve a problem where you have (or will have) discrete pieces of logic that may be added to at any time. Often but not always, these operations occur in a particular order. There will usually also be one or more results of the pipeline that all of the operations will contribute toward in some way. Continue reading
There have been quite a few posts on the topic of ‘Dynamic Placeholders’ (among the most useful of which are those of John Newcombe, Nick Wesselman and Dave Leigh). If you haven’t come across this topic, then I’d suggest checking out Nick Wesselman’s blog post for a pretty succinct explanation of it. It boils down to the limitation that you cannot place multiple sublayouts containing a placeholder onto a page in such a way that the placeholders resolve to having the same fully qualified placeholder keys. I really like John Newcombe’s approach, which is based on Nick Wesselman’s; and having spent quite a bit of time playing with it, I’d certainly suggest that anyone needing to solve this problem takes a look themselves.
I plan to tackle a slightly different problem in this post: that of dynamically creating a number of placeholders within a single sublayout (so dynamic placeholders instead of dynamic placeholder keys, although as we’ll see later, the two problems can be solved in a very similar manner). Continue reading
I sometimes wonder how many people look at the various dependencies that come with Sitecore. One has to be slightly careful around how these are licensed, especially with Telerik, but I think that there’s one which deserves a mention: NVelocity. NVelocity was originally a .Net port of the Java-based Velocity templating engine. Sadly the project itself is more-or-less dead as far as I can tell; having been overtaken by more modern engines like Razor, but I still use it now and then. I thought that I’d explain the basics for people who hadn’t heard of it until now. Continue reading
A couple of years ago, I wrote a post on how to assign a Sitecore image media item to an image field using the Sitecore 5.3 API. As it stands, I haven’t really had need to do this since, but I got asked about it the other day by someone at the office. So, I thought I’d post a little update to the original article. Continue reading
Unit testing is a very popular topic, and is a very good practice to adopt. Unfortunately, as anyone who has worked with it will know, some common Sitecore classes (Sitecore.Data.Items.Item to name one) can’t be mocked with some popular mocking frameworks, and can’t be directly instantiated. So, the logical solution (to me) is to let your unit tests access the Sitecore API and databases (some others abstract the detail away, but as the saying goes: “Who guards the guards?”). There have been quite a few different blog articles written about this topic, and people have approached the problem differently. So I thought that I’d share my approach to writing unit tests for Sitecore solutions. Continue reading
As anyone familiar with Sitecore’s guide of recommended practices, changing the <sitecore> section of the Web.config file directly is frowned upon. Rather, developers should use things called Sitecore configuration include files, or patch files. By default, these are stored in the /App_Config/Includes folder of the website.
There are plenty of blog articles about them on the internet, however there was one specific feature that seems to be relatively unknown: the set namespace. Continue reading