Conquer the five Heads of Kentico


David te Kloese

Did you know there are five ways to add something to the HEAD section of your Kentico pages. Most you'll be able to do directly from within the coziness of your Kentico admin interface! I'll explain each one and why to use them!

The Head section is mostly used for metadata, favicons, CSS links and Scripts (included or placed directly). But what is the best way to add your custom content. I'll talk about 5 ways of doing so and giving the pros and cons.
 

  1. Master page

Probably the easiest and mostly used. Can be find in the Pages module on the Master page tab of every template which is defined as being a Master page.

Content head section on masterpage template
Pros:

  • Easy to find
  • Possible to let non-developers edit or maintain the section


Cons:

  • This field is a content field and therefore only related to this specific master page. This means if you reuse this master page you'll need to manually copy this content. Unless you use staging or in an export package add the content pages itself this is hard to deploy.
  • You cant easily exclude this section from any page that inherit from this master page, and thus they will all get it.
  1. Template

In the Page templates module you'll find each template (master page or not) has a Header section. The data is saved in the template and used for all pages using it. You can decide if it needs to inherit this section from parent pages, but also if you want child pages to inherit this one.

Template header section

Pros:

  • Easy to maintain template specific content
  • Inheritance per template (or breaking it) can be configured
  • Can be easily deployed using import/export

Cons:

  • Out of the box not suitable to be maintained by non-developers
  • When used with multiple inheritance levels overview can become an issue
  • Harder to create exceptions per page when using the same template
  1. Web part

A lesser known way is to use a basic Kentico Web part which is present in Kentico by default. This Web part is called 'Head HTML Code'.


add HEAD HTML Webpart

Since its a web part you'll be able to use the default functionality a Web part gives. Like display name and behavior configurations.


Configure the HEAD HTML webpart

Web parts are placed on the design tab of a template and thus used on every page that uses this template.

Pros:

  • Easy to maintain template specific content
  • Easy to separate multiple functionalities on the same template
  • Can be easily deployed using import/export (Template)
  • Can be cloned to create a prefilled version of repetitive use

Cons:

  • Out of the box not suitable to be maintained by non-developers
  • When used a lot overview can become an issue
  • Harder to create exceptions per page or template
  1. Code

Since point 3 was a default Kentico Web part, this means you can view/copy/edit the code. Which when needed in your custom code can be directly placed there. You can find the Web part example code on the following path:

~/CMSWebParts/General/Headhtml.ascx.cs

but the code itself is pretty simple:

Head by code
I would advise to use this on a custom Web part and let the content itself be placed via a custom field manageable in Kentico. So don't place hard coded data here.

Pros:

  • Freedom for the developer of placement and management
  • Full code freedom for exceptions and inheritance
  • Easy to combine with custom Web parts, user controls or modules so no missing script/css dependency

Cons:

  • In some way must be maintained by a developer
  • usage 'hidden' in custom code so harder to get an overview
  1. PortalTemplate.aspx

When for some reason you need to be sure your code is placed at some exact order or in some exact way. If none of the above seemed to help, you could also go hardcore and update the Kentico Portal Template page. This is the base of the Kentico Portal pages. So don't break anything...

File on the following path:

~/CMSPages/PortalTemplate.aspx


Portal template head section
Same advise as point 4; let the content itself be placed via a custom field/setting manageable in Kentico. So don't place hard coded data here.

Pros:

  • Full Freedom for the developer of placement and management
  • Full code freedom for exceptions, inheritance and order

Cons:

  • In some way must be maintained by a developer
  • usage 'hidden' in custom code so harder to get an overview
  • If you break it you'll break everything
  • Extra hurdle when upgrading to a newer Kentico version

Wrap up

There is no wrong or right way. It all depends on your requirement. I usually end up with 2. Templates HEAD section and in some special cases 3. HTML Web parts. As long as you'll use it consistent throughout your project. This way not only you, but also the next developer on the project can find its way.