Archive for Umbraco

Tips on Beginning with Umbraco

I recently wrote an email to a colleague talking about some points in Umbraco, so I wanted to include some of that here.

There are five main pieces to understand about Umbraco:

• Document Types (held in the database)
• Macros (information is held in the database, but they live in usercontrols)
• Fields (held in the database)
• Templates (found in the masterpages directory)
• Pages (held in the database)

A page is what you would expect – a page that can be created in the CMS (in the Content section, right-click and Create). When you create a page, it has to be a certain document type. A document type can have one or more templates that can be used with it (the user has a choice) and different fields that can be filled out to be used on the front-end (text, images, etc).

In a template, you can choose which fields are displayed in the html (see areas like <umbraco:Item Field="text" stripParagraph="true" runat="server"></umbraco:Item> and [#text]).

Macros are really just custom user controls that can come in a variety of forms, for example a custom .Net control and can be added to a template like this:

<umbraco:Macro Alias="MyWidget" runat="server" PassedValue="[#value]" SomethingElseToPass="true"></umbraco:Macro>

These function as normal custom user controls (code-behind, etc). To get Umbraco to pass values (like “value”), you need to add that information about the macro under the Development section.

The database structure is not very clear, and I generally try to avoid it so I don’t mess things up. Another note is that Umbraco cannot be run in a virtual directory, so to do development, you need to set it as your root website.

So, in short, a Page has a Document Type, which gives a user a set of Templates to choose from and Fields to fill out, and the Template determines how those Fields are displayed and if/what Macros are used.

2 comments

What Six Months Using Umbraco Has Taught Me

For a client, I’ve been using Umbraco as a CMS for them and I wanted to chronicle some of the things I learned about it that were not obvious when I first started using it.

1. Umbraco cannot be run in a virtual directory.

This definitely becomes obvious after trying to install it, but was certainly the first hiccup I had with Umbraco. Certainly not a deal-breaker, and when combining that with Helicon Tech’s ISAPI_Rewrite, ended up not being a problem in the slightest.

2. Umbraco’s document/database structure is non-obvious.

I definitely think the engineers over there are bright and did it the right way – it was just a more complex and abstract system than I was initially expecting. I don’t think it’s something they need to work on changing, but it was another hiccup I went through when I first started using Umbraco.

3. Umbraco creates a cache of pages when they are published.

When a page is called in Umbraco, most of the result is served directly from a cached XML file. Certainly was a great call performance-wise and makes sense, but it was not something I realized when I first set out with Umbraco.

4. Umbraco is simply incredibly powerful.

While all of the above might seem like I have reservations about Umbraco. In fact, quite the opposite. Sure, there were bumps in the road as I went along, but in the end, I came out liking Umbraco more and more as I got to know it better and use it more. It’s incredibly powerful and useful, from the template creation to embedding macros. Making changes and updates is far easier than I would have imagined and I cannot thank the Umbraco team enough.

3 comments