Page Types.
Models? Patterns? ARRRRG!

In previous versions of Concrete we've kept the technical architecture for how pages are presented pretty simple. Every page is a single type. Each type has a PHP file that handles presentation, and a record in the CMS that defines default/shared blocks you want to always show up. When we build sites ourselves, this typically works pretty well for us.

Sadly, it tends to get out of control when other people start playing with it. Our developers tend to think of page types as functional, and aesthetic idiocyncries from section to section are handled in that presentation PHP. So if you have a page type of "Case Study" it's going to use the same template no matter where you put it in the site. If you have case studies both in your Product section and Services section, we would A: make the navigation block that renderes that primary nav handle how it looks, or B: add some logic to the template to do area specific presentation stuff based on where you are in the category tree.

A lot of the development shops we've partnered with in the past tend to think of page types as silos or areas of the site, not functional break outs. So Products and Services both get their own page type because they have different side bars. Now when you add a Case Study that was originally designed to show up in the Services area to the Products area, its gonna have the wrong header color. All of a sudden you end up with a ba-gillion page types to handle these scenarios, which basically defeats the whole point.

The resolution we seem to have come to is split the concept in two. In Concrete 5 you will have page types that map to what goes on a page. You will also have Themes that are presentation focused, and control where and how that content/functionality is presented. Themes will contain templates that map to page type names. Every theme must have at least one "default" template, which will be used for a page type if no specific file exists.

By splitting this in two this way we hope to handle more diverse situations in a more intuitive way for end developers/site owners – my only fear is introducing too many labels and leaving people wondering where their presentation layer is coming from.