Sitecore Best Practices: Your information is the foundation of your website
With Sitecore your information is the foundation, making sure an installation starts off on the right foot will save time in the long run.
When developing a website based on the Sitecore CMS it is too easy to get into the swing of things and construct your solution using traditional website conventions. Thinking of data items as generic web pages with a bunch of controls that control what data is to be pulled from your database is likely to cause a great deal of pain when it comes to maintaining, or even implementing enhancements for your site.
If we are to use ASP.NET web forms as a point of reference; a data item can easily be treated as a basic web page; and the presentation components as user controls that control what data is to display on those pages, and where. If this is the approach you are taking to configure your Sitecore installation, it is a means to the end, but the short term gains of getting the solution up and running quickly will be lost when it comes to maintenance and enhancements.
When determining how your content is to be stored within Sitecore it is important to architect your information well and implement your architecture in such a way as to separate your data from your presentation.
Understand what Sitecore provides
In order to be able to develop an understanding on how to best approach the design and implementation of your Sitecore installation it is important to know what you have to work with. Some of the key aspects of Sitecore that you have at your disposal are:
- Hierarchical data storage
- Presentation Components
- Standard Values
- Insert Options
Hierarchical Data Storage
Sitecore stores your data in a hierarchical structure; using search and other APIs to provide relational features (West, 2013). In general it isn’t recommended to design your site around Sitecore, but it is recommended to take advantage of it where possible. This is primarily in reference to inheriting data/security from an Item’s ancestors or determining the default URL to an item.
Data in Sitecore is represented as much as possible as generic items; the structure of each item being defined by templates. Templates within Sitecore provide structure to the data that is being stored.
In most cases templates can be grouped into two different distinct types; data and presentation templates. When it comes to designing a template it is important to know what type of data should go into each type of template.
A data template defines the structure of the content being stored within Sitecore. It consists of sections that logically and visually group fields; each of which defines a value in the Item (West, 2013).
Sitecore is flexible in that a single data template can inherit from and expand on any number of other data templates. This gives the ability for any fields that are common across multiple types of data to be defined and configured within a single template that is then inherited (or shared) by all the data templates that require those fields.
Presentation templates are used in defining the structure of the parameters that can be assigned to a presentation component as they are added to an item’s presentation. The data stored within the structure of presentation templates should only be data used to control the presentation, not what should be presented.
Sitecore uses what it refers to as layouts, sub-layouts and renderings to present the information stored in a data item. Each component has access to:
- The item in the current context (the page item).
- The parameters applied to the component through the presentation configuration (these are the details specified by the presentation template assigned to the component).
- Optionally, a data source that usually indicates the item to render instead of using the item in the current context (the page item)
Presentation components don’t directly have access to the configuration of other components assigned to the same data item. This is why it is important not to have any content data on presentation templates.
Presentation components should be designed and built against a specific data template.
For each template it is possible to configure default values and presentation configurations for items on what is referred to as the template’s standard values. If a value isn’t set for a field directly against an item, then its value is a reflection of the standard values. The standard values inherit through base templates; meaning the standard value for a field comes from the field’s standard value in the base template, unless the inheriting item overrides that value (West, 2013). So, changes to the standard value for that field will be reflected by any item that doesn’t override the field.
Insert options define the types of items that can be inserted beneath existing types of items in different contexts (West, 2013). These don’t enforce, but help to guide the hierarchical structure of the data within Sitecore’s content tree.
Pulling it all together
When it comes to configuring an installation of Sitecore to meet your business’ requirements, as with many digital platforms, there are many ways the task can be tackled in order to get the same high level outcome. The decisions made during the design process; as well as the process taken to execute and adhere to the designs created; can determine how well the final solution can stand the test of time, and the level of difficulty that will be experienced when trying to enhance the solution after its release.
Create and use the necessary templates
Data item templates give structure to and between the data items stored within Sitecore’s content tree. The number of templates you will have within your Sitecore installation will depend on the complexity of the data set your site is working with.
Templates will need to be created for each of the different types of information that Sitecore will need to store for your business requirements; e.g. product, product category, store. Additionally templates will need to be created for the different page variations that are required within your site; e.g. home page, product listing page, category listing page, three-column page, two-column page.
Generally, if there are going to be more than 2 or 3 data items that will use the same configuration; in data fields and presentation; then it is worth while creating a new template. This provides the ability to maintain the common configuration between those items together, on the template.
Recently when I was working on adding an additional presentation device to an existing Sitecore installation I discovered that even though data templates had been created for the different types of content pages, there were a number that weren’t being used. On the surface it appeared as if the data items were making use of logical data templates, but when it came time to implement the new device presentation it was discovered that critical data specifying the product category and filter to be used for product listing was against the presentation component, and the data item was making use of a generic page template. In order to roll out the changes individual pages (100 or so) required configuration changes; this is time that could have been saved if the items were created using a handful of common templates.
Configure insert options
Once a decent set of good data templates have been built, it is important to then configure the insert options for each template. This will help to control the hierarchy of content within the content tree; and when a default presentation configuration is set on the template’s standard values it provides a quick means of creating new data items that will work out-of-the-box.
When a content editor goes to add a new data item, Sitecore provides a list of available data templates that are available in the context they are adding the item; this list is controlled via the parent item’s insert options.
If we go back to the example I used earlier with the lack in use of data templates; each sub-tree of content retained a matching hierarchical data structure as a sibling sub-tree. Presentation components on many ancestors were configured as if they were inheriting data used to filter the information displayed on the page, but as it turns out that wasn’t the case. It can be assumed a time consuming process of configuring, copying then re-configuring content items was undertaken to create the structure presented in the data. The way this data was implemented multiplied the effort it took to implement and roll out the additional device configuration.
If the insert options were configured; and data templates were constructed; the content editors would have been empowered to construct the required hierarchy without fear of there being a misconfiguration. Also, the time required to develop future enhancements would be minimised, reducing also the cost of development.
Develop presentation components to adapt to the item in context
All the content detailing what the item is about should be mapped to fields on the data template; which leaves the details on how the content is to be displayed up to the presentation components and their presentation templates. In this way, multiple components can be added to the presentation that all display a different aspect of the data.
Separating the data from the presentation also means you could have two different presentation components that display the same content from a particular type of data item, but in different ways. The presentation components can then be configured in such a way that content editors can swap them for each other, allowing the editor to decide on the best presentation of their data in the context of the current page.
In the scenario I discussed earlier, where there was critical information for the current page assigned directly to the presentation component, the ability to add additional components that adapt to the content assigned directly to that component is lost. If additional components were to be added to the presentation that required the same data configuration, we’ve instantly increased the complexity of maintaining the content for that given page.
Constructing a site in Sitecore is all about the information you intend on storing within it. Starting without taking any consideration to the information architecture can cause more problems then it is worth. This is especially the case if the only reason for jumping straight in is the short term gains of just getting a solution up and running.
Sitecore has a great number of features and aspects that, when configured well and taken advantage of, help to keep easy future maintenance and empower those who own the content to get on with making it available to the masses. When a configuration is lacking in an area, especially with the separation between content and presentation, the great flexibility and relative ease that comes with maintaining a Sitecore implementation can be lost.
Starting with a good foundation is always the key to success when it comes to projects. With Sitecore your information is the foundation, making sure an installation starts off on the right foot will save time in the long run.
West, John. 2013, Information Architecture with the Sitecore ASP.NET CMS. 17 May 2013. Sitecore Blog: @sitecorejohn Blog. [26 May 2014]
Ellison, Tim. 2014, Sitecore Rendering Parameters Part 1: How and why to use rendering parameters. 03 March 2014. Captech. [26 May 2014]