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

In the past I’ve often renamed the default <site/> 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 <site/> 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 <site/> from “website” to “web”.

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

Crashed Website

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” <site/>, 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.

Advertisements

3 thoughts on “Renaming the site called “website” is a bad move…

  1. I’ve never renamed the default website – I always add a new Site Definition in for what ever project I’m on. Even if its not multi-site. You never know what “hidden” goodies are awaiting the default stuff 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s