I’m not a Umbraco expert, actually I never did a real website in Umbraco till now. So being a developer that tries to adopt agile methodologies and tries to remove as much “friction” as possible I was a bit disappointed by the development and deployment experience in Umbraco. But the great community compensate pretty well the missing features (at least missing for my scenario) of Umbraco, and at the end my site came out fine, and thanks to their suggestion I’m now a much better “umbraco developer”.

I want to share with you some of the suggestion I received on twitter.

One site per instance vs many sites per instance

For “historical” I had to develop the site inside an instance together with other sites. Well… never do that, unless you develop, deploy, maintain the sites in the instance all together. Also, don’t do that if the sites don’t share the same media contents and the same templates. Unlike Orchard and DNN where “tenants” are completely separated and multi-tenancy is just a way to increase site density, in Umbraco all media, styles, scripts, templates, macros are shared between all the sites.

So, it’s ok if you want to have a multilingual web site (it.example.com, be-fr.example.com and be-nl.example.com), or if you want to do a site for each event of a series (like the triathlon world championship series which has london.triathlon.org, lausanne.triathlon.org and so on). But not if you want to have Company1.com and Company2.com.

Document Types

For people not initiated to umbraco, a Document Type is something like the “model” of the page. They have fields, and they are hierarchical, just like normal POCO classes. But unfortunately they are not as “agile” as normal classes.

I started creating all my nodes in a list with the same DocType, with the basic fields. But then I realized that for some pages I needed more fields. So I thought: “I just create a new DocType that inherits from the base DocType, I add the 2-3 fields I need, and I change the type of the node”. That’s also I do when I write normal applications. It was great until I tried to change the type of the node: that is not possible. So at this point I had two options which I didn’t like:

• Create a new node with the new type, and copy all the contents
• Manually change the type of the node in the database

I understand why changing DocType of a published node can be a bad idea (data loss), but in some situation (when changing to a child type) this operation is safe. Also, the child type is not automatically allowed where the parent node is: remember to add it to the allowed nodes or you won’t be able to add nodes of the child doc type.

Here the community came to the rescue and suggested me this awesome extension, called “Doc Type Extensions” that allows extracting a base type from a DocType.

In some other cases inheritance might not make sense, for example when each page have a title, a description and tags. If you adopt inheritance to solve that situation, you will have all your DocTypes inheriting from a base doctype. What about composition over inheritance? Another extension suggested to me via twitter introduces “mixins” to DocTypes creation: DocTypeMixins. With this you can reuse the same group of fields in different document types.

Additional data types

Data Types are the type of each field in a Document Type. They both define the real type of the field (integer, string, boolean, etc), but also, and most importantly, the control that will be shown to the user to edit its value.

Umbraco has a lot of them already, but if you want more, go and download the uComponents library.

Deployment

This is another super weak point of Umbraco, and despite all the time spent discussing this on twitter this morning, I think a lot can be done to improve the deployment experience.

Let me explain where the problem lies:

• everything (both development artifacts and contents) in Umbraco has a id (well, obviously you might say), but this id is not a GUID, but it’s a numeric id.
• everything is referenced with everything via these ids.

You probably might already see where this is heading: if you copy the content to a new server, ids will change, so references will break. Not a problem for development artifact as they are usually referenced via their alias. Same happens when you have links: they are done via the friendly url which doesn't change with the id. Problems are when you reference images or other nodes via their id: you'll end up with tons of broken images and links.

Unfortunately there is no easy solution for this without the help of external components. One solution might be the backup and restore of the DB, but that will work only if deploying to an empty instance, and will not work if upgrading an existing site, or if you have more than one site per instance.

The umbraco HQ released, at the beginning of this summer, Courier 2, an evolution of the old syncronization tool for umbraco: it automatically takes care of the changing ids, fixes the references and is also supposed to fix hard-coded links and references in templates and CSS. Looks good. Too bad I find it out only when I had already manually copied and fixed all my content.

Browser based development

Another thing I don’t like is the fact that Umbraco needs you to work inside the browser: datatypes, document types, macro have to be developed from within the web application. In theory you could also write templates and scripting files in the web browser, but unless you have to apply a quick (and dirty) change to fix a urgent bug in production, you’d better put all your files in a Visual Studio solution and work from there.

Another suggestion I received, to have a complete out of the browser development experience also for document types is uSiteBuilder. I still have to try it, but it seems like this package might also make automated deployments possible.

Is community a feature?

Most consulting companies, when comparing software solution don't give the right importance to the community factor: my short experience with the umbraco community showed that even a relatively small community, if full of smart and helpful people, can even overcome technical defects, weak points and missing features of a software.

What about Orchard

I think I'll now try to redo the same website in Orchard, to be able to compare the development and the user experience of the two main CMS in the .NET space.