Working on Sitecore.Mvc

It’s been an interesting few weeks since I came back from vacation. Found myself transferred to the Sitecore.Mvc project, something that in the past would have been considered a bit of a poison chalice. Not this time around. As a project we started by asking and listening to what the Sitecore development community were calling out for. As far as I know this is a first for my organisation, the feedback though is where it matters.

Model View Controller

It’s no secret that Microsoft has re-invented itself around engaging with the community since Scott Guthrie and others started to lift the covers on internal development activities. Microsoft went further than most commercial organisations are able to go, it open sourced a great swathe of its intellectual property and even opened it up to public pull requests via GIT.

Advertisement

Dependency Injection with Sitecore

I frequently see Sitecore implementations that use no form of Dependency Injection (DI) or perhaps worse still lean on a Service Locator Pattern to build up component dependencies. When I tweeted about this situation some of the responses I got back really surprised me.

Wondering why more #sitecore web forms devs don’t use an IoC and employ DI. It’s 5 minutes work to get property injection going.

— @KevinObee .. October 26, 2013

I’m not sure whether there is a lack of awareness about DI around some areas of the Sitecore developer community or, as some of the responses to the tweet suggested, we have more than our fair share of Dark Matter Developers.

In this post I’ll try to give the briefest overview of what DI is, and show just how simple it is to implement in a Sitecore solution.

Glimpse for Sitecore

Welcome to a new era of server side diagnostics with Sitecore. In the past we had the following tools to help us identify performance issues with our Sitecore installations:

• Sitecore Log Analyzer (SCLA)
• ASP.NET Trace
• Sitecore Debugger
• Sitecore Admin pages
• Sitecore Rocks

These tools could be used in circumstances where it is not possible to attach a debugger or application profiler like the ANTS Performance Profiler to a running web application. No there it’s time to add a new tool to this list, that tool is Glimpse.

Fixing up Sitecore.Nuget connections

This post aims to document an issue and workaround for something that I spotted when working with Sitecore.NuGet to install Sitecore enabled NuGet packages.

For the uninitiated the following extract explains the idea behind these packages.

Sitecore.NuGet allows NuGet packages to be installed in a Sitecore solution, including Sitecore items.

A Sitecore NuGet package that contains items requires the Sitecore Rocks Hard Rock web service installed on server and that the Visual Project has been connected to the Sitecore installation.

The open source Sitecore.Mvc.Contrib project uses Sitecore.NuGet to package up and install Sitecore content items. In order for these packages to install the Visual Studio project has to be connected to a Sitecore site. In itself that is not a problem, simply right click on the project file in the Visual Studio Solution Explorer, select Sitecore -> Connect to Sitecore Explorer Connection… on the context dialog and connect to a Sitecore website. This will add a connection to the Sitecore Explorer as shown below.

After configuring the project you should be able to install a Sitecore.NuGet package like any other.

PM> install-package sitecore.mvc.contrib

The regular files within the package get installed as expected and then a nasty surprise pops into the package manager console output.

Successfully added 'Sitecore.Mvc.Contrib 1.0.1' to Website.
 install-items : A connection to "sc66contrib (sitecore\admin)" was not found.
 At C:\Websites\sc66contrib\packages\Sitecore.Mvc.Contrib.1.0.1\tools\install.ps1:19 char:3
 + install-items -toolspath $toolsPath -project $project -dte $dte;
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : NotSpecified: (:) [Install-Items], InvalidOperationException
 + FullyQualifiedErrorId : System.InvalidOperationException,Sitecore.NuGet.Installing.InstallItems

I’m obviously not alone in suffering from this issue:

@KevinObee @TheRocksGuy this. If you’re using local IIS sites in latest rocks it’s busted anyway.

— Kam (@kamsar) August 2, 2013

Using Cassette with Sitecore MVC

Cassette is a fantastic bundling and minification solution for those developing in ASP.NET. It automatically sorts, concatenates, minifies, caches and versions all your JavaScript, CoffeeScript, CSS, LESS, Sass and HTML templates. By doing this you end up with web pages that issue fewer HTTP requests and you reduce the size of each of those requests.

I recently ran into an unexpected issue when using Cassette with a Sitecore 6.6 MVC implementation that took long enough to get to the bottom of, that I thought it worth documenting. After installing the Cassette nuget package and make the few changes necessary to configure my stylesheet and script bundles I was very happy with the results. All of my local CSS and JavaScript files had been minified and combined and were now being pulled down from the server with just two HTTP requests. Job done and in no time at all, or so I thought.

Deep investigation (Photo credit: Stéfan)

