This isn't good.

This isn’t good.

There I was, minding my own business when I was greeted by this lovely YSOD.  I was creating a new site within my custom SiteProvider for a client and when I loaded up Sitecore, everything was down.  From the stack trace, it was clear that it was cache related.  Some query to the cache configuration was breaking everything.  To test this, I created a XML-based site configuration:

Everything was fine.  A big more digging had me remove the cache sizes in the site definition.

Boom. The error is back.  It appears that when it tries to default a cache size, it explodes.  I renamed “12-monkeys” to “twelve-monkeys” and the error went away.  Interesting.

Time to open up dotPeek.  Down inside Sitecore.Web.SiteInfo, there’s a method to create all the caches which is called as part of the constructor.  When this is called, there’s a method invoked that will get the cache size from the site.

Noting line 11, you can see it tries to build an XPath to the cacheSizes node:

Creating a website in here with a name that starts with a number is against the W3 standards for XML and would break the whole entire world.

I’ll be submitting this as a bug to the Sitecore Support Portal, but in the interim, I suggest you always specific your cache sizes if you’re going to have the possibility of a site name that starts with a number.

Update 5.16:  Sitecore’s official response was to always include the cache settings on the site definition node.  That’s about right, I guess.