Sitecore is a complex piece of software by any measure. This series attempts to explore, demystify, and shine a light on some of the complexities involved in deploying Sitecore sites into an existing (and operational) Sitecore instance where source code is contributed by multiple parties.

Item tidiness is not something that is restricted to multi-agency deployments in Sitecore. A consistent item naming and structure can make the difference between a project being a success or unmanageable ball of mud.

A key thing to keep in mind is that the item structure is for the client not the developers. What makes sense to a developer might not be quite so intuitive for a content manager. It is the content managers who will be working with the content tree well into the future.

Sometimes we don't have the luxury of deciding the layout of the items, decisions on item structure, for better or worse may have already been made. As tempting as it might be to restructure the content to match your regular way of working, there be dragons!

The size of the project will inform the approach that needs to be taken, the larger the project the more thought that needs to be put into how the items and templates will ultimately be structured.

It is generally expected that an incoming agency will adhere to the patterns and structure already in place, so long as said structure does not violate best practice or make the content managers job more difficult than it needs to be.

Here are a few factors to keep in mind when planning the structure of the Sitecore tree.

Think global, act local

Global, local item structure

Sitecore instances are often owned or managed by a higher level of management than the one you are deploying a site for, it may be a parent company or simply you are creating a site for a brand of the company. This needs to be reflected in the structure of the items.

Sitecore items should form a hierarchy that matches the entity that is deploying the site. If you are building a sub brand site of a brand that is owned by a parent entity, this should be reflected.

"But I am only building one site", I hear you say, that may be true however the Sitecore instance may be in use for the next ten years and many more brand sites and micro-sites may be built. Sitecore item structure should reflect this possible future need, if not the tree can easily become an unmanageable mess.

Not just content

The hierarchy should also extend to the non content areas of the tree such as the media library, templates, system and layouts. This means a developer can initially browse the content tree for any site then instinctively know where to find things in the other less obvious areas of the tree.

Configuration items

Murphey's law of CMS's states; "If something has been hard coded then it is guaranteed that, that is the first thing that absolutely must be edited". It is important to anticipate any configuration or setting value that could change for any reason. These items should be centralized in a 'configuration' area of the website tree. This turns what may be an annoying change request to a simple content management job.

There is an inverse to this approach however, if there are too many obscure 'developer' related configuration settings made available to the content manager then this section becomes confusing and unusable to all but the most advanced content managers. Additionally creating complex configuration values that if entered incorrectly cause outages or break pages can easily make the site brittle and unpredictable. A balance needs to be struck between configurability, stability and usability.

Reference data

Reference data

In days of old a Sitecore instance would have a single item for each page with fields for each of the areas content would appear on the page. Nowadays due to the requirements of infinite configurability and the need to support advance XDB functions such as A/B testing and personalisation (OK not really that advanced), page items are a shadow of their former selves. Fields that once resided in the page item now for the most part belong to the modules that follow the data source pattern. But that is the subject for a post of its own.

The references that I am talking about here are the items that are to be shared amongst multiple pages, this information should not reside on an individual page. These items should sit at a higher level than the website but within the 'local' structure as defined in the Think global, act local section.

Other than display references this same patter applies for business domain items. These are items that reflect things that represents the clients products or services (or in the support of them). Structuring these items outside the main website affords greater flexibility when using these items as data sources for different modules.

The main takeout of this is that structure matters, care and consideration should be put into how the items will be structured. The structure that you put forward will likely be followed (especially if it is enforced) for a long time to come. If the items are a mess to start with this problem will only be magnified as time goes on.

Check out the other posts in this series.

The next article in the series 'Pack your things' is coming along soon.