This wasn’t supposed to be a blog post series, and my original reason for this code was to just offload the hosting of large files. But whilst writing the first draft of the blog post I started to investigate various areas since the potential for this module became greater. It was supposed to stop at part two, but I supposed I suffer from the same thing as most of you: programmers OCD. And so a series is born and expect another post or two to follow until a final solution is attained.
In my previous code I noted that the code did not work with the attach/detach handlers in the Media Library:
This is a continuation of my previous blog post in which we uploaded files into Azure Blob Storage through the Sitecore Media Library. If you haven’t read it yet then first go and do that since this may not make much sense otherwise…
The previous post showed how to upload media files into Azure Blob Storage using a custom pipeline. I started off the post by stating that the requirement was to only store large files in Azure and that was primarily the focus of what we needed to achieve but some small tweaks meant it was possible to store all media in Cloud storage.
We still need to make some small updates to code to allow us to actually correctly link to the media in Azure though, so I’ll present a couple of options we have to do that.
On a recent project we had the requirement to be able to link to large files which the user would be able to download, file sizes could be up to 2GB in size. Far too large to store in Sitecore Media Library, at least in database storage. We had previously used Blob storage in Azure with great success for another (non-Sitecore) site so decided to utilise this again but wanted a seamless, single interface for the user to work with, i.e. everything through Sitecore.
Knowing that Azure has a rich API set and pretty much everything in Sitecore can be hacked into via the pipelines we set on our merry journey.
The following requirements were set in order to help set the boundaries:
- any file uploaded to certain folders would be uploaded to Azure
- any file uploaded and the “Upload as Files” option checked would be uploaded to Azure Blob Storage
There was also an additional requirement to automatically calculate the MD5 of each file which was uploaded. This ties in follows on nicely from my previous post about extending Media Item templates using Glass Mapper. Hopefully the specifics of that post will make more sense after this as well 🙂
I’ve seen a fair number of posts already on SEO Friendly URLs, search engines love them apparently and as humans we love them too – although it could be argued that it is mainly for vanity reasons (go check out the product URLs on Amazon quickly…)
Whatever the argument, we agree that Semantic URLs are a good thing for us mere mortals and the vast majority of sites.
The simplest way of achieving friendly URLs is by using a combination of settings. Firstly set the
LinkManager (from Sitecore 6.6 onwards) to use lowercase urls and remove the aspx extension:
<linkManager defaultProvider="sitecore"> <providers> <add name="sitecore" addAspxExtension="false" encodeNames="true" lowercaseUrls="true" ... /> </providers> </linkManager>
And then set
encodeNameReplacements to replace spaces with dashes:
<encodeNameReplacements> ... <replace mode="on" find=" " replaceWith="-" /> </encodeNameReplacements>
About a year or so ago I was working on a project which involved an upgrade from Sitecore 6.4 to 7.0 (the latest version at the time). The upgrade was fairly incidental, the site was (kind of) “working fine” in production. The main reason for touching the codebase was to fix issues due to a poor implementation that was carried out initially, namely:
- Lack of Page Editor support
- Poor coding not following Sitecore Best Practices
- Sitecore section in Web.config modified directly (which made upgrading more difficult)
- Poorly structured Content Tree
- Difficulty applying a good security model for multi-site, multi-editor environment
…amongst others. It wasn’t all bad, just some common mistakes made by developers struggling with Sitecore during a first implementation.
One issue was the poorly structured content tree. It seems there was struggle with getting a handle on how to structure content whilst trying to use that same structure to create the navigation menu on the site. They had the usual “Include In Navigation Menu” checkboxes but the navigation structure did not actually completely match the content structure.