Renaming the site called “website” is a bad move...

In the past I've often renamed the default entry from "website" to something more meaningful when creating the configuration for a project. If your instance of Sitecore is serving multiple websites, then it seems logical to me to name your entries so they make sense against the purposes of these websites. However it seems that in the current version of Sitecore 8.0 this is a bad idea...

To see what I mean, try taking a vanilla install of Sitecore 8 and adding a configuration patch containing:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <sites>
      <site name="website">
        <patch:attribute name="name">web</patch:attribute>
      </site>
    </sites>
  </sitecore>
</configuration>

					

(it needs to be the last patch that is run – so name the file "z.config" or something similar to ensure it's at the end of the list for processing)

All this does is rename the default from "website" to "web".

Now when you try to request any Sitecore page you will get:

Frustrating, huh?

Based on that stack trace, if you dig into the Process() method of the EnableExperienceModePipeline that the stack trace mentions, you will find this:

public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
{
    Sitecore.Web.WebUtil.SetCookieValue(SettingsHelper.AddOnQueryStringKey, "0");
    Sitecore.Diagnostics.Assert.ArgumentNotNull(args, "args");
    if (!SettingsHelper.ExperienceModePipelineEnabled)
    {
        return;
    }
    if (!SettingsHelper.IsEnabledForCurrentSite)
    {
        if (Context.Site.DisplayMode == Sitecore.Sites.DisplayMode.Normal)
        {
            Context.Site.SetDisplayMode(Sitecore.Sites.DisplayMode.Edit, Sitecore.Sites.DisplayModeDuration.Remember);
        }
        return;
    }
    bool flag = PageModeHelper.IsExperienceMode || (PageModeHelper.HasPermission && (args.LocalPath == Paths.Local.Controls.Editor.AbsolutePath || args.LocalPath == Paths.Local.Controls.Viewer.AbsolutePath || args.LocalPath.StartsWith(Paths.Local.Services.AbsolutePath)));
    string database = Sitecore.Sites.SiteContext.GetSite("website").SiteInfo.Database;
    if (string.IsNullOrEmpty(database))
    {
        return;
    }
    bool flag2 = ModuleManager.IsExpButtonClicked && string.Compare(Context.Database.Name, database, StringComparison.InvariantCultureIgnoreCase) == 0;
    if (flag || flag2)
    {
        Sitecore.Data.Database database2 = ExperienceExplorerUtil.ResolveContextDatabase();
        Context.Site.Database = database2;
        Context.Database = database2;
        Sitecore.Web.WebUtil.SetCookieValue(SettingsHelper.AddOnQueryStringKey, "1");
    }
}

					

The cause of the problem is highlighted here. The code is finding a database by looking at the configuration for the "website" , but it doesn't make a test to check it exists before it tries to access properties – hence the crash if this isn't present.

So, don't get rid of the default site if you're running Sitecore 8.0...

Having reported this to Sitecore Support they confirm this is a bug, and that it has been fixed in 8.1 release. That version determines which site's database to use via the DefaultSite config setting.