Mindless Philosophy






Umbraco Document Types Explained in 60 Seconds.

by Darren Street

Created on: Monday October 7, 2013

Comment on this post

It seems many people get totally confused with Umbraco Document Types insofar as which properties to create and where. The powerful inheritance features of Umbraco mean that clever arrangements equates to a really flexible content hierarchy. This equates to less downtime and happier customers.

Document Types

One rule of thumb to consider is that generic properties should be higher in the hierarchy than specific ones, which seems kind of counter intuitive. To visualise it, think of the content tree turned on its head for Document Types.

This means that properties that you create that need to be written once (for example a copyright notice) should be placed on a document type well down in the hierarchy that has no subordinates. Conversely, generic properties that could be applied to each page of content, should be right at the top of the document type hierarchy.

So let’s put some meat on the bones to give you a better understanding

I always start an Umbraco website with a node called:

Base Document Type

This is the top root node in the document type tree. Every page of content will inherit its properties. This is typically how I would configure the node.

[Create a New Tab called "Advanced Settings" and assign a sort order of 99]

[Create the following properties and assign to the Advanced Settings tab]

1) hideFromNavigation       True/False

2) umbracoRedirect             Content Picker

3) umbracoInternalRedirectId         Content Picker

4) umbracoUrlName            Textstring

5) umbracoUrlAlias               Textstring

6) umbracoNaviHide            True/False

7) umbracoSitemapHide    True/False

Most of the properties wire up existing methods built into Umbraco, such as an invisible (non 402) redirect et al. Google the rest for more information. So every page of content can have a different Title or be redirected if required.



Next I create two subordinate nodes under the Base Document Type called:

 Create Website Document Type

 Base Page Document Type

The Create Website document type doesn’t have an HTML  template associated with it, but acts as a repository for  website default values. The top page node of the website is typically associated with this document type.

In my Create website document type I have three tabs:

[Settings]

[Navigation]

[Social Media]

In the Settings  tab I have the following properties configured:

1) Site Name

2) AddressSingleLine

3) AddressMultiLine

4) Telephone

5) Email

6) Copyright

7) Registration

8) MetaDescription



In the Navigation tab I have the following properties configured:

1) HeaderNav

2) FooterNav

(these are configured to bespoke Ultimate Picker controls linked to a Razor script to show specific content pages)

In the Social Media tab I have the following properties configured:

1) FacebookURL

2) GoogleURL

3) TwitterURL

4) LinkedinURL

These properties are configured at the home node on the Content hierarchy. If these fields are included in a top level template with the attribute Recursive=”True” applied, these will filter down to all subordinate page and can be overwritten on a page by page basis if required.

The Base Page Document Type has two tabs:

[CSS]

[Scripts]

These are mapped to placeholder s in the core template so that CSS and Scripts can be added to content on a page by page basis.

In a nutshell


So what we have setup are the fundamentals of any new website. The “Create Website”  Document Type stores data at the root content level, and is mapped to a top level template, perhaps one that has the code for headers, footers and core navigation items.

The “Base Page” Document Type has properties about the page and any aliases employed, or where it should be linked to etc.

I would also suggest creating two further document types as subordinates of the Base Page Document Type. These are:

Landing Page – To store specific properties associated with a home and/or landing page.

Standard Page – To store generic properties of all the other content in your website.

Of course these are suggestions, and you can handle your business mapping appropriate to your situation. The standard page document type typically holds little, perhaps a Header Title and is reliant on subordinate document types to flesh out the different types of content, such as contact page, search or products pages.

 All these subordinate document types share the Standard Page template. This makes it extremely easy to handle specific CSS and JavaScript.  Additionally as each of these content pages are direct descendants of the Base Page Document Type, all content pages have “Advanced Settings”, “Scripts” and “CSS“ tabs.

Each new content page will inherit all the values further up the content tree unless specifically overwritten. Additionally styling and scripts needn’t be applied at the page template level slowing up content not needing it.

Sorry I know this post has been way longer than 30 seconds but get this right and your Umbraco website will be flexible and easy to modify.  

0 comments





Have your say


Sorry this post is no longer accepting comments.