Sitecore 8.1. Developer's Notes

I took a two months long hiatus from writing to transition into my new role at work. It’s all good now and I am back with an overdue post about Sitecore 8.1

Routes and the MVC Areas

Sitecore 8.1 has finally added native support for MVC areas. If you’ve used areas before (using this option, for example) you probably were calling AreaRegistration.RegisterAllAreas() during <initialize> and registering your routes in RegisterArea():

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using System.Web.Mvc;

namespace Solution.Web.Areas.Site
{
public class SiteAreaRegistration : AreaRegistration
{
public override string AreaName
{
get
{
return "Site";
}
}

public override void RegisterArea(AreaRegistrationContext context)
{
// Register your MVC routes here
}
}
}

You can now take your own area registration out. Or can you? Here’s how Sitecore changed the InitializeRoutes:

1
2
3
4
5
6
7
8
9
10
11
12
13
protected virtual void RegisterRoutes(RouteCollection routes, PipelineArgs args)
{
RouteCollectionExtensions.MapRoute(routes, MvcSettings.SitecoreRouteName ... );
this.SetDefaultValues(routes, args);

// <-- Pay attention to the order
this.SetRouteHandlers(routes, args);

// <-- This is new in 8.1
this.RegisterAreas();

InitializeRoutes.AddRenderersViewFolderToRazorViewEngine();
}

The problem is - area registration is called after route handlers have been set. I briefly mentioned the custom route handlers in my older blog post about Sitecore MVC routing mechanisms. This is what makes otherwise regular MVC routes Sitecore aware. No custom handlers on your routes means no mvc.* pipelines, no PageContext, no analytics.

All the routes that you were registering in RegisterArea() are now not part of the Sitecore MVC ceremonies. They are late to the party.

I brought it up on the Sitecore MVC Experts Panel. I can’t tell you if the order of commands will change in the next version or next update - ask @herskinduk - but I can tell you what you can do about it.

My approach is to keep calling AreaRegistration.RegisterAllAreas() during <initialize> before Sitecore’s InitializeRoutes. There’s really no harm in running area registration twice unless you do something not idempotent in the RegisterArea(). MVC will issue a warning in the logs about not being able to register a route with the same name twice and that’s about it. The benefits of having Sitecore pipelines on your routes outweighs the small noise in the logs during initialization.

Preview.ResolveSite

The new Preview.ResolveSite setting has been blogged about and tweeted about already. I want to add something else that I observed while working with 8.1.

Those of you who followed my blogging last year know that I spent some time dissecting versioned layouts (here and here) and then wrapping my head around how to properly work with them (here). The result of those explorations is a strong desire to build presentation details on shared layout unless it’s an as-designed variation for a specific language or a version of the page.

Sitecore 8.1 has a built-in toggle between Shared and Final layouts in Experience Editor but it’s disabled for my newly scaffolded site:

(/images/8-1-ee-sharedfinal-disabled.png)

If you take a closer look at the URL string you will see that the sc_site is set to website. My site is playground (I just duplicated the Home item and added a site definition that points at the copy) so clearly site context wasn’t resolved correctly. This is easy to fix by setting Preview.ResolveSite to true:

(/images/8-1-ee-sharedfinal-enabled.png)

I would argue that true should be the default for Preview.ResolveSite but I am not sure why the toggle would be disabled without it. It’s enabled for the vanilla Home item in a clean install. I could probably debug into it but since all the sites we create now have Preview.ResolveSite set to true I will spend my troubleshooting energy elsewhere.

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×