Where Should Sitecore Page Content Live?

I recently started a thread in the Sitecore MVP forum concerning the best place store page content. I was overwhelmed by the responses. Around 25 MVP's contributed to the thread and I'd like to thank everyone who got involved. In this post I'll summarise the key discussion points.

It started as follows:

Do you think there's a better way to handle the storage of page content items? By page content items I mean fragments of content that make up a page and are not intended for reuse elsewhere. We store all "page fragment" items outside of the home node. We do this so this to preserve the structure of the site tree. A user looking in the tree knows that more or less every item under the home node represents a page in the site.

I know other companies take a different approach. They put the content items in a folder under under the page. Users know that whenever they see that folder (usually a different icon to other folders), then it contains content from the item above. I'm not personally keen on this approach, but it still keeps the tree relatively free of clutter.

So I was wondering...

Do you take a different approach to the one's I've mentioned

Is Sitecore actively thinking about ways to improve this?

The responses were diverse, but there were several of common themes.

Different Levels of Page Content

Everybody agreed that there should not be a single storage location for all page content. The general consensus was that there are at least 3 types of page content:

Belonging to a single page
Belonging to a single site
Global

There were variations on this structure but they generally related to specific customer requirements. Several people pointed out that a rendering's 'Datasource Location' field can accept multiple, pipe-separated items and that provides the ideal way to allow user to decide which level to store their content at.

Handling Page Specific Content

This was my real point of interest when I started the discussion. As I suspected there were two main schools of thought. In Dan Cruickshank's words, "it comes down the to spirit/vision of the architecture".

1. Under the page item

This was clearly the most popular approach. It typically involves creating special folder beneath each page item that contains the data items that belong to it. The datasource locations for components are set relative to the page, so they always point to the right place. Additionally, the folder can be styled in such a way that de-emphasizes it or marks it as different from "page items". Mike Skutta and others even recommended hiding the page content folder completely.

Features of this approach include:

An obvious link between content and the page it belongs to - easy for users to understand
Content items inherit the security/permissions of the page item.
Data integrity - If you delete the page item, the associated page-specific content also gets deleted.

2. Outside of the site

This typically involves storing page content in an orderly fashion in one or more folders somewhere outside the home node. As an extension to this idea, Kamruz Jaman and others mentioned techniques involving a "folder structure auto created to match the tree structure".

Features of this approach include:

A clean site tree that closely matches the structure of the site.
Leans more towards the idea that no content is truly "page specific".

3. Another Opinion

One final opinion regarding the placement of page specific content was "Is the content typically baked into the items? Then don't fragment; instead, put it as a field on an item". Only one person mentioned this, but I think it's a very valid point and shouldn't be disregarded.

Conclusion

This is the kind of topic that starts wars, so I was pleased to get so much constructive feedback. Regardless of their views, people gave reasoned arguments. Many people pointed out that there is no right answer. As Nathanial Mann put it, "the decision should really be with the client. See how they want to work."

This post has been an extremely simplified account of all the opinions expressed. If you have any other views to contribute to the discussion, please leave a comment below.

Sitecore Skills

Search This Blog