Inheriting website attributes and trimming your Sitecore configuration

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.

Everyone will be familiar with the following snippet from the vanilla Sitecore configuration:

<site name="website" virtualFolder="/" physicalFolder="/"
      rootPath="/sitecore/content" startItem="/home"
      database="web" domain="extranet" allowDebug="true"
      cacheHtml="true" htmlCacheSize="50MB"
      registryCacheSize="0" viewStateCacheSize="0"
      xslCacheSize="25MB" filteredItemsCacheSize="10MB"
      enablePreview="true" enableWebEdit="true"
      enableDebugger="true" disableClientData="false" />

A lot of people implementing Sitecore will change the root path, some cache sizes and probably never touch that section of the configuration again.  Others having to support multi-site solutions will probably copy that line for as many sites as they need in their solution and change the root path and host name.  Fortunately there’s a much better option: inherits.  Its purpose is pretty self-explanatory: if website B inherits from website A, then B will inherit all the attributes from A unless B provides its own value.  This means that your configuration for a second site becomes something like this (assuming you’re using an include file [you are, right?]):

<site name="other-website" inherits="website"
      rootPath="..." hostName="..."
      patch:before="*[@name='website']" />

Aside from being much shorter, it also allows changes to propagate more easily (e.g. disabling debugging, beefing up HTML cache sizes).  One nice thing is that you can insert the new site before or after the other site, so you can still put your catch-all site last.

Of course, if you have several hundred sites, then even this fancy shortened version is going to end up being an unmaintainable mess – if you ever reach that point, then I’d strongly suggest investigating a custom site configuration provider.  They’re a little easier in Sitecore 8, as you can have multiple providers active at any one time, while in older versions you had to do everything yourself (including surfacing all those sites which exist for system purposes).  That will pretty much eliminate all the major site configuration, and it also has the benefit of (depending how you implement it of course) not requiring a configuration change whenever a new site goes out.