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
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
<initialize> and registering your routes in
You can now take your own area registration out. Or can you? Here’s how Sitecore changed the
protected virtual void RegisterRoutes(RouteCollection routes, PipelineArgs args)
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
<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.
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:
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
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.