Open and Closed Content Management Re-visited

By Deane Barker on November 27, 2005

I spent some time over the weeked with two major open source content management systems. I’m not going to mention names, since I don’t want to start a flame war, but they’re both very popular, have big communities behind them, and there’s a good chance you’ve heard of them.

They’re both really, really good at the concept of a “page.” They’re phenomenal at displaying and categorizing these “pages.” They have titles, previews, bodies, keywords, etc. If you have nothing but “pages,” then you’re money with either of them.

It’s when you move “past the page” that things really fall apart. (Yes, I’m on this bandwagon again...)

I’m toying with a moderately complicated data model for a project I’m considering. This model requires three custom “objects” – conceptual things, each with fields other than title, preview, and body. Some of the fields could potentially be multiple – they could have more than one value.

Additionally, the model requires linking between the three objects – foreign key stuff in relational terms. A property on one of the objects, for example, needs to be a reference to one of the other objects.

Both of the systems I played with were completely unable to do any of this out of the box. I kept digging around, trying to find what I needed, and discovered – to my horror – that I had to start writing “extensions.” This means rolling my own database tables, input forms, etc. It got pretty ridiculous, pretty quickly.

Both of these systems had large libraries of pre-built extensions from their respective communities. What struck me is that there were extensions for purely content-based problems.

For instance, one of them had a downloable extension for “movie reviews.” Someone wrote some custom content object to store movie reviews, and you had to download it and install it.

Now, in my mind, a movie review is pure content, and a CMS should be able to handle this out of the box. You shouldn’t have to write code to support a new content type. An extension should be reserved to extend the system beyond core content management – into, say, CRM or a shopping cart or something.

If you have a system that you claim is a general content management system, then I should be able to think up new content types on the fly, explain them to the system, have all administration forms and screens generated automatically, and be able to arbitrarily link them to other objects – all without writing a single line of code (aside from template/display code). Am I asking too much here?

Yes, there are specialized systems. Blogging systems are just meant to blog, so anything beyond a blog post is just a bonus. And systems like Big Medium come right out and say that they’re “article management systems,” so I’m cool with that.

What open-source systems do what I want? I know of one. (Curiously, I can think of three commercial systems off the top of my head that do this as well. Is this such a high-end feature that it’s usually reserved for paying customers?)

In the end, however, the two systems of which I speak are both very successful and appear to be thriving. Other people seem to be doing fine with them, so maybe I’m just a snob? Or a wuss?

And it’s also worth saying that these are free systems to which I haven’t contributed a line of code, so perhaps I should just shut my mouth until I’m willing to pony up a class file or two.

Comments (3)

Rick says:

Respecting the “code of silence” invoked for the two CMS systems... Its killing me :)

Since Deane and I have talked about this issue offline, I’m kind of surprised that I’m tossing a comment in here at all, but I’ve used both (and implemented a few others for clients) as well as having built my own primitive CMS (in Cold Fusion 4.5, no less! Talk about a limiting experience! Talk about finding creative ways around hosting issues and security issues!).

To do some of the specific things being considered in the data model presented, I was able to think of a way or two to make the back end accomodate my wishes, but I knew it would not be an elegant solution at the time I tossed it off, and I know that we, as a team, want clean code, easily understood and amazingly simple, and above all, elegant from a coding standpoint (no wasted anything, no hacks, and no kludgeware!)

I like free, and will continue to support both (actually, three with the fork) CMS’s – and the one that Deane favors may be the best one out there for the money – but somewhere down the line, who knows? Deane – want to write a CMS in Ruby? :)

Anonymous says:

Deane – want to write a CMS in Ruby?

I was thinking the other day that I’m surprised we haven’t seen a big push for a Rails CMS. Someone has to be doing something out there with one. I wonder when it will hit the scene.

But, what’s interesting with Rails is that it’s so easy to write stuff, that maybe they don’t even bother because Rails is already a CMS, you just have to tell it that. See this post:

Rails Blurs the Lines

Doug says:

There are some Rails CMS efforts. Here is one that appears to be gaining speed.