So what is content management and how will it help you? When you start to develop content on a site, unless you want to be bogged down forever with HTML trivialities or resource sharing, you want to make it as painless and easy as possible.
You need a system that will eliminate the grunt work and let you focus on actual content. You need a system that will allow writers to easily submit articles, one that will let you proof and publish the articles, all without having to write a bunch of HTML. Enter automated content management.
Imagine a simple news site that two different writers update twice a day. Without any content management system, the writers would have to download the source code for the current page, add their news, re-upload the page, and then let the other writer know the page is updated so they won’t overwrite the changes.
For a larger site, such as Enfused.com or WDVL where news is updated at all hours of the day, and longer content is added on a semi-regular basis, this system will not work.
So What Are The Parts To A Good Content Management System?
- Allow writers to easily submit content
- Make sure a record is made of that submission
- Allow editors to easily proof, publish content
- Make sure content layout fits with current design
- You want to be able to do all this without having to mess with any HTML, and as easily as possible. There are definitely packages out there already that allow you to do such functions, and much more, such as Vignette’s Storyserver.
But this nifty little app can cost you in upwards of several hundred thousand dollars. That’s five zeroes we’re talking about. We’ll show you how to build the poor man’s system here.
Ready to dive in? Let’s find out how we’ll let the writers submit their content. Submission System
There are two ways to go for the submission system.
You can either let the writer write in his/her own choice of editors, or you can force them to use a web based form (with a textarea element) to submit their content.
Naturally, the first option would be a more robust choice (not to mention friendlier for your writers), but more difficult than the latter choice.
Either way, you’ll want to store this content somewhere, which usually means putting it in a file that resides on the server.
You may choose to store the content in a database instead of a file. While this will allow you to keep track of and perform database functions on the content more easily, if your content is long and/or you have a lot of content, your database can balloon to extraordinary proportions.
Not to mention that the articles will have to be generated dynamically when a visitor tries to view them, which adds more overhead to the server. We will use text files for simplicity’s sake in this article.
Should I Let The Writers Choose?
We’ll talk briefly about the first method of submission, that is, letting the writer choose his own medium. While this does seem like the best route to take, there are a few compatibility issues.
Firstly, chances are that your all writers may use different word processors, and no one will be able to read another person’s document. So unless you want to go out and buy licenses for all of the different editors people use, you’ll have to coordinate compatible versions.
The next issue is obvious – for people to be able to read articles online (ie web site visitors), the articles need to be in plain text format; Word Perfect, Lotus, MS Word, etc formats won’t work.
So you’ll have to convert the documents into plain text.Unless you know the binary file format of the document and some heavy programming, or a copy of the application is installed on the server, you’ll most likely not be able to get the actual text and/or images out of the document.
One solution is to require your writers to convert the documents into something you can manipulate first. Many popular word processors these days allow you to ‘export as html’ or ‘save as web page.’
This would be ideal, since such pages are straight text files and can easily be manipulated.
Or, you could simply have them write HTML or text files and submit those.If, however, none of the above options are feasible, you’ll have to resort to the second method, which is to make the writers submit the content through a web-based form.
The Back End
Before we actually start building the submission system, we’ll want to create the database backend.
The tables we’ll create will store important information about the content. Here’s a sample database structure for the submission system we’re creating:
|UID||Unique ID to keep track of records||Autonumber|
|Filename||The filename of the document||Text|
|Author||The name of the author||Text|
|Title||The title of the document. (Note: This is not the same as the filename.)||Text|
|Date||The date of the publishing/writing||Date/Time|
|Published||Is this document published (ie viewable to the general public?)||Boolean (Yes/No)|
You can obviously expand this with whatever you’d like, but this is a good framework to start us off.
We will use a wizard type interface here – that is, the user selects some options, hits the next button, selects some more options, hits next again, etc.
This will make things much easier to follow for the user, and much easier to debug for the developer. How do you design a wizard?
Simply follow these easy to munch on steps:
- Each step that we discuss below can be on a single page.
- Any forms on those pages (and there will be a lot) will point to the same page (action will be set to the same page the form is on).
- Put the script that processes the form somewhere on that page, preferrably at the top.
- After the script is through, and if it is successful, redirect the user to the next step.