Building first Umbraco 5 website: Document Types

  1. Building first Umbraco 5 website: Document Types
  2. Building first Umbraco 5 website: Nodes
  3. Building first Umbraco 5 website: Templates
  4. Building first Umbraco 5 website: Partials

I have been working with the Danish-made CMS, Umbraco 5 for the past few weeks. The experience was both good and bad (read here about my first impressions and here about resources) but definitely interesting enough to share. It resulted in a series of posts, first of which you are reading now.

The series will describe my experience with creating a relatively simple Umbraco 5-based website for a made-up coffee shop. I will try to describe it in a step-by-step tutorial-like way, that is to say that I will spare you the description of every single mistake I made or every single place that got me stuck. I will however point out the pitfalls and sticky points, based on my experience. For the moment I have no possibility to host the website online so no demo is available but I will try to rectify this as soon as possible.

Disclaimer: However, please keep in mind that I am in no way an expert or professional in the field. Therefore I submit to you a description of a learning process rather than an expert tutorial and I ask you to read it as such. More than that, I encourage you to comment to point out mistakes or suggest better practices.

So here it comes.

Step 1: Design

While it is possible to code your website from within Umbraco backoffice it seems to me that this is an ineffective practice. I started by designing and HTML/CSS coding my website before I got anywhere near Umbraco.

The HTML/CSS part will come handy in one of the following posts but we can forget it for the moment. These are the quick designs I made for this test website:

Front Page

Front page design
Events Page

Events page design
Particular Event Page

Event Design Page

Menu Page

Menu Page design

Step 2: Document Types in Theory

To do anything in Umbraco you have to start with document types. These are the “definitions” for your content holders, the nodes. They govern the type of content your user will be allowed to enter in her pages.

To create document types, you need to start by deciding how many different types of pages you have and what content you would like to store in them. The types of pages are not described by the design or layout but rather by the types of content that appears on them. For example a hypothetical gallery and an article will be different document types because one holds images and the other holds mostly text and maybe an illustration. On the other hand a hypothetical article and an about page might well be the same document type even if they have very different d

esign because they both hold mostly text and possibly an image.

It is perfectly possible to create a document type for each and every page you are planning to have in your website but this is a nightmare to maintain and will effectively defeat the purpose of using CMS for quick edit of content. In fact I suggest striving for organization and simplicity when working with Umbraco as this is where its strength lies.

So let’s see how to create document types in Umbraco 5:

  1. Creating document types in Umbraco 5Go to backoffice
  2. Click Settings
  3. Right Click Document Types
  4. Choose Create
  5. Type name of the Document Type and choose if a template with a matching name should be created (it’s not very important because you can always create and delete templates later)

In the Document Type window you will see 4 tabs:


These are general meta properties of your document type. The only one you could consider changing at this stage is the Icon. Different icons help users understand the differences between different types of nodes. This will become clearer as you read on.

Creating Document Types


This tab allows you to establish the relationship of your document type with other document types and/or templates.

  • Inherit from – this option allows you to choose if some properties of other document types should be inherited by this document type. This is useful for properties such as keywords or meta description. You want to have these type of properties on every page so instead of adding it in every document type you can just set a document type for SEO from which all other document types inherit.
  • Allowed children – this option allows you to establish what pages can be created as children of this document type. In our case that means for example that the Event page document type should allow for Particular Events pages as children.
  • Inheritable only – if chosen will prevent users from creating this node in content section of the backoffice. This again is useful in terms of SEO for example. You don’t want your user to create a page with keywords and description that is published and available as part of the website. Instead you can make the SEO document type inheritable only and make all other document types inherit from it. These means that on each page users will be asked to enter SEO properties.
  • Allowed templates – they are exactly what you think they are. Should your article page have only one layout or should it also have a high-contrast design? This is where you decide if the person creating the page should be guided to the default layout or be allowed to choose from a number of them.
  • Default template – this is also self-explanatory


This tab is also rather easy to understand. Here is where you create new properties which are basically types of content your users will be allowed to input.

  1. Click on the Click here to add a new property button to add a new property (sic!).
  2. Type the name of your property (ex. Heading, Body Text or Date).
  3. Alias will be filled automatically but you can change it if you need to. It is how Umbraco refers to this property.
  4. Data Type dropdown allows you to choose what kind of content users should be allowed to enter. The most common data types seem to be Rich Text Editor (RTE) which is a typical WYSIWYG kind of editor, Textstring and Textarea which are input fields that do not allow any formatting, and Media Picker which allows you to choose previously uploaded images etc.
  5. Below Data Type you also have Tab dropdown where you choose which tab in content editing section your property should be on. Most commonly it is Content tab (but you can also add Images, SEO or any other tab you can think of).

Document Type Properties Tab in Umbraco 5


This tab allows you to create and administrate tabs in the content section. It will start making more sense when we get to the content part in one of the following posts.

Step 3: Document Types in Practice

The pages I designed for the coffee shop can be analyzed from the content perspective in the following way (for the purpose of this website we will ignore the header and footer as they will be for the most part hardcoded, menu will be described in a later post):

