Content Management System

Abbreviated to CMS. Wiki is one. ZopeApplicationServer, optionally with PloNe, is another. CollaborativePortalServer is another based on ZopeApplicationServer. Frontier and Manila are another related pair.

Context

Content is anything that an audience might be interested in: articles, reviews, recipes, book chapters, etc. This being the Web, in the context of CMSs we are mostly referring to online content.

Problem

Most online content is still written as HTML pages and uploaded via FTP. (The 'static site' model.) HTML pages are notoriously difficult to maintain in large numbers: hyperlinks that point to dead pages, common elements (headers, footers, navigation menus) that must be rewritten in all pages whenever you change some graphic or move stuff around, etc. At some point you find you're dealing almost exclusively with technical issues and no longer adding content; this results in a dead site. Another problem is that, if more than one person is contributing content, it must all be submitted to one Webmaster who formats it as HTML, uploads it to the site, and checks for broken links and suchlike; pretty soon that Webmaster has TooMuchToDo.

Solution

Implement software that lets you focus on content, and takes care of the boring tasks such as generating headers and footers, hyperlinking pages together, ensuring that the site has a consistent layout, and so on. Ideally the software has an HTTP interface so it can be used by more than one person, letting you distribute the task of managing content among many editors.

Resulting context

You have a clean separation between the technical issues and the ones related to content. You can distribute the job of maintaining the site among people with appropriate skills. Your site obeys OnceAndOnlyOnce: the visual layout is defined in one place (and only one), the actual content in another, the logic for displaying headers, footers and so on in a third.

New possibilities open up: e.g. specifying that some content is only to be published after a given date (April 1st for that funny article), but putting the content in the system well before that and letting the CMS take care of publishing the content when appropriate.

Your main problem is now that it takes more people to do the job that one used to do (at least two, a technical maintainer and one editor). You must also invest more effort in organizing your content and learning how to use the CMS.

The primary requirement of a CMS would be to make the task of managing any content which is to appear in a computer media publication (such as a Web site) a non-technical task; i.e. one that does not require a programmer to perform it, but a person such as an editor. I would define managing content as the task of choosing what content appears where, and when; this would be separate from actually creating the content.

In this context, application servers and other middleware systems do not qualify, nor do authoring systems. Systems which can be validly considered components of a CMS include presentation tools (such as an XSL engine or a caching engine), workflow tools, aggregation or syndication tools, and versioning tools. However, to qualify as a CMS a system should combine several of these components such that it conforms to the above criterion --- if you are an editor of a Web site that uses such a system, you use the system to publish content submitted to you by some author, and do not have to call on, say, a programmer or a support person to do so.

-- LaurentBossavit, A technical introduction to ProjectCanon

I would agree, and add that a good content management system should include dynamic and interactive content in this. Once a given piece of dynamic or interactive content has been developed, the site editors should be able to place it wherever they want it in their site, and configure it appropriately.

-- MalcolmCleaton

ThereAintNoJustice?. I have been playing with this idea for about a year, as a result of a friend who has an online journal, but does not want to use one of the online services for it. Now I find someone has done it....great for speed, but heck for NotReInventingTheWheel?. -- Pete Hardie

A list is at http://www.camworld.com/cms/ although many of these seem to require a lot of setting up work before benefits start kicking in (well of the freebies I looked at anyway) -- AndrewMcMeikan

So far, most of the comments here seem to be talking about what might be best called an offline CMS. It seems that people here (and people other places too) want a system that lets them generate and upload static HTML, without giving up flexible tools. While pretty much any CMS can do this with help from a tool like wget and perl, only one program supports this more natively. That is frontier from UserLand software. It has templates and was originally used for generating large static sites. Since then, a dynamic CMS name manila has been bolted on top.

"[Frontier] was originally used for generating large static sites" -- Not so, it was originally used as a post-HyperTalk proto-AppleTalk macro system for the MacOs, well before Mozilla. But I concur that it filled the CMS niche perfectly. ~SeanOleary

Zope also lets you ftp into it easy enough and makes for a handy tool when experimenting with changes in plain websites. ftp it in, then use the Web interface to cut-n-paste, reorganise edit etc, then ftp back out again once you're happy. You can even blissfully ignore all the fancy features Zope offers and it is still very useful if you look after static sites (I keep a couple of sites and various revisions this way). -- AndrewMcMeikan