One of the common implementation patterns I see is the notion of unique "Page Types" or pages as first class citizens. By default Sitecore doesn't have a notion of "Page Types", I've always taken this as a not so subtle hint that we shouldn't be creating "Page Types". Many of my biggest pet peeves when diving into a content tree or code base is a direct result of modeling sites as a set of wrote pages. Modeling page types introduces a lot of content smell. What is content smell you ask? Well it's just like code smell, except worse because your content editors have to deal with it. It makes managing content quirky, inconsistent, and unpredictable.
Optional Or Unused Fields On The Context Item
This is quite possibly the most egregious offender that you will find, and sometimes I even do it. However, it should be avoided at all costs. More likely than not the context item is already filled with all kinds of meta data fields, so the last thing it needs is half a dozen more fields thrown onto it for things like hero rotators or callouts. To make things worse, many times you will find people adding these fields directly to the context items data template instead of inheriting a common data template. This results in the same code being written multiple times, or some kind of Frankenstein resolver/repository pattern being implemented to handle which field to use based on the template. Not to mention, it's basically impossible to personalize a sublayout that is using the context item as its data source.
Page Types Running Wild
"Look How Robust Our Implementation Is We Have over 100 Page Types To Choose From"
A Sitecore Architect Building a Robust Data Model
Requirements change, page types don't. Chances are that if you end up having to support an implementation for any period of time past UAT you are going to have to make more than just a little tweak here and there. The entire point of buying a CMS, especially a high end enterprise CMS such as Sitecore, is to empower your content team with the tools to constantly evolve your organization's content. When you build page types you basically defeat the entire purpose of buying a modern CMS.
Liberate Your Content
So what is the alternative? Don't put content that is displayed on the body of the page on the context item. Implementing this model requires a certain mental discipline in how you think about what a web page is and at a minimum what every page on your site requires. So, what should be on your page template? Meta Data. Your page templates should describe the page. In practical terms that means the following:
- SEO & Open Graph fields
- Configuration fields for navigation, etc.
So now the logical question is, what do I do with all of my content? Where should that live? I find the page resource pattern works well for this. The page resource model is typically implemented by having an item that represents a resources folder inserted into the tree with every item that represents a page. When a rendering is placed on the page it is always data sourced to an item other than the context item. The datasource location is set to the items resource folder via something like "./_resources" in the datasource location field. You end up with something that looks like the content tree below.
When you break your pages into a collection of single purpose renderings and pull the fields that support these renderings off of your context item you empower your content team to create meaningful content variations. You allow them to handle edge cases that would require data template changes that would have a widespread effect on your content architecture.
Once you start building your pages in this manner, you will realize that your development workload has been cut down significantly. There is only one problem - you just pushed all of your labor savings onto your content team, as they now have to manually build out every page. Now your content team has to manually build out every page. At first they may be in awe of the free form utopia you have built them, but soon they will get tired of having to map yet another Main Body content field or Page Title. Also, your IA team or content guardian will most likely have a heart attack when they see your summer intern expressing his creative ambitions with stacked carousels and marque text. Good websites have a logical content structure with repeated conventions and themes. Implementing Sitecore in this way removes the safety rails provided by Page Templates and insert options.
Creating the Illusion of Structure
What are some of the techniques we can employ to create the illusion of structure without losing the free form glory of our abstraction?
Premapped Branch Templates
One way of avoiding true Page Templates is by creating Branch Templates. Branch Templates allow us enforce insert options, default content structures, and mapping renderings that represent common IA patterns. Now your content team can still think in terms of Page Types, but you don't have to develop in terms of page types. You can create new "Page Types" without deploying code. Creating new "Page Types" in the middle of a demo is a neat party trick guaranteed to earn good will with your customers. The only major shortcoming of this approach is that once you insert your branch template into the content tree your renderings' data sources will still point to the the child item of the branch template. This is most commonly handled by remapping the data sources to the content of the newly inserted item's resource folder.
Place Holder Settings
Placeholder settings are an absolute essential if you use this approach.
Now that all of the content is no longer on your context item, some type of custom search indexing strategy has to be implemented to index the data sources of your renderings' as part of the page. There is a lot out there on how to do this, and I will be writing a followup on how to do this as well.
This approach has served me well and allows you to do a lot with very little in the way of code and data template architecture. The major trade-offs are that you have to keep your content team in Experience Editor, and everything has to be built to be Experience Editor friendly. Some clients aren't going to want this, and in that case I would actually recommend staying away from this model or at least implementing it to a lesser degree.