Because Umbraco is built on such a loosely coupled design, you, as the administrator and developer, are provided with an endless combination of variations for structuring your site. As a result, thinking about what your sitemap should look like before you dig in is extra important. As a general rule, try to design the first two to three levels of your site before you start building out your document types.
It's recommended that you use a sitemap, mindmap diagram, or similar tool when you're in the analysis phase of your project. Doing so enables you to relatively quickly create a hierarchical structure and start to visualize what your site will ultimately look like. A quick Google search can yield all sorts of options for you.
Although the flexibility of Umbraco is great, knowing what level of control you should provide to the site's editors is important. The following sections describe how you can limit and control this structure intimately, providing a user-friendly experience for the end user and a proper setup for search engine optimization (SEO) purposes.
To start, go over the interface used to maintain your document types. Navigate to the Settings section and click the Document Types node in the left pane. If you followed the installation steps outlined in Chapter 1, you should see several document types listed already, as shown in Figure 3-2. Figure 3-3 shows how the document type management section is made up of four tabs. These tabs are located in the right pane when you click a document type under the Document Types node. Table 3-1 provides a description of each tab and field.
To make your content tree look richer and more specific to your implementation, consider installing the FamFamFam icon set from the package repository (covered in Chapter 10). This set extends the basic list of icons provided as part of the installation and are made available to you in the Icon list mentioned in Table 3-1.
Creating a new document type takes just a few steps:
When creating your document type, start by creating the required tabs under the Tabs tab so that you can associate the properties to the correct tab under the Generic Properties tab later.
See how the Alias value was automatically concatenated to remove any spaces from the name? This is intentional, because it will be the value used to name these nodes in the XML cache and also how you will target the newly created document type later on in your XSLT and .NET macros.
PROPERTY NAME | PROPERTY DETAILS |
Press Release Content |
|
Press Contact Name |
|
Press Contact Phone |
|
Hide from menus? |
|
Several notes concerning these properties:
You have now created a document type with the necessary settings and properties. However, if you tried to add a press release to your site you would see no option to do so yet—other than adding the press release as a new root node to the content tree. Umbraco is set up this way so that various types of content can be restricted as to where it lives within the content tree. This feature is helpful for a number of reasons. The most notable and clear example is in the case of a press release. Chances are that the website you're working on will have different authors for different types of content. In the example here, a PR person may be dedicated to writing press releases. Wouldn't it be nice if you could restrict the type of content that he or she can create? Well now you can.
To complete the example, create a press release container where your PR person can post all the press releases as shown in these steps:
PROPERTY NAME | PROPERTY DETAILS |
Press Contact Name |
|
Press Contact Phone |
|
The reason you're recreating the same fields for this document type is because later on, when you work with templates in Chapter 4, you learn to recursively display the press contact name and phone number if none are entered for an individual press release.
Now you have a contained structure where only the Press Release document type nodes can be created under the Press Release Area, and nothing else. So, when your PR person logs in and sees the Press Releases node in the content tree, all he or she can add are press releases. To finish this setup, you must do one last thing, which is to allow the Press Release Area document type to be created under the Runway Homepage document type (so you can create the container for the PR person to access later). The steps involved in finishing up this setup are as follows:
Parent document types allow you to share fields among multiple different document types. In fact, the previous exercise could have been structured in this fashion to share the Press Contact Name and Press Contact Phone fields among the Press Release Area and Press Release document types, removing the requirement to re-add the same properties to multiple document types. In that case, however, doing it for two separate document types isn't too difficult. However, this section looks at another case where this functionality makes more sense.
You want to add additional content to your site in the form of events, news, and clients. All of these would have at the very least some page content, and as with other content nodes, you may also want to be able to hide them from the navigation. The Runway Textpage document type already contains these fields, so why not use that as your base?
The structure you create using parent document types has no bearing on the Allowed child nodetypes' functionality, which means that even though, for example, an Event document type is created under Runway Textpage, you still must allow the Event type under Runway Textpage, or whatever type Events can be added under, for it to work.
In the following exercise, you can see how leveraging the power of master document types to create additional ones saves you from duplicating common properties such as the ones covered earlier. Events can consist of many properties, but for the purposes of this example the properties in Table 3-4 will suffice.
Another prime example of using master document types is to add commonly used properties such as META tags, which can then be recursively displayed through the use of Umbraco tags (covered in Chapter 4).
PROPERTY NAME | PROPERTY DETAILS |
Event Summary | A short version of the full description of the event |
Body Text | The detailed description of the event |
Event Start Date/Time | The start date and time of the event |
Event End Date/Time | The end date and time of the event |
Hide from menu | The ability to hide the event from menus and other output through macros (covered in Chapter 5) |
Here are the steps for using master document types:
You cannot change the designation of master document types after the document type has been created. You must delete the document type and start over if you did not mean to assign a master. This is due to the enforced relationship of parent/child properties in the database.
The Generic Properties and Tabs tabs provide a reminder saying that you must edit master document type properties on the related master document type itself, as shown in Figure 3-9.
PROPERTY NAME | PROPERTY DETAILS |
Event Title |
|
Event Summary |
|
Event Start Date/Time |
|
Event End Date/Time |
|
So far, this is all theoretical as you have not seen the results of your careful planning and labor. Chapter 8 deals with creating content where all this work will come together. For now, Figure 3-10 shows a preview of what the content editing UI looks like. You can see the Content tab, just like in a Runway Textpage node, and the addition of the Event Details tab and associated fields.