The Abcs Of Cms

Why Do Custom Design?

There are quite a few Content Management Systems available commercially, as shareware, and freeware, so why would you want to design a custom CMS? There are a couple of reasons:

1. The off-the-shelf CMS has a high learning curve for both the persons responsible for the maintenance of the system and the CMS user,
2. The off-the-shelf CMS does not fit all of your requirements even though its high-level of customizability should allow it,

3. The off-the-shelf CMS has either not enough features, or too many features to suit you. There is the expense, and that expense is either the retail price, or the cost of the customization, or both.

Custom content management can be approached like building an igloo, one piece at a time. Start with a solid foundation and you can build up from there.

Basic CMS Theory

Martin Burns' excellent article, Your Clients Need A Content Management System, goes into depth about CMS theory, providing valuable checklists and requirements for a CMS.

However, at the very heart of content management is a very basic premise, that there is content that needs to go through a review process (workflow) and then be published.

You can define content as anything needing to be published, photos, PDF files, spreadsheets, other items.

You can then define publishing as the presentation of content in the desired form, requiring templates.

Since content is controlled by a CMS which is separate from presentation you now have the option of delivering your content to multiple output formats. Content can be published to web sites, read over wireless PDAs, sent to printers with proper formatting, shared with publishing partners... your imagination - not to mention the user's imagination - will come up with new and innovative ways of using the content.

We will call the delivery vehicles "templates".

Workflow is the Starting Point

We're going to look at the life cycle of an article to demonstrate workflow and security levels.

• Article written and submitted to the approval process - (user level "Author");
• First Stop - Editing.
  
  Article edited for spelling, grammar, and may be checked for facts - (user level "Editor")
• Second Stop - Content Approval
  
  Is this article acceptable? If not, it is sent back to the original author along with recommendations for making the article acceptable. If it is acceptable it moves on to scheduling. - (user level "Approval")
• Third Stop - Scheduling
  
  Once the article is approved it is scheduled for release. It may also be scheduled for expiration - (user level "Scheduler")

Role-Based Security

This workflow gives us at least three levels of users, perhaps four if content approval is separate from scheduling (which we will assume for the sake of this project). They are:

1. Authors,
2. Editors,
3. Approvers,
4. Schedulers.

We will also add 'Administrators' to the user levels, which we will discuss later.

For this project we will use "inheritance" for our user levels. Starting at the top:

An Administrator can do everything Schedulers, Approvers, Editors, and Authors can do, plus other tasks (i.e. adding/deleting users, archive administration, etc.).

A Scheduler can do everything Approvers, Editors, and Authors can do, plus scheduling.

Inheritance is maintained throughout the CMS down through Authors. We will allow Authors to be able to edit their own articles and they will only be able to send the article up the ladder when they have completed the editing of their own article. This also allows an Author to enter partial articles into the system, coming back to complete them when time or resources permit them to.

Using your favorite database management tool create a database called "CMS"

CREATE DATABASE CMS;

Then create a users table within the database called "tblUser";

CREATE TABLE `tblUser` (
  `ID` int(4) NOT NULL auto_increment,
  `name` varchar(64) default NULL,
  `email` varchar(128) default NULL,
  `accesslevel` varchar(64) default 'author',
  `password` varchar(64) default NULL,
  PRIMARY KEY  (`ID`)
) ;

Now that you have a table (don’t forget the proper GRANTS) you can start registering users for the cms. They will automatically enter the system at the "author" level. You can create a PHP form page that will accept the information, do validation of the information, and insert the information to the database. It would be preferable to assign no user level at all, but rather to inform an administrator via e-mail that someone has registered. Then the administartor can grant the proper user level to the registrant. Even if the user level is set automatically to a default, the CMS administrator(s) need to be notified in the event that the user level needs to be changed for this user.

What's Next ?

In the next article in the series, we will cover logging in a user, presenting them with

appropriate navigation according to their user level, and setting up an

article table.