Warning: file_put_contents(): Only 0 of 8322 bytes written, possibly out of free disk space in system/classes/filecache.php line 154
Warning: file_put_contents(): Only 0 of 303 bytes written, possibly out of free disk space in system/classes/filecache.php line 157
CMS Key Components - RedAlt

I've been considering lately the key components of a certain kind of content management system. I've been conceiving something simple for boutique content management, something that allows a developer/themer to easily erect a simple site to the specifications of a client but is simple for the client to maintain, so that the developer can walk away from routine maintenance until something specifically warrants those skills.

The primary issue I see with software that functions like a CMS, like WordPress or Drupal or Habari, is that they aren't aimed quite directly enough at this market, which has very specific needs that don't include many of the other capabilities that these systems have.

Off the cuff, here are some thoughts:

Database Layer

I'm seeing more leaning away from relational databases. While I think that there is still benefit for a CMS to have these capabilities, it's probably enough to have a simpler database layer, rather than a full-on relational system in the back-end.

I've been thinking of a scheme that uses a simple database structure, like Amazon's SimpleDB, which could be abstracted up to something relational like MySQL or SQlite.

URL Dispatcher

Pretty URLs are not only commonplace, they're expected. One of the useful things that a front controller will allow you to do is dynamically route incoming URLs to specific pages, and pass additional arguments to those dynamic pages. The URL is the physical structure of the dynamic site, if it can be said to have such a thing at all.

Something that people don't seem to grasp about CMSes is that while it's possible to completely mirror the logical structure of a site with the URL setting, it's also possible to have the two be completely different things. Keeping these thing in sync can simplify the system. Perhaps it's worthwhile to marry these two, with an option of relocating the URL for any individual page.


Menus are the logic structure of the site. While the URLs are the physical locations of the pages, the menus help you get to those pages.

I've seen even "simple" sites have multiple levels of navigation without seeming to cumbersome. There needs to be a way to have multiple menu sets for site organization, and also a way for administrative users to access all oft he pages in the site. It's not practical to have to type in any page's URL to locate it in the site.

The typical way to do this is to produce a tree structure. Either there would be a separate tree for each menu, or each menu would be one of the root elements in the main tree. Whichever the element, no page on the site would be inaccessible via the configured menus.


Having some method to output content is essential to the production of a site. Pages may need to be displayed in different ways. If the basic accepted unit of display is a page, and not a "chunk of content", then the templating becomes fairly simple to tie exclusively to a single page.

One important thing to consider about templates in this system is that they should be easy for a designer to produce directly.

Those are some preliminary ideas. I'm not sure if this is going anywhere or just speculative. But I'm thinking about it right now.


Some of this actually makes me think of MindTouch's DekiWiki. I'm not sure how simple its theme or database layers are, but it's pretty simple to use, produces obvious URLs that mirror the site structure, and tends to seem fairly nifty.

Were it not for the mono behind it, I'd be a little more excited -- though I've used DekiWiki successfully.