What is a “Page Based” CMS?
By Deane Barker | August 27, 2012 | 3 Comments
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.
Comments
-
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.
-
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.
-
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..