Creating fast, Examine indexable widgetized Umbraco websites (Part 1)

Umbraco has always been a good CMS when it comes to flexibility, and with the need to produce ever more engaging websites, that flexibility has become increasingly important.

Making fairly large websites at work and following the developments in the community (such as WebBlocks) has made me realise how important it is to consider the content editor when developing websites; if you can make the editors job easier by allowing them to reuse content and create a variety of different pages, then the quality of output they produce is likely to improve.

At work I have been working on what we call a ‘Base Build’ for Umbraco; this involves making a large amount of reusable components to save us time in the future. I decided to use a widget system for this base build to keep it modular and easily extendable. Creating a base build that is flexible for developers inevitably ended up with us creating a solution that was also flexible for editors.

Improving the experience for content editors allows them an easier way to create engaging websites, but they can also cause problems with other concerns. I'll describe the different ways to make flexible Umbraco sites, the strengths and weaknesses of each approach and outline the approach I take on sites I make at work. Then I'll describe the negative effects caused by my approach and how I managed to fix them.

Flexibility and Reusability in Umbraco

Flexibility is at the heart of Umbraco and there are many different ways to allow editors to get creative with their websites (in a controlled way of course!).


An Umbraco node can be assigned a template that creates the markup for the page. In Umbraco an editor can select the template they want to use from a list of supported templates. This allows them a degree of flexibility when it comes to choosing how a specific page should look. Unfortunately this is only a small amount of flexibility as the page can only be comprised of the fields in the document type and every layout must be designed by a front end developer.

Document Types

To allow more variety, different document types can be added with more (or different) fields. This allows the developer to set up different forms of page, but these must be specced out before the build, turning this approach into something similar to hard coding.


Macros are the backbone of Umbraco, allowing a developer to easily integrate functionality from a variety of different technologies into a template. One thing that is often overlooked is how powerful macros can be from a flexibility point of view.

Macro parameters can be used to build a piece of functionality once, and then use it multiple times on the site with results that depend on the input parameters.This is both a time efficient and cost effective way to make websites in regards to both developing and editing.

This flexibility is undermined unfortunately if the specific parameters are hardcoded into the templates, for example:

<umbraco:Macro Alias="TwitterFeed" runat="server" userName="_SamMullins_" ></umbraco:Macro>

A more appropriate method is to use the macro picker feature in Umbraco’s rich text editor. This will allow the editor to choose the parameters they want to add. Even though you can filter which macros the content editors can insert, as a developer you lose control over where they can insert in the page. Giving a content editor flexibility is one thing, giving them free reign is another!

My personal favourite is to use the “Macro Container” data type in Umbraco. This allows editors to insert as many macros as they want (up to the maximum you choose) with their chosen parameters into sections of the page defined by the developer. This allows the front end developer to have more control over the layout of the page whilst still allowing the content editor to compose a page of components they feel are most appropriate.

This works great for macros that only have one or two parameters; if there are a large number of parameters and same settings are often used on multiple pages the content editor finds themselves inputting the same content over and over again, exactly the situation we were trying to avoid. This is why I chose to architect my Umbraco projects as a set of widgets.

Creating a Widget Based Umbraco Website

Umbraco sites often make use of pulling content from other pages into the content of other pages. An obvious example of this is a simple blog, where a listing is created from a node’s children. There is no reason why this content has to be pulled from other pages though, we can use the node structure of umbraco to store content that is never intended to be displayed as a whole page. When you embrace this, Umbraco becomes amazingly flexible!.

Child Content

Sometimes page designs will not be a simple content area of rich text. An example of this is for a project I’m doing for a housing company. An estate page has a tabbed area that can be used to display information about the services offered, the local area etc. Now you could add each one of these sections as a tab in the document type with a the appropriate fields in each tab but this is not a flexible approach. Instead I created sub nodes to this estate that can be pulled through to the main page; the tabs themselves will never be navigable as a page, they are purely to store content. For example:

  • Estate
    • Content Tab
    • Services Tab
    • Local Area Tab
    • Content Tab
    • Content Tab

I can then write a macro script for this checking for all tabs and rendering them on the page. If the editor decides that a certain estate needs more tabs than others they can add the child tab nodes to that estate and they automatically appear. To me this is much more user friendly and flexible.

This approach is great for a situation like this, where the content will only be used once, but if a piece of content can be used multiple times storing the piece of content under a content node is not ideal. What we need to do is structure a widget based solution.


By mixing the concepts of macro parameters and the nodes used purely for content storage, it is possible to create a document type that matches the parameters for a macro and then point to nodes of this type as one single parameter in the macro. For example:

Instead of using

    <umbraco:Macro Alias="TwitterFeed" runat="server"
    title=”Latest Tweets”


    <umbraco:Macro Alias="TwitterFeed" runat="server"
    Node 1178 (of document type TwitterFeed)
    - userName="_SamMullins_"     - hashTag=”#Umbraco”     - title=”Latest Tweets”     - amountToShow=”3”

This means that every time an editor wants to insert this specific macro into a page they only have to fill in one parameter rather than four. Whilst this may seem like a tiny gain for such a trivial example, once you scale this up to large sites with more complex macros the possibilities are incredibly powerful.

To improve the editors experience even more we can now store them in organised folders in the tree. For example:

  • en-gb
    • Home
      • Blog
      • About Us
      • Contact
    • Widgets
      • Testimonials
        • Example Testimonial
      • Twitter Feeds
        • _SamMullins_
        • Umbraco

We now have Umbraco site where content is reusable, logically organised and the layouts are flexible but where editors don’t have carte blanche.

Unfortunately this technique is not without its drawbacks, however there are ways to combat this which are surprisingly simple and quick to implement. I will describe my solutions to these problems in Part 2.


comments powered by Disqus