All was fine until I fired up the Sitecore Page Editor to work on some of the site content. What greeted me after I logged in was quote literally an empty page. The Chrome Dev Tools confirmed that the page requested had indeed returned a zero byte response. I faired no better when I tried to preview the page in the Sitecore Content Editor, I just got the same story, an empty page. The odd thing was that when I hooked up the Visual Studio debugger I could see that all of my MVC layouts, controllers and renderings were executing just as I expected. When this sort of thing happens I usually fall back to chopping out anything that could be interfering with the response, in this case pipeline handlers and finally modules. Eventually the culprit revealed itself, the CassetteHttpModule was responsible for my empty responses.

Hiding XDT Transforms from Sitecore

Sitecore ships with a very useful web.config patching feature that allows everything within the element in the configuration file to be modified and extended. It is a best practice recommendation not to modify the web.config file directly but instead use customised configuration files located within the App_Config\Include folder to overlay the modifications that your solution requires.

Rather that regurgitate information on how to use the web.config patching mechanism I’ll suggest instead that you start with John West’s post All About web.config Include Files with the Sitecore ASP.NET CMS for a definitive way into this subject.

web.config transform files

Developers working with ASP.NET web applications outside of the Sitecore ecosystem are likely to be performing their web.config transformations using Microsoft’s XDT transform syntax. The popularity of the XDT engine is such that it has recently be issued as a NuGet package so that it can be shipped with third-party products. Whilst on the subject of XDT transforms it would be worth pointing out the Slow Cheetah Visual Studio extension for those new to the area. This package enables you to transform your web.config or any other XML file based on the build configuration and preview the outcome – simply invaluable.

MVC Areas in Sitecore

Areas have been a part of ASP.NET MVC since ASP.NET MVC 2 shipped in 2010. This walkthrough article from MSDN sums up why areas are useful in MVC web applications. A brief extract follows:

To accommodate large projects, ASP.NET MVC lets you partition Web applications into smaller units that are referred to as areas. Areas provide a way to separate a large MVC Web application into smaller functional groupings. An area is effectively an MVC structure inside an application. An application could contain several MVC structures (areas).

For example, a single large e-commerce application might be divided into areas that represent the storefront, product reviews, user account administration, and the purchasing system. Each area represents a separate function of the overall application.

The release of Sitecore 6.6 saw the introduction of support for MVC and the Razor view engine within the Sitecore CMS. It wasn’t long before a question popped up on stackoverflow asking how to wire up a Sitecore Controller Rendering to a controller located within a MVC Area.

Hopefully this article will provide some answers for those wanting to use MVC Areas with Sitecore and highlight a few of the subtleties that currently may not be so well documented.

Doing the Simplest Thing

Sitecore content tree indexed by Search Engines

Have you noticed that your Sitecore content tree may be indexed by search engines?

Try searching for “/sitecore/content/” in your favourite search engine. When I entered this into Bing the third link that I was shown was:

www.rfu.com

http://www.rfu.com/sitecore/content.aspx

Clicking on the link takes you to a Page Error message on the RFU site as there’s no layout associated with the content item. The url shown in the browser address bar is:

http://www.rfu.com/error?item=%2fsitecore%2fcontent&layout=%7b00000000-0000-0000-0000-000000000000%7d&device=Default

Presumably having content indexed by search engines under two separate url’s on a site isn’t going to be too good for your SEO rankings unless appropriate action is taken.

One way that I found of successfully dealing with this problem was to add the following to the sites robots.txt file:

User-agent: *
Disallow: /Sitecore/

Can anyone offer a good explanation of what is allowing the structure of the Sitecore CMS’s content tree to be indexed by the search engines?

HTTP 304 response handling in Sitecore MediaRequestHandler

Whilst testing a Sitecore 6.1 site due for release Firebug highlighted some unexpected behaviour from the Sitecore Media Request Handler which takes care of responding to requests for items held in the Sitecore Media Library. Media library items were being returned in full every time that they were requested, each returning a HTTP 200 response status code.

Further digging with Lutz Roeder’s excellent Reflector tool showed that the If-Modified-Since request header field was not being responded to correctly by the MediaRequestHandler. The If-Modified-Since request header is a HTTP-date value whose time component is in the format HH:MM:SS (i.e. no milliseconds). This header field value is used by the Modified method within the MediaRequestHandler to compare to the System.DateTime value that the media library item was last updated. As a System.DateTime value includes a milliseconds component the equality check fails for the majority of media library requests and as a result the item is downloaded to the browser in full.

Sitecore have confirmed that this is a known issue and something that will be fixed in a forthcoming release. In the meantime it’s not difficult to patch in a modified HTTP handler to respond to media library requests and implement HTTP 304 response handling appropriately. Alex de Groot has a good article on his blog that explains how Sitecore interacts with HTTP handlers for media handling.