1. Front Page

  • Left side heading
  • Image
  • Text block (content text)
  • Right side heading
  • Right side text

2. Events Page

  • Left side heading
  • Image
  • Text block (content text)
  • Right side heading
  • Right side text

3. Particular Event Page

  • Left side heading
  • Date
  • Cost
  • Image
  • Text block (content text)
  • Right side heading
  • Right side text

4. Menu Page

  • Menu section headings
  • Menu items
  • Menu items prices

You will notice that Front Page and Events Page have exactly the same type of content. It will therefore require only one document type, Text Page. The name of the document type depends on you but it is a smart idea to make it descriptive. This document type will contain the following properties (or content fields):

Text Page properties

Notice that I created 2 tabs: content and sidebar. This is the way I choose to organize the content editing section. You can do the same or choose to keep all the properties on one tab.

The solution I used above is not optimal. Row1Lable and Row1Vaule correspond to day of the week and the times the café is open on these days. That of course will prove too few lable/value rows if the owner chooses to have the café open in different times each day of the week. I took a leap here, accounting for the most likely scenario. There are two ways that this can be avoided. One is to use RTE and instruct the user to enter input as a list and add proper styles. But frankly, we all know you can not rely on users to do what you ask them to. I explain the second, most effective solution, below (in Menu document type).

This document type will allow child pages of the type Text Page and Menu (and again this is something that will make more sense when we get to the website structure) and it will not inherit anything (I ignore SEO in this example). The only allowed and also default template for this page will be Text Page.

Particular Event Page has almost the same content as the 2 previous pages and could be dragged under the same document type. That would mean that the user could supply Date and Cost also for Front Page and Events Page and I would have to make sure that in my template I ignore this fields so that they are not rendered on the these pages. But for the sake of cleanliness I will give it a separate document type, Event Page. These also means that I can make the sidebar on this page more flexible and use RTE for Address and Details text section.

Event Page Properties

This document type will not allow any child pages and it will not inherit anything. The only allowed and also default template for this page will be Event.

And lastly, we have Menu Page which is a bit more complicated than the previous pages. The first impulse you might have (as I did) was to create a document type, call it Menu Page and be done with it. However this would mean that we give the user/owner of the café a limited amount of menu sections and menu items. They could have food, drinks and desserts but if they wanted to have alcoholic drinks they would have to come back to us and ask for a new property. So the problem is the same as in the Text Page document type.

This time I wasn’t willing to guess how many food items does the owner of the café plan to have from now to eternity and so instead of 1 document type, I made 3.


  • Has no properties
  • Allows Menu Section children
  • Has Manu template

Menu Section

  • 1 property: Heading (textstring)
  • Allows Menu Item children
  • Has no template

Menu Item

  • 2 properties: Menu Item (textstring) and Price (integer)
  • Allows no children
  • Has no template

This way the owner of the café is able to create as many Menu type pages as he wishes. For the Menu type page he can create child nodes of Menu Section type (and again, he can create as many child nodes as he wishes) and for each of the Menu Section types he can create as many Menu Item types as he wishes. For example:

Example of content structure in Umbraco 5

In the next blog posts I will explain how to make the Menu page display Menu Section and Menu Item pages’ content but for now don’t worry about how to do that.

This is where I stop this blog post since it grew quite large as it is. The next blog posts in this series will cover:

Post 2: Creating and Publishing pages
Post 3: Templates
Post 4: Adding the magic: Partials

11 thoughts on “Building first Umbraco 5 website: Document Types

  1. Adam Werner

    Great start! I’ll be looking back here for the successive posts.

    I’d be interested to see, as you go forward, if you revisit your document structure decisions — I usually find that I’ll start with something and as the project continues I may need to restructure/extend some documents along the way. With Umbraco V5′s multiple document inheritance, I can see that helping out quite a bit in this area.

    1. Inabox Post author

      Hi Adam,
      thank you for your comment. I certainly corrected the document types structure as I worked. That especially had to do with the Menu page but resulted mostly from me learning how to do things and not really reorganization of the website itself.

      You have to consider that this is really a very small and simple website and thus it was easy to predict what kind of document types I will need and what they will need to inherit or not. I suppose that with larger websites the situation becomes much more complex and rethinking along the way is needed.

      Anyway, I’m looking forward to reading more of your comments on the following posts.


  2. Pingback: InaBox Design Blog : First website with Umbraco 5: Nodes | InaBox Design Blog

  3. Renzo

    Thanks man, this will help me. I’ve been looking for a while for a good basic but somewhat indepth tutorial for Umbraco 5.

    I will be comming back for all 4 parts.

  4. Pingback: InaBox Design Blog : Building first Umbraco 5 website: Templates | InaBox Design Blog

  5. Pingback: InaBox Design Blog : Building first Umbraco 5 website: Partials | InaBox Design Blog

  6. Pingback: InaBox Design Blog : Installing Umbraco 5.1 | InaBox Design Blog

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>