If you hadn’t noticed, SDL Web released a new product recently: Contextual Image Delivery, which in short enables you to resize, crop, trim and convert formats for images. I thought I would see how easy it was to set up in an ASP.NET MVC environment, and it went pretty well, but there are a few subtleties

I was running an SDL Tridion 2013 SP1 ASP.NET MVC4 DD4T Web App, and while I know that DD4T contains some image resizing options I wanted to try the SDL version and see how it compares.

I already had my web app set up including the ADF and Context Engine (you are going to want to use this do the ‘contextual’ bit of image resizing), so my first step was to install hotfix 87801. Next I followed the ASP.NET installation intstructions which are pretty simple, especially when installing into your existing web app, and used /cid as my CUSTOM/PATH – the base URL for which altered images will be served from.

So far, so good – I was only a few minutes in to set up and it appeared that I was done. I hit a test url: http://mysite/cid/fit/200/source/site/media/curry_tcm4-124.jpg – which basically is instructing CID to fit the image to a width of 200 pixels.

Unfortunately I got a 404.

There was nothing logged in the CID logs, but then I noticed that the request was being processed by the DD4T Binary Distribution Module, so I did a couple of changes in web.config:

• In system.webServer/modules removed the runAllManagedModulesForAllRequests=”true” attribute – this was forcing the Binary Distribution Module to execute for each request – CID works with a Handler, which executes after the module, so would never be reached (as the DD4T module will throw the 404 exception)
• In appSettings updated the DD4T.BinaryUrlPattern from ^.*\.(jpg|JPG|gif|GIF|png|PNG)$ to ^/media/.* – even though I now do not have the DD4T module executing for every request, the cid requests were matching the DD4T pattern, restricting it to /media (my images root) should solve this.

Unfortunately, I still got a 404, and the strange thing was that the CID handler never seemed to be activated (no logging appeared). After some head scratching and googling (this Scott Hanselman article is essential reading) , I discovered that if you have a resource (like an image) which would normally be handled by the StaticFileHandler, but that resource does not exist on disk, MVC routing kicks in. In DD4T you typically have a greedy route:

routes.MapRoute("TridionPage","{*PageId}",new { controller = "Page", action = "Page" }, new { pageId = @"^(.*)?$" });.

Which means that my requests to /cid were actually now going into the DD4T Page controller, which quite correctly throwing a 404. When I understood this, the fix was easy. Add an ignore route in Global.asax before the greedy DD4T route:

routes.IgnoreRoute("cid/{*pathInfo}");

And voilá – it worked! You can see my first resized image at the top of this post. Setting up Contextual Image Delivery took less than half an hour, but figuring out the configuration and routing issues took at least 2 hours – hopefully I have spared you that pain.

So how does CID compare with DD4T image resizing? I will leave that to the next post…