Not Another Content Management System

Written: December 26th 2009

When I started this website I did so because I was in need of a project. I was coming to the end of 365 days of photography and needed something else to focus on. So, instead of throwing up a WordPress or Habari install and spending my time theming I decided to build the system myself.

As it wasn't intended for public consumption it didn't need to be all signing or dancing, or even particularly extendable, it just needed to do what I though I would need it to. The basics.

So I put together a basic request handler, a way to save content and produce different types of content, some taxonomy controls and I was ready to publish.

With this site live I moved on to the next project, rebuilding photospots, and it made sense to use the same platform. I was already familiar with it and with some extra user management, flickr integration and geolocation classes I could quite easily turn it to running a membership driven site.

In doing that though I found I needed to update a lot of the original code. It didn't need to change, just handle some extra situations. So I went ahead and updated it.

So what do you do when you have two different versions of the same basic platform running? I figured my next project should be to combine the two and produce something that was a little more extensible. And that's where I'm at now.

Writing your content management system

Writing your own content management system (using the plain English definition) is a fascinating business. When you work with WordPress or Habari most of the work has been done for you; you just need to figure out how to extend it for your needs and invariably you come up with cool things that the software could do.

You also find your own gripes. Not OOP enough, too bloated, too complicated, It doesn't matter what the gripes are, there are people with opinions on both sides, they are invariably based on your own view and uses of the software.

When you start to build your own you start to think on an entirely new level. You need to start thinking about architecture, about consistency, about speed, practicality, extensibility and so much more.

One of the most interesting aspects is that there are so many ways to achieve the same thing and lots of reasons for doing things one way or another. Here's a good example:

A thread on WP Hackers last week was discussing methods for dealing with metadata for content items. As my system was built to use multiple content types by default this got me thinking about whether the way I had gone about implementing this feature was the most effective.

The model I used for storing the data was this one:

The gist of this model is that the standardised information about each item (type, name, created date, etc) is stored in one table, and all the data fields that are type specific (e.g. an image for photoblog posts) are stored in the details table in key / value fields.

This is easiy to implement and, as it doesn't require any changes to the database structure to deal with new types, is also easy to maintain.

It does however have its problems. First, it stores far more data than is needed because, instead of a single column of values it stores the name of the key every time a value is saved. This also makes it slower to query. It also means you have no control over the data types stored. They will always be stored as a string.

The key issue with it though is that it can make it hard to do even fairly simply queries. Take the situation where you want to return all the records where value A is less than X and more than Y and value B is less than Z. It is a simple enough query normally, but I couldn't say quite how to do it with SQL using this model.

So what are the alternatives?

The first is to modify the database in one direction; i.e. to add columns. When a new post type is added, new columns are added to the post (or the details table). Any columns not used by a particular type will contain null values when not used.

I don't like this option as it adds columns that may be entirely unnecessary for most of the content, and makes column changes to all of the data each time one type is changed. It feels as though it might have performance issues as well, but I'm not sure on that.

The next option is to add a new table for each post type.

This option feels much neater, but is likely to involve more code to manage it. The first option makes adding extra content a trivial matter which anyone can do. Not dissimilar to the custom fields option in WordPress. If you need a new option just add it. Adding a new column to a table to do that is a much bigger deal, so you may end up not only with a table for each type but also a generic details table as well.

The option you choose depends on what you want the system to do, or not do, whether speed or extensibility is more important, how much control you want to leave to the users, and so on.

It is these sorts of questions and decisions which using WordPress or Habari takes out of your consciousness and is exactly why writing your own CMS is so interesting. Right now I am leaning toward the third option, rather than the first but there are always reasons to change my mind.

There is also something very satisfying about typing in a URL and seeing a plugin serve up custom pages when you started with a blank file and a head full of ideas.

I don't know whether my system will or should ever be ready for public consumption; I will make it open source, and it will almost certainly be stored in a public respository; but that isn't really the point. There was something that didn't work for me when I was using WordPress. I can't say or sure what it was, but it seems to have been resolved by using something I've written myself. Long may that continue.

---

Feedback

Add new comment

Name

Email

Web Address

Is ice "hot" or "cold" (usually)

Subscribe to coments by email?

Say your piece