Using Umbraco

When the decision was made to use Umbraco for new.shropshire.gov.uk it was at an interesting point in the lifecycle of the CMS. The current version at that time (and the one we had based our initial investigations on) was 4.7.1, but a newer, more refined version (Umbraco 5) was in beta, and would be released well within the timescales of our project.

Being the adventurous types (and the fact that the majority of us had just completed ASP.NET 4 and C# training making it an easier learning curve for us), we opted to develop the prototype site using Umbraco 5. The main draw of this version was the advantage of having a more refined behind-the-scenes architecture and a streamlined templating process (using ASP.NET MVC 3 and Razor), and meant that what we were learning & building now wouldn't have to be relearned & rebuilt a year or so down the road if we upgraded.

Unfortunately, opting for a new and untried system set us up with a few stumbling blocks...

As Umbraco 5 was still in beta, there was a distinct lack of information and official documentation available to us, although users of the Umbraco community website (our.umbraco.org) were ready and willing to assist with a number of questions and concerns we or others had raised.

Quite often, those questions and concerns were answered by members of the core team behind Umbraco - a reassuring sight that they were fully invested in the new version, listening to the people who would eventually be using it rather than hiding away and developing the system in isolation.

Admittedly, a large proportion of our own problems stemmed from our own inexperience with ASP.NET MVC 3, but, like others, we were also hamstrung by the lack of documentation on the revised functionality in Umbraco 5.  A number of learning resources were available for 4.7.x, but were not applicable to Umbraco 5, which, as a consequence meant that some of the features we were expecting to have out of the box were unavailable (being open source, some components of Umbraco were community-developed and, as of yet, those components had not been recreated for the new version).

Despite these issues, we did find the development side to be fairly quick, turning out new templates and document types pretty easily, and managing to find work-arounds where some of our desired functionality could not be built as we had originally intended. Being able to review the source code of the existing features of Umbraco was the biggest help in such situations.

Once the main development was either in hand or complete, our main concern was with the performance of the website, as some pages were taking anywhere between 3 seconds to 1 minute to load. Through trial & error, and monitoring the dedicated Umbraco 5 discussion forum on our.umbraco.org, it became apparent that the problem lay with the new architecture, and it wouldn't be a quick fix.

Over the weeks, the core Umbraco team developed patches and released version updates, and during that time the community came up with a number of additional tweaks and techniques to shave valuable seconds off the load time.

On the whole, the version updates showed marked improvement, and we ended up going live on a Release Candidate of Umbraco 5.1. The full version was made live shortly after, but after upgrading our site we found it brought with it another performance hit and were forced to roll back.

The feedback on the poor performance of Umbraco 5 was getting quite heated, although regular updates from the core Umbraco team (in particular Niels Hartvig - the founder of Umbraco) on the plan to resolve the problem have managed to turn the rants into constructive discussions.  My own tweets (from my own personal Twitter account) about our experiences with Umbraco 5 (good and bad) resulted in a response from the Twitter account of another member of the Umbraco team, Alex Norcliffe, who was interested in seeing our own setup to see why the upgrade turned out the way it did.

Sadly for us, the timescales mapped out for the next couple of updates for Umbraco 5 aren't in our favour, and our next service to be included on new.shropshire.gov.uk will have to be developed in Umbraco 4.7.2.

We haven't ruled out using Umbraco 5 again in the future, in fact the Umbraco team's willingness to engage with the community across a number of different channels goes a long way, in both terms of improving public perception of Umbraco 5 as a product, and towards speeding up the identification and resolution of the issues with this version. We may find that the next update resolves all the main bugbears we have, allowing us to continue using and developing Umbraco 5.

In short - we like Umbraco, and, even though it is currently hampered by a few issues, Umbraco 5 is shaping up to be a pretty good CMS.

UPDATE 13/06/2012 - The founder of Umbraco - Niels Hartvig - officially announced at their Codegarden event in Copenhagen that they are retiring v5, and will be concentrating on improving v4.  An official blog post detailing the reasons behind this decision can now be found on the Umbraco website.

While a shocking move in general, this decision is actually a wise one.

There comes a point in some projects when you realise the time and effort to fix problems with a new product will be far greater than admitting defeat and adapting something you already have or starting again from scratch. Earlier in this post I wrote about how we hit this same point when it came to developing for v5, and how we took the decision to revert to v4.7.2 to take advantage of the wealth of existing resources and faster performance.

At the time we figured this would be a temporary measure, but the decision today does mean that our focus (and that of the Umbraco team and Umbraco community as a whole) will now be entirely on v4.7.2 and beyond.

Yes, this does impact the image of Umbraco as a company, but by retiring v5 now they are making this a sharp shock to overcome rather than a slow lingering death by bad reputation, and the lessons learnt by us all can only make us better developers.