Umbraco Zeitgeist: Effective Umbraco Development in 2016

Heads Up!

This article is several years old now, and much has happened since then, so please keep that in mind while reading it.

How you should build Umbraco sites, how you shouldn't build Umbraco sites, and how Umbraco sites will be built in the future.

In the beginning, there was nothing. And then, suddenly and without warning, Umbraco was formed. It expanded rapidly, engulfing everything in a plasma of XSLT and Web Forms. As time went on, that plasma evolved into the basic building blocks of our lives today, Razor and MVC. By random chance, those building blocks started to form the basis of more complex entities in the Umbraco universe.

Those complex entities further subdivided and recombined into various taxonomies: macros, packages, approaches, systems, and so on. Some were the most fit in their era, though all are subject to changing times and so may become supplanted or go extinct.

This article will go over those that are no longer fit (bygones), those that are the most fit (zeitgeist), and those that promise to become the most fit (horizon) given a little more time to evolve.

Umbraco Zeitgeist (Today's Umbraco)

We must utilize our resources to keep pace with an ever evolving world.
We must utilize our resources to keep pace with an ever evolving world.

There are a lot of different ways to build Umbraco websites. Some of those techniques are now considered outdated, and some of the effective techniques are slowly being replaced by more effective ones. Before getting into the older or newer ways, I'll cover a few of the more effective ways that Umbraco developers build sites today, which will include:


Coming from a developer who has worked a lot with ASP.NET Web Forms, ASP.NET MVC (and most especially Razor views) is really nice. The syntax is super concise, there aren't a lot of opinionated controls built in, and it allows developers to more easily create webpages that use a variety of new technologies. MVC is also a great way of separating business logic from the view and formalizing a model of the data.


Each version of Umbraco has had some answer to create complex content (think lists and nested content). The current best solution to that need is Archetype. It's a package that installs a property editor with a very advanced configuration page. Essentially, you can create a list of any type of content, and those lists can in turn contain lists of Archetype content.


  • Inline Content. Inline complex content makes editing quicker and more intuitive.
  • Robust Feature Set. Contains all the features it ought to (sorting, cloning, deleting, restrictions, and so on).


  • Scales Poorly. Slow when you have dozens of Archetype fieldsets on a property. When they get into the hundreds of fieldsets containing things like media pickers, pages (in the Umbraco interface) can take minutes to load. Based on this commit, this may have been fixed in the latest release (curently, 1.12.0).


  • Use It. You won't regret it. So long as you allow for spreading bulk content across multiple nodes, it is great to work with for content editors and developers.


There are a bunch of ways you can allow content to be entered on a website. One way is to make a bunch of document types corresponding to very specific variations of pages (each variation having a different set of properties). Another way is to have a very small number of document types, and allow for any variation of layout by using the widget concept. Basically, you create a single property based on an Archetype that contains a bunch of fieldsets. Each of those fieldsets is a "widget" (e.g., rich text, image, slideshow, layout grid, and so on). This allows content editors to create any element on the page in any order.


  • Flexible. Content editors can create most any type of layout on any page.
  • Faster Development. Because you are developing a series of widgets rather than a bunch of pages, development can go faster.


  • Too Flexible. Content editors can create most any type of layout on any page, including layouts that don't necessarily make sense on those pages.


  • Curate Content. Form a relationship with the content editor to give them guidance on the types of content (widgets) that should appear on various pages.
  • Create Presets. I haven't tried this yet, but I'm thinking of giving it a try. For different content types, create an "example" page. When somebody tries to create a node of that content type, intercept that and copy over the widgets from the example page. An easier solution is to just create sample pages and allow editors to copy those nodes.
  • Documentation. Use packages like uEditorNotes to add documentation to document types that indicate the ideal widgets for particulare page types.

Picked Widgets

When using Archetype to create widgets, you'll find that some widgets appear on a number of pages without any variations (especially common with sidebar elements). Rather than force that content to be entered over and over, I recommend creating what I call "picked widgets". Essentially, you create an Archetype fieldset that has a content picker to some part of the content tree that contains widgets that can be reused. Then, instead of recreating the widget over and over, the content editor just creates a picked widget and selects the existing widget. If you are having trouble visualizing what this looks like, here's an example (click to enlarge):

Picked Widget


  • Faster. Content can be created and changed faster.


  • Confusing. Because the content doesn't exist in one place, it is not always obvious where to edit the picked widget to non-experts.


  • Facilitate, Don't Force. Allow for widgets to be picked, but allow each picked widget to also exist as a local widget. If an editor finds picked widgets to be confusing, they can create a local widget.

Contour / Umbraco Forms

If you want to build a few forms (say, some contact forms and feedback forms), Umbraco Forms is your best bet. While not the same, Umbraco Forms is intended to be a replacement for Contour. It seems as if the Umbraco core team would like a fresh start, and so they are building Umbraco Forms using a different codebase from Contour. There are some differences, though many of them are superficial. For example, while Umbraco Forms doesn't support code-first forms like Contour, Umbraco Forms does store forms as JSON files, which means they can be source controlled. And Umbraco Forms has a built-in means of creating grid layouts.


  • Dynamic. Allows non-technical users to modify forms (e.g., change fields, send emails on submission).
  • Extensible. Parts of Contour are extensible (e.g., you can add custom field types). Umbraco Forms is likely similarly extensible (haven't looked into it much yet).


  • Buggy. Fairly significant bugs sometimes take years to fix, and others haven't been fixed.
  • Closed Source. Given the limitations of Contour / Umbraco Forms, it would be nice to submit some pull requests. However, since it is closed source, that is not possible.
  • Not Free. It's not expensive, but it's not free, so keep that in mind when considering using it.


  • Be Wary. Use Contour or Umbraco Forms, but be wary of their limitations. They may cause you to invest extra time implementing workarounds.
  • Use Either. If you are already familiar with Contour, keep using it. If you are building a new site, it may be time to look into Umbraco Forms.


AngularJS is the framework used by the Umbraco back office. The Umbraco team have also mentioned they will be building Umbraco 8 with the next version of AngularJS. You can think of AngularJS as a way of building reusable components in HTML/JavaScript. It is used to build all of the UI elements you see in the Umbraco back office (e.g., property editors, trees, dialogs, dashboards, and so on). If you haven't invested time learning AngularJS, there is no better time to begin doing so. Not only can you use AngularJS to customize Umbraco, but you can use it when building the frontend of your websites too.

New Relic

New Relic is a monitoring tool. You can install it on your server and in your website to enable monitoring, then you log into the New Relic website to get information about your site. It has a ton of useful features, such as graphs showing resource usage (i.e., RAM, CPU, drive space) and information about errors occurring on your sites. You can even configure alerts (emails) to be sent to you based on configurable conditions (e.g., if a site is unresponsive for a few minutes or if a hard drive is filling up).


  • Easy. You just create an account, run some executables, and you are up and running.


  • Expensive. They offer a free tier, but that has some limitations. Their pro tier is relatively expensive (hundreds of dollars a month).


  • Try It. Try the free version. If you run into problems and you need the pro version, you can always pay for just a single month.

dotTrace / dotMemory

dotTrace and dotMemory are profiling tools that allow you to figure out where CPU and memory are being used. I have found them useful when troubleshooting an issue on a production server in which the CPU would periodically spike, and another time when memory would increase over several hours. They are more detailed than New Relic for those times when you really need to dig into a performance issue.


  • Detailed Stack Traces. The traces you get (e.g., for CPU usage) are extremely detailed. You can usually see exactly which function or stack is causing high CPU usage.


  • Expensive. You can no longer purchase these tools individually. You have to purchase ReSharper to get them.
  • Resource Intensive / Invasive. If your production server is having CPU/memory issues, these tools can exacerbate the situation. One of these tools messed up an app pool once so that even a server restart didn't fix it (I had to fiddle with some configuration).


  • Trial. If you are having a production issue, try these tools during the trial period to see if you like them.

Slimsy / Slimmage

Slimmage is a JavaScript library that facilitates serving up responsive images regardless of the user's browser size or the pixel density of their screen (e.g., retina displays). It works with a server-side image processor to ensure images are served to a user in exactly the correct size (which reduces bandwidth without sacrificing quality). Slimsy is an Umbraco package that coordinates between Slimmage and ImageProcessor (Umbraco's aptly named server-side image processor). You can read more about the relationship between Slimmage and Slimsy here.


  • Easy Responsive Images. You no longer have to create picture elements and manually code the markup for the mobile / tablet / desktop versions of an image.


  • Malformed Markup. Slimsy apparently processes and adjusts the markup for the entire page so it can output the correct markup for images. It seems to do it in an invasive way that can cause HTML tags to become self-closed (e.g., <div></div> might be converted to <div/>), which can break some layouts.
  • IMG Only. If you intend to use a <picture> element for different images at different breakpoints or if you need a CSS background image, Slimsy can't be used. It is for use with <img> tags only.


  • Use Slimmage. To avoid broken markup, just use Slimmage and manually code what Slimsy does (basically, it adds some markup where your images appear in the HTML).


ImageProcessor is the server-side image manipulator that now comes with Umbraco. It allows you to make a request (such as with the src attribute of an <img> tag) to the server for an image, including various query string parameters to manipulate the image (e.g., resize, change compression quality).


  • Built-in and Free. ImageProcessor comes built into Umbraco and is entirely free.
  • Chained Processing. You can chain multiple operations for complex image manipulations.


  • New. It only comes with newer versions of Umbraco (7.1+), so it may not be included with your older installs. Luckily, you can install it manually in older versions.


  • Use It. You can't go wrong with ImageProcessor. As mentioned above, you may even be able to use it with Slimsy for more seamless responsive images.

Document Type Compositions

It used to be that if you wanted a property to exist on a bunch of pages, you'd create it in a parent document type, then you'd have each page be a child of that document type. However, there would always be some exception (e.g., if you have a secured extranet, there is no use having a property for the meta description, as search engines can't access those pages anyway). Those exceptions meant a more complex document type configuration, or you'd have garbage properties. With document type compositions, you can essentially have multiple parent document types, which allows you to split properties into logical groups (document type compositions) and selectively include them on other document types.


  • Prefer Compositions. Only nest document types for organization purposes (e.g., put all the components under a "Components" document type). Use document type compositions instead of nesting to associate common properties to multiple document types. A later version of Umbraco is even promising actual folders so you don't need to nest document types for better organization.


Bookshelf adds a section to Umbraco that allows users to read markdown-based "books" (essentially, a hierarchy of markdown files). It includes a markdown editor and renders markdown to HTML.


  • Robust Documentation. This is documentation that is more robust than you'd be able to fit inline on a content page, for example.
  • Searchable. It uses Examine to make the books searchable.


  • Permissions. I didn't see a way to restrict who can edit books. So, anybody who can read a book, can edit one.
  • Images. Images must exist on the server before they can be inserted into a book (i.e., there is no upload button).


  • Explain Problematic Scenarios. If editors of your Umbraco implementation are having issues figuring certain things out, explain them in the Bookshelf.

Umbraco Bygones (Yesterday's Umbraco)

The buzz used to be all about the moon landing, but we've learned since those first steps.
The buzz used to be all about the moon landing, but we've learned since those first steps.

These tools and techniques all had their time, but for reasons I will explain, they are no longer recommended. This list of misfits includes:

Child Node Widgets

It used to be that the only built-in way to create a list of content of an arbitrary length was to create that content as child nodes of the page the content was to be added to. For example, a homepage node might have a slideshow node under it, and that node might have a number of slide nodes under it. This has the problem that the content can't all be seen and edited at once (i.e., you must navigate between nodes to edit each slide).


  • Archetype. As discussed previously, Archetype is great at handling lists of content (especially widgets).

Repeatable Custom Content

Many moons ago, a package surfaced that allowed you to edit lists of content. It was called Repeatable Custom Content (and later Repeatable Custom Content v2). It was a useful solution in Umbraco 4 if you wanted to avoid child node widgets. However, it hasn't been updated in 6 years and the author was hesitant to publish the source code (he seemed to just email it to people who were interested), so by now it is antiquated and unsupported. There are better options.


  • Archetype. Archetype is almost a direct (if fancier) replacement for Repeatable Custom Content.


uComponents was a really awesome package that contained everything that seemed to be missing from Umbraco. However, much of what was contained within uComponents eventually got integrated into the Umbraco core. uComponents is also incompatible with Umbraco 7.


  • Umbraco. Since much of uComponents became integrated into Umbraco, a plain Umbraco install will give you much of what uComponents offered.
  • nuPickers. A collection of property editors, much like the ones available in uComponents.
  • Archetype. Think of this as a replacement for the uComponents datatype grid.
  • uEditorNotes. Great for adding rich text notes to content nodes (e.g., editor instructions).

XSLT / Web Forms

The two dominant ways of building sites in Umbraco used to be XSLT and ASP.NET Web Forms. XSLT made some sense, as Umbraco stores a cache of the website's data in XML. However, it makes little sense now, considering the varied types of data Umbraco now stores (hint: lots of JSON as of late), and the limitations of this declarative language. Web Forms was another common way of developing Umbraco websites. While it's still possible to develop Umbraco sites in Web Forms, the default is now ASP.NET MVC.


  • ASP.NET MVC. Razor syntax alone is enough to prefer this.


Macros are an Umbraco-centric concept that is really a combination of a number of technologies: XSLT, ASP.NET user controls, and Razor views. You can embed macros either in a template (read: ASP.NET master page or Razor view) or a rich text editor (and, from what I've been reading lately, they can also be added to the Umbraco grid). They can be nice if you are combining a number of technologies, but for new installations there are very few uses for them. They are also somewhat inflexible in the type of data that you can pass to them. By avoiding macros now, you can avoiding running into their limitations later.


  • Archetype. Rather than embed macros in a rich text editor, create widgets using Archetype (some being rich text widgets, and some being what you might have created as macros).
  • Partial Views. Rather than build a macro to insert into a template, just build a Razor partial view and render it from that template.

Complex Rich Text

If an editor wants to do something "custom" on a page, they might try to modify the rich text to add some inline styles and markup. They may also insert some macros to embed some complex functionality that is surrounded by text. However, there are better ways, and you shouldn't expect your content editors to be HTML/CSS gurus.


  • Archetype. You can create fieldsets that allow editors to build any type of responsive layout they could want.
  • Widgets. If you are using Archetype, building arbitrary widgets is trivial. They can be as simple as rich text or as complex as custom forms.

Highly Structured Document Types

It is usually the case that you have a set of properties common to most pages (think meta description, page title, header image, and so on). One way of adding those properties to every page is to create a parent document type. Trouble is, not every page has those properties, so you end up with complex document type hierarchies that are hard to change (e.g., base page, public page, extranet page, headerless page, and so on).


  • Compositions. Now that Umbraco has document type compositions, you can inherit selectively from multiple document types. You might have a composition for SEO page properties and another for the properties used by pages with a header.


Contour is the typical way you would create forms in Umbraco. However, Contour has a number of issues, such as no built-in way to do AJAX forms, a clumsy method of customizing form Razor views, hard to troubleshoot bugs, and form fields that are hard to identify programmatically (to name a few).


  • Umbraco Forms. This is replacing Contour. Since the Umbraco core team has shown more of an interest in Umbraco Forms as of late, I expect it will become of higher quality than Contour was.
  • Formulate. I'm in the process of building a free, open source form builder that will solve many of the problems that have been around for years in Contour. If all goes according to plan, you should see some information about it here in early 2016:


In its day, ImageGen was the lead image manipulation package. It allowed you to do things like resize images and apply effects. It was really useful if you wanted to resize images automatically to be served up to different devices (e.g., smaller images for mobile). It started free, but cost a small fee if you wanted more control over the configuration.


  • ImageProcessor. ImageProcessor now comes built into Umbraco and does all ImageGen did and more. It's also free.

Umbraco Horizon (Tomorrow's Umbraco)

If we dream big enough, we can expand our own horizons.
If we dream big enough, we can expand our own horizons.

For one reason or another, these aspects of Umbraco development are either not ready, or are somewhat risky, so they may need some refinements before I'd recommend their use in a production environment. Still, they have enough to offer that they are worth considering. Here's what the future of Umbraco will look like:


The grid is an attempt to make the back office look a bit more like the grid you'd see on a Bootstrap (or Foundation, or other grid-capable framework) site. It helps make it more clear to editors that their content will appear in multiple rows and columns.


  • WYSIWYG. This makes the back office look a bit more like the website.
  • Repeatable Content. The grid may be the only current property editor that allows editors to create repeatable content in a single property.
  • Galleries. One interesting use case I have seen is to create a media gallery using the grid (gives the editor more control over the layout of the images).


  • Blob of JSON. Right now, the grid just stores the data as a blob of JSON, which causes all sorts of problems (think: Courier, Examine). You can watch a video about it here.
  • Beta Feature. This feature is really more of an experimental feature. There are plans to release an updated version, which you can read about here.
  • Minimal Core Support. If you want a property editor (or, as they are apparently called, grid editors), you will probably have to build it yourself.

Doc Type Grid Editor

This is a package that extends the capabilities of the grid. It allows you to insert cells that have properties based on document types. So, you click a cell and it opens a dialog to allow you to edit the fields.


  • Sophisticated Layouts. You can use this to create what are essentially widgets in interesting layouts.


  • Temporary. My guess is something like this package may become integrated into the grid at some point, so this may become redundant eventually. In other words, it's too useful.


This is a collection of property editors that allow you to use a number of data sources to pick data in a variety of ways. While I haven't used nuPickers, it seems like it could be really useful for picking data in ways not built into Umbraco. Really the only reason it is in this section is because of my lack of in-depth familiarity with it.


  • Custom Display. Most (or all) of the pickers allow you to render whatever you want for picked items in the back office so the content editor has more information (e.g., a sample rendering of a slideshow slide).


  • Missing Hierarchy. One common type of picker would be one that allows items from a hierarchy to be selected. Think a multinode treepicker that could accept any data source.
  • Missing Structure. Wouldn't it be neat if you could pick a node, then pick some related nodes, then pick nodes related to each of those nodes (to build, for example, a menu or a product finder)?

Umbraco Forms / Formulate

Umbraco Forms is the latest incarnation of Contour, the original Umbraco form builder. Formulate is a free, open source builder that is currently being developed. Both are likely to become the dominant form builders for Umbraco websites. Form builders like this make it very easy for content editors to create forms (e.g., contact forms, feedback forms, newsletter subscription forms, and so on) themselves, and attach custom actions (e.g., emails) based on submissions to those forms.


  • Formulate: Free. While Umbraco Forms is not very expensive, free is always nice.
  • Formulate: Open Source. Particularly useful if you run into an issue you need to fix. Also, the community can contribute, which gives us more of a say in what is important to us.
  • UF: Core Support. It may be easier to convince manager types to adopt the use of Umbraco Forms, as it has official support by the Umbraco team.
  • UF: Supports Umbraco. Money paid for Umbraco Forms supports the Umbraco core team.


  • Formulate: No Official Support. With no official support planned (yet), you may have to figure out some things yourself.
  • Formulate: Incomplete. While it is definitely planned for release in early 2016, it is not yet complete. You can follow the progress here:
  • UF: Closed Source. That means all development is done by the core team, and so development is less driven by community guidance. Additionally, bugs are that much more difficult to fix and work around.
  • UF: Historically Problematic. There are too many to list, but you can read about the issues here (TLDR: buggy, poorly architected, limited customizability, not HIPAA compliant, not AJAX-friendly).

List View

List View is a great new way of accessing nodes in the content tree (or, rather, accessing nodes without the content tree). Essentially, it replaces a subtree of content nodes with a paged table of content nodes. If you are aware of its limitations, it is usable as is. However, it can be clumsy to use in some situations.


  • Catalogs. List View really shines when it comes to large catalogs of items (e.g., a product catalog with thousands of products). Expanding a full tree of items is slow, so List View offers a fast way of finding something you are looking for.


  • Grandchildren. List View doesn't handle grandchildren well. See here for a discussion. Basically, you must enable List View on children of a node with List View enabled; otherwise, you can't access the children of the children.

Variants / Segments

These are probably the coolest features that don't exist yet. In simple terms, variants allow you to create alternative versions of your content, and segments allow content to be personalized for different audiences (i.e., show different people different things). You can watch this video for more information.


  • Translation. Variants would make it really easy to create translations for content nodes.
  • Optimized Marketing. Segments would make it really easy to optimize content for different types of visitors, which would facilitate more relevant marketing.


  • Not Available. Neither of these features are actually built yet, but they're planned for Umbraco 8 (if all goes according to plan, before 2017).

Starter Kits

Starter kits aren't just for getting simple sites up and running quickly. If you are an agency, why not create a starter kit using the functionality common to most of the websites you build, then start your new builds with most of the boring and common stuff already done? Yes, you can create starter kits yourself. It's as simple as creating a package and selecting pretty much everything in one of your websites. Once you have a package created from one of your sites, you can then install it into a new empty site and hit the ground running.


  • Time Savings. Imagine all the cool extra stuff you could do if you could avoid doing the things common to most sites; the time savings in percent would likely be in the double digits (say, 30%).
  • Common Code Base. If you build lots of sites from a common code base, you get the benefits of shared code (e.g., greater stability and easier updates).
  • Subtractive Construction. Rather than spend months upon months adding features, you can start with a full suite of features, then spend hours or days deleting the ones that aren't appropriate for your use case.


  • Entrenchment. The downside to using something that can save you a ton of time is that you may become overly reliant upon it. If you don't keep your starter kit up to date, it may eventually lead you to use outdated techniques.
  • Unproven. Having not tried this myself, I can't be sure there won't be some complications (e.g., I don't think third party packages are well supported without very custom code). However, that is just my experience; others may be using this extensively.
  • Better Alternatives. I've heard of some interesting approaches, such as storing a starter website in source control, including a scripted version of the database (i.e., you'd just clone that to create a new site). Another alternative might be's new feature, Baseline (see below).

Umbraco as a Service / Baseline

Umbraco as a Service is still very new, so use it at your own risk. However, the potential is immense. It essentially gives you hosting, setup, source control, and Courier out of the box for a relatively small monthly fee. Baseline is a feature built into UaaS that allows you to create multiple websites based off of a starter (or "baseline") website. From what I understand, it uses Git under the hood, so any changes made to the baseline website can be merged into forked websites.


  • Ease of Use. This has the potential to make Umbraco vastly easier to setup and begin using for novices.
  • Improved Courier. Since Courier is used with UaaS, and the Umbraco core team will be partially supported by proceeds from UaaS, it is in their best interest to improve the quality of the Courier code base, which has historically been lacking. They seem to be calling this initiative "Umbraco Deploy".
  • Change Management. By spawning many websites from a few baselines, it should be much easier to manage change (e.g., deploy updates from one baseline to all derived websites).
  • Automatic Upgrades. Umbraco upgrades can be a pain, so the fact that they are done automatically is awesome.


  • Less Control. With UaaS, you are essentially tied to Azure and the way the Umbraco team does deployments, though you could probably export the site if you decided to host elsewhere.
  • Troubleshooting. Speaking from experience, Azure sites can be a real pain to troubleshoot. While their staging capability is nice, it can be slower than molasses at times. And depending on the type of Azure instance (e.g., cloud services), gaining access to the server itself can be troublesome.
  • Expensive Upgrades. If you need a staging server (rather than just dev/prod), you will need to upgrade from the 89 EUR/month plan to the 359 EUR/month plan (those are the current rates shown here).


If you are in need of a blog, this seems like the most active and promising package available for Umbraco. After having worked with uBlogsy and uCommentsy and reviewed the code for Articulate, it seems to be hand over fist an improvement over the former two.


  • Well Engineered. Unlike comparable packages, Articulate seems to be very well engineered. I wouldn't expect many issues to crop up in terms of bugs and limitations.
  • Theming. The swappable theming system used by Articulate is really interesting. This is what many people expect out of a blogging engine. What's also exciting about this is that it gives Articulate room to grow to a more out of the box solution (i.e., usable instantly), in addition to it being usable as an integral part of an existing website.


  • Difficult to Integrate. I recently looked what it would take to integrate Articulate into an existing website I built, and it was mostly straightforward, with one exception. It seems Articulate makes use of a custom model, and I'm unsure if I could make use of my existing templates with that model. An article here claims it is possible, but I've yet to try it myself.


Photo Credits


Here are some resources you can refer to if you'd like to do your own research:

Of course, you can use the comments section below for any specific questions you may have.

Nicholas Westby

Nicholas is on Twitter as