The source field on a template definition is a great and easy way to enhance your content editors experience.

With fields types such as a tree list, this can be used to restrict the content tree to the section that is relevant. e.g.

Adding a source property like this:

Will change how a tree list displays from this:

To this:

Multi-Site Solutions

The source field however is far more powerful than just pasting in a fixed path to an item. Rather than a static path you can use xpath to make the results based on a query, such as restricting options on a droplink by template type.

In a multi-site solution this is particularly useful, by restricting the options to the site that your content item is on.

With a fixed path the best we could do in the above example would be to set the restriction to the nearest folder that could access both, resulting in a restriction like this:

While this makes some improvement for the user, but not hugely and they can still select content from the wrong site.

By using an xpath query that utilizes the ancestor-or-self function with a template name, the restriction will dynamically be based on navigating up the content tree from the current item until the template is found and then showing items from it or in this example going back down to the home item.

Resulting in an output like the original example, but dynamically changing to be the correct items for where the current content item is located:

Templates are the building blocks for a Sitecore installation, they're amazingly flexible and with capabilities such as inheritance you can produce an elegant architecture, or alternatively a complete mess. Here's how I like to structure things:

Base Templates

First off I have a folder of base templates. These are the building blocks for all the fields that will end up in a component data source or an actual page via inheritance. By setting them up as a base template we can re-use the same field definition for things like headings, but more importantly it keeps them focused on a specific purpose rather including details of the entire eventual item.

One additional rule I have for base templates is that they should only contain one data section within them. This in turn helps keep them focused on a specific purpose.

Page Templates

Next we have pages. You guessed it, a page template is what a content editor will create an instance of when they make a page. It's responsibility is to bring together default presentation details, the set of fields on the page and insert options for the pages beneath it.

All fields are inherited from base templates and standard values are used to define the defaults for the page.

Additionally to make the CMS experience as easy as possible for the content editors an icon should be set so that a page type can be visually identifiable.

Component Templates

A component template is the equivalent of a page template but for data sources.

Like page templates all the fields are inherited from base templates and standard values are used to define the defaults for the page. An icon should also be set to make content types easily identifiable by content editors.

Folder Templates

Folder templates are often overlooked but they are an essential part of creating a decent user experience.

Folder templates are created to define the insert options for components and site settings rather than having them set on the site content tree.

Where relevant a folder template should also include itself as one of the insert options so that content editors can organise their content into sub-folders.

Parameter Templates

When a component needs some config to customise its look and feel that is not content, it can be better to use Rendering Parameters rather than a data source.

Site Setting Templates

A Site configuration template is useful to contain various global settings for a site. This could include things such as the Site Logo, Google Analytics account details etc. Settings should be segmented into logical sections that have been defined in Base Templates and then inherited.

It can also be useful to separate some settings into their own template item depending on the scenario of what the setting is for.

Group Into Folders

With each these template types created, you'll end up with a tree structure that looks something like this.

This is the third in a series of blog posts covering everything you should need to know for building a multilingual website in Sitecore.

Part 1 - Adding languages for a multilingual site
Part 2 - Translating text in your presentation

In the first two parts to this series I concentrated on how you can setup Sitecore to allow different language versions of content to be entered. In some instances though your content will contain fields which should remain the same across all language versions. This could be for product sku's, dimensions of an object or possibly image fields.

To make a field share it's values over multiple languages, in the template definition tick the shared checkbox against the field.

It's worth noting though that as well as making the field value the same across all languages, it will also be shared between all versions within the language.

Although the interface gives the impression that a field can be the default (versioned), unversioned, shared or unversioned and shared. The value of the unversioned checkbox actually become meaningless once shared has been ticked and there really are only 3 options; Versioned, Unversioned and Shared.