This is a post I’ve been meaning to make for a long time. However, an informal presentation of the awesome Doodlekit last night at KCRUG and a site Scotty showed me yesterday reminded of the quagmire we’re in.

The Problem

If you need to build a website for yourself or for a company, often the default answer is “You need a Content Management System (CMS)!” The problem with this assumption is multi-fold:

1. Do we really know what it means to have a CMS?
2. Do we know how our content will be structured?
3. Do we know our audience and their needs?
4. Do we have a preferred way of working? (a.k.a “workflow”)
5. Are we managing web pages or something else entirely?

To tackle this problem, we first need to define what we mean by Content Management System, and then break it up into its varieties.
h2. Reductio ad absurdum

A Content Management System is — you guessed it — a system for managing content.

Ok, as the header suggests, that’s a bit ridiculous, even almost circular in logic. With this definition, any one of these things is a CMS:

• Web-publishing software
• Email client
• A shared file-server
• An FTP client
• My computer’s file system
• A Relational Database
• A filing cabinet
• The pile of papers on my desk
• The cobweb in the corner of my office

Refinement

In order to put an adequate scope on the definition, we need to define what each of the constituent terms mean, otherwise our discussion could be “full of sound and fury, signifying nothing.”

Defining and scoping content

Put simply, content means information. As shown in the previous section, this information could be represented in any form, but really information only exists in our brains; that is, information is the result of observing and interpreting the world around us. To keep in-scope with our topic, we are going to limit our definition to information that can be stored, manipulated, and transmitted on or via a digital electronic device such as a computer, or more simply, digital information. This scoped definition excludes the filing cabinet, pile of papers and our beloved cobweb.

Defining and scoping managing/management

The word “manage” or “management” implies the organization and coordination of resources. Thus, the “management” aspect of a CMS should provide representations or interpretations of the digital information that reveals relationships and properties of that information, i.e. metadata, and (perhaps) the contents of the digital information. In other words, our content management system must have a way of organizing and manipulating content that humans can interact with.

With this scope and explication, we really haven’t eliminated any more from the list above.

Defining and scoping system

This is the hardest aspect of our term to define, partly because its meaning is tied up with “management”. However, I take it as an indication that large aspects of the process of managing content will be automated, that is, handled by the computer.

Again, we still cannot eliminate any more from our list. Why? The remaining choices differ in at least these respects:

• The type of content managed
• The method of interaction with the system
• The way information is organized and manipulated
• The scope and method of distribution of content
• The degree of automation

If we limit our choices to those with a high degree of automation and information distributed via the Web, we are left with only Web-publishing systems.

Before we go on

Contributing to the confusion over CMS software is the unfortunate use of the term as a buzzword. In fact, I’d venture to say that this is the core of the problem. By labeling software as a CMS, one is able to easily sell it to business and marketing types who couldn’t care less whether it is blogging software, a community portal, or a document-workflow automation tool.

Since I should really get back to making my clients happy, I’ll leave you to wait for Part 2 where we will discuss the many different types of CMS software out there.

One should be careful when using Rails' acts_as_list macro. I was reimplementing the Radiant "reorder" extension (mostly to simplify it and make it compatible with "shards") for DP when I discovered some strange problems. My reordering controller actions took this format:

def move_higher
  @page = Page.find(params[:id])
  @page.move_higher
  redirect_to page_index
end

But apparently, while my tests didn't show any errors in reordering things, in certain circumstances in production mode I would end up messing it up and get two items with the same position value. This would make it near-impossible to move them in any direction.

However, a member of the team had also run into the issue when using other AR macros, and the problem had to do with scoping. Of course, the Page model has the acts_as_tree macro already applied. The solution, it seems, is to (re-)load all of the models in the same scope before executing the positioning action:

def move_higher
  @page = Page.find(params[:id])
  @page.parent.reload.children.reload
  @page.move_higher
  redirect_to page_index
end

Or more tersely,

@page.parent(true).children(true)

(Incidentally, I have to use the former because I override some of those associations in other extensions.) I hope this prevents you from running into the same problem!