Last time, I talked about how to get information about the current document type from a controller, or a view in, How To Get The Current Page In Umbraco 7.  Today I'm going to go over how to get data from other document types.

Getting Information About Another Page

Let's say you want to link to the search page from the header.  You could use this snippet of code:

  var currentNode = Umbraco.TypedContent(101);

In this snippet, I have hard coded the Id of the search page in the code.  For anyone who is new to CMS development, this is a terrible idea and will give you no ends up bugs and deployment problems in your production environment.  Let's say a content editor wants to delete the search page and create a new one, without updating your code, checking it in and deploying it (all tasks involving a developer) they won't be able to do it.  Instead when you link to other pages you want to do it either by filtering a result set, or by getting the data from the CMS. I'm going to cover both approaches, but I'll start with filtering first.

Filtering Results

In a lot of situations, you may want to get one off pages, say a 'Search Results' document type, or a contact us document type.  These pages will probably live under your homepage.  Getting a reference to the homepage is easy, we can use (see How To Get The Home Page In Umbraco? for more info).


One approach to resolving the issue to dynamically getting a reference to a page, is to simply look for the children under the home page for the document type you care about, so:

            IPublishedContent currentNode = Umbraco.TypedContent(CurrentPage.Id);
            var page = currentNode.Children.FirstOrDefault(x => x.DocumentTypeAlias == "umbTextPage");

If your page doesn't live under the homepage, then you could use this snippet:

           var nodes = umbraco.uQuery.GetNodesByType("umbTextPage");
            if (nodes.Any())
                IPublishedContent node = Umbraco.TypedContent(nodes.First().Id);

Both of these snippets are better than hard-coding the ID.  In this code snippet, nothing is tied to a single Id.  A content editor can now add a new search page in the back-end, test it, delete the old one and the code will just magically update without any developer intervention.  Brilliant? The downside of this code is that we've hard coded the document types alias in both.  Granted the document alias is a lot less likely to change, but there is also another approach.

The Settings Document Type

A settings page is a document type that is used solely as a container for all of your website's global settings.  This approach abstracts the need for any sort of hard coding of pages to an Id or a document alias in your templates.  The benefit of this approach is that instead of having to duplicate code all over your codebase to look-up pages, you load the container page, get the setting/link you care about and off you go. If a content editor wants to create a completely new search page using a completely different document type, they can update the setting page property and the website will just update without the need to get a developer involved at all. Using a template or document type as a settings container is a common pattern amongst any CMS build.  To give you a quick idea, in your settings document type, go to the 'Generic Properties' tab, and click 'Add New Properties' umbraco_usitebuilder_defining_type Call your field whatever you want and set the 'Type' to a content picker.  Now, when you create an instance of your 'Settings Document Type', the content editor can set the page to whatever they want. Umbraco_Settings_document_type_property Now if you use this code:

           IPublishedContent currentNode = Umbraco.TypedContent(CurrentPage.Id);
            var settingsPage = currentNode.Children.FirstOrDefault(x => x.DocumentTypeAlias == "SettingsPage");
            var property = settingsPage.GetProperty("SearchPage");

            var id = property.Value;
            var searchPAge = Umbraco.TypedContent(id);

You can get access to the search page without having to hard-code anything. If you are like me, you may be looking at this code and thinking but this still breaks the separation of concerns in several ways.  First, the "SettingsPage" alias is still hard-coded.  If you want to get rid of this, you can add a content picker property on your home page and then get the setting page this route. The second issue is that we've hard-coded the "SearchPage" property.  There are several ways to get over this and I'll cover the different approaches in another tutorial. One of the more common approaches would be to define your document types in code, using uSiteBuilder.  More information can be found here.  Although this isn't the only option.


In today's guide we've covered the different ways of getting data about commonly used pages within your project.  There are several approaches you can take.  One, hard code the Id or the document type alias name in your code.  This is considered bad practice and will make your website hard to maintain in the future. The better approach is to either dynamically search for pages, using some of the API called discussed.  Or the best approach is to create a settings document type to abstract all your properties away.  Using something like uSiteBuider will give the code more flexibility but I'll cover that in more detail later.