What is a “Page Based” CMS?

By Deane Barker on August 27, 2012

We hear a lot about a various content management systems being described as “page based.”  This term usually comes from people who think this is bad.

“Page based,” for the record, refers to a CMS where the main content object is…wait for it…a page.  You add a new page to the system, you organize pages, you manage pages.

A non-page-based CMS (what would that even be called – a content-based CMS?) works with more generic concepts of “content.”  So the core manageable object is a “content object,” which doesn’t necessarily equate to a page.

I get a little confused about this distinction, because I think the difference is less about architecture and more about implementation.

What makes the core content object of a CMS a “page”?  EPiServer calls them “pages,” sure, but look at eZ publish – they’re just “nodes.”  Drupal has “nodes” too.  Ektron has “content objects.”

So, even though they don’t call them pages, are these systems page-based?  Why?

I think I’ve boiled it down to a litmus test: upon creation, does the core content object automatically get an addressable URL?  If it does, then that would be a page – pretty much by definition – no matter what someone calls it.

Reversing that paradigm, can you remove the auto-generation of a URL and say your CMS is not page-based?

EPiServer did exactly this – they had a way of doing this before (you could create a page as a “Link Only” page), but they formally introduced the concept of a “Container Page,” which is a Page Type (content type, essentially) with no rendering template.  No template means no URL.  No URL means no page.

These pages still take up “URL space” in the form of an ancestral segment for pages below them, but you can’t address the page.  Any attempt to call it directly ends up with a 404.

So, is this page-based now?  I don’t think so, and I guess I never did before.  Not in the sense that “page-based” is a detriment in any way.

The concept of a “page” in most systems is just semantics.  In EPiServer, it’s called a page, but it may as well be called “generic object with properties.”  The fact that it results in a URL-addressable page is both incidental and preventable, if you don’t want it.  We’ve done EPiServer installs with a bunch of “pages” that you couldn’t address directly.  In this sense, they were just generic content objects.

The same is true of lots of systems.  I’ve personally done the same with Ektron and eZ publish, and I have to think that most systems will allow you to do this in either a supported way via or some mild templating code.

(When we do commenting systems in EPiServer, we do them exactly this way.  Each comment is stored as a page.  You just can’t navigate to it, and it only exists in service of it’s parent.  If someone, somehow tries to hit a comment directly, we can either 404 them, or redirect to the parent blog post with a bookmark in the URL to the specific comment they were trying to get to.)

Given that, I don’t understand the “page based” and “non-paged-based” dichotomy.  It feels forced and increasingly irrelevant to me.

Gadgetopia
What Links Here

Comments

  1. To me a page-based Cms is focused on creating and managing pages, as opposed to creating and managing content. But it’s not a yes or no classification. There are different degrees of how “page-based” a cms is, IMO.

    As you mention, there are many grey areas in this, but I don’t think that if a piece of content automatically gets a URL when created is a good way to determine which cms’ are page-based. For example all content in Webnodes get’s a unique url, but Webnodes is far from a page based cms.

    In my mind whether a cms is page based or not is closely related to content modeling capabilities and how content is structured in the cms. To me a page-based cms has traded content modeling flexibility for simplicity.

    Content modeling capabilities play a big role in determining how much a cms can be used for in addition to publishing pages.

  2. Sorry, but if every content object in WebNodes gets a URL, then I can tell you that the majority of people I have talked to about this topic would call it a “page based CMS.”

    But, in the end, I go back to my original point — who cares? Page based or not, I think this has little effect on the underlying capabilities or competence of the system.

  3. If you should care if a cms is page-based or not depends on the definition of what a page-based cms is. If it’s whether each content object has a URL or not, then I agree that it’s a useless moniker. But if you use the definition I gave above, I think it’s a useful way to classify cms’.

    It’s of course just one of many aspects that customers should evaluate a cms on, but I think it’s one of the most important factors if a company needs a complex content model and/or is dependent on content reuse in multiple channels..

  4. Addressable URLs (and associated templates) are only half the story — the other half is the enforced hierarchy of page-based systems.

    I have several idealistic objections to hierarchical page-based systems:

    1. In a given information architecture, page hierarchies are often totally arbitrary (especially on marketing websites), so it doesn’t make sense to cement content items into place by tethering them to parent/child relationships. Those items should be floating freely and able to be called upon wherever the context demands them (both automatically and manually). The page-based systems I’ve worked with allow for hacks and workarounds to create container references from one place in the hierarchy to another, but it’s an inelegant solution for a problem that doesn’t need to exist. (You then need to manage your container references in addition to your content!!).

    2. Page-based systems encourage content editors to create vast amounts of poorly organised and deeply nested content. In an ideal world all content would be properly modelled before being created, but in reality the marketing department will go wild with the tools you give them, leading to…

    3. Lack of future-proofing. Ending up with 1000’s of ‘pages’ that should have been properly specified as discrete content items creates a situation where it’s extremely difficult to modernise a website because every content item becomes indistinguishable from all the others.

    By focussing on creating strong relationships between content items, the content hierarchy becomes unnecessary and can be removed (from the back end) — this leaves you free to experiment with different front end information architectures and survive large scale redesigns. I suppose this is possible too in page-based systems, but there it seems to be standard behaviour to directly couple the front end presentation to the back end page hierarchy, which in my opinion is a terrible error.

  5. I believe that there is one important reason to distinguish between a “page-based” CMS versus a “node-based” (or “free-floating-content-based” or whatever you want to call it): these are two different tools, each of which is better suited for certain tasks. Understanding the task at hand and being able to choose the best tools for those tasks is an important thing we developers must do for our clients.

    I personally am a huge proponent of the Concrete5 CMS, which is most definitely “page-based” (although they don’t use that term to describe themselves). To me, this is a great thing for certain kinds of sites — specifically smaller marketing sites. The reason for this (in my opinion) has to do with the editing UI. Non-technical people who’s job is not “content manager” or “content strategist” have a very hard time understanding the more advanced concepts of non-page-based CMS’s, because the editing UI is conceptually and visually different from the way the site looks on the front-end. These non-technical people (e.g. small- to medium-sized businesses that don’t have a “content team”) have a mental model of a website being a bunch of pages in their browser that they can click around on and navigate just like an end-user. They do not think of their website as a database of content that is displayed in a myriad of ways via inserting into a template. So for these situations the “page-based” CMS is much easier to use because the program model matches the mental model (see http://www.joelonsoftware.com/uibook/chapters/fog0000000058.html for an explanation of this important UI concept).

    For larger organizations, or for companies whose actual product is the content, then I think the “non-page-based” CMS is better suited, because there you have people whose primary job is to manage this content, and there are often workflows and approval steps and re-purposing, and embedded/shared content all over the place. This is where it makes more sense (in my opinion) to treat content as distinct entities that are not tied to one page. These people need more powerful tools that can be used in more flexible ways, and they’re willing to deal with more complication to achieve that.

    But in my line of work — building marketing sites for small- to medium-sized businesses (which I believe is the majority of the work smaller developers and designers are doing) — I’ve found that 95% of sites fall into the former category where a “page-based” CMS is the right tool for the job. And there is a very obvious difference when training these clients on their new website — the page-based CMS (usually Concrete5 in my case) makes SO much more sense to them and they feel much more in control of their site… which makes us (the developers) look better and also cuts down immensely in support costs.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.