What is a “Page Based” CMS?

By Deane Barker

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.

This is item #75 in a sequence of 354 items.

You can use your left/right arrow keys to navigate