Tips For Umbraco Developers

I've been working with Umbraco for a while now, and I've done a fair bit of work that's involved creating some quite complex extensions for the Umbraco back office, from DataTypes, through to whole new sections.

I've learnt a lot as I've gone along, and thought I'd share some of the tips for writing extensions for Umbraco! Hopefully some of these will help others avoid some of the mistakes I've made, or save them hours of research.

1. Don't Customize the Core Unless You Have To

Only modify the core if you absolutely have to. Early on I extended Umbraco by modifying the core code itself rather than using the event models etc. This was great, until I had to perform an upgrade. At which point I had to re-apply my updates to the new source, rebuild and re-test. Ouch.

Using the event models and the API, you can code extensions that are easy to re-use and that should carry on working, even after an Umbraco upgrade!

2. When Coding Datatypes, Don't Rely on the HttpContext

DataTypes can be called by events that don't have an HttpContext, like the timed publisher. In these cases they'll throw a null reference error, as the HttpContext is not available. Use non context versions of functions wherever possible!

3. When Coding Publish Event Handlers, Don't Rely on the HttpContext

Publish events can occur outside of the HttpContext. If your publish event handler relies on the HttpContext, it will fail when you try and use the timed publish feature of Umbraco. The biggest culprit I've seen for this is using HttpContext.Current.Server.MapPath, which will be null when called through the timed publisher.

You can map the path using HostingEnvironment.MapPath instead. For other code that relies on HttpContext, put in null checks and default values in case there is no HttpContext, and your handlers should work on normal and timed publish!

4. When Creating New CMS Pages, Inherit From UmbracoEnsuredPage

If you're creating new pages for the back office, you want to make sure that those pages are only visisble to users who have logged in through the CMS. The easiest way to do this, is to make sure that your pages inherit from umbraco.BasePages.UmbracoEnsuredPage instead of the usual System.Web.UI.Page.

This will make your page unavailable to non-logged in users, and will also enable you to hook into your page using the Umbraco event model!

5. Don't Be Afraid To Grub Through Code

One of the biggest ways I learnt was to grub through other people's code. Want to make CMS pages that look like the Umbraco ones, but not sure how to do it? Easy, grabthe source from codeplex and have a look at how it's done! Want to know how your favourite uComponents DataType works? Go look at the source and find out. The more you look, the more you'll learn about how the core works, and the ways that you can interact with it.

Hopefully (time permitting) I'm going to start a series of step by step tutorials on how to do some common stuff with the Umbraco Event models and API, concentrating particularly on the back office! Some of the things I'm hoping to cover are creating back office pages, using Umbraco UI elements, working with DataTypes, and using the event model to interact with the back office!