It makes a lot of sense, when building a corporate website or intranet, to construct a content management system that enables users to update the words and pictures on the site. The logic is simple: instead of requiring those writing the words to have HTML skills (and running the risk of them mistyping a tag and breaking the entire page), you simply let them type the words and then use an automated mechanism to pull those words into an HTML template before sending them to a browser.
So what do you have to do to build your own CMS?
The first thing you need to do in order to implement a CMS is to decide what the pages will look like. This doesn't mean the graphical impact, but the various sections of text, pictures, links to other places and the like.
Each page of a simple site might comprise a header, a couple of paragraphs of text (each with a photo) and a footer. More complicated sites might have a number of different types of page, each with its own particular selection of content. Because the structure of your database depends to a great extent on the content structure, you need to get a grip on this information on day one – otherwise you'll spend your life retro-fitting bits and retraining your staff on the new things that appear daily or weekly in the CMS screens.
You'll also want to think about how you want to control access to your system. An obvious way to go is to have the concept of users and groups – it's a system many people can relate to as it's the way that operating systems like Windows and Unix work. Don't just implement this approach for the sake of it, though – after all, the Windows and Unix user/group mechanism is a useful, general-purpose system. As you're building a CMS to fit your organisation's particular needs, don't be afraid to clear your mind of preconceptions and consider whether there's a better way to do it in the context of your company.
Once you've decided the basic structure and the access control mechanism, you can think about putting the database together. You'll need tables for users and pages, and you'll probably want to consider whether to include rich media items such as graphics and video clips in the database or as disk files. The larger the media items, the more likely you are to decide to store them on disk and simply refer to them from the database (so the file is on the disk but there's a unique identifier, perhaps some information such as resolution and colour depth, and almost certainly descriptive text and/or a caption in the database).
Always, always use a style sheet to define the key styles for your site. Never, ever use in-line tags (the sight of tags in any page is enough to strike terror into the heart of whoever's tasked with changing the look-and-feel of your site later) because there's no excuse for doing so. If you define your heading styles, foreground and background colours, link styles and such like in a central place, it means that if the design changes later, a single modification will instantly be reflected across the whole site.
At some point you'll have to get down and dirty with the look and feel of the site. At this stage it won't necessarily be the colours, font sizes and such like, but you'll certainly want to consider the basic structure. The majority of sites use HTML tables to define the basic structure: a typical starting point is to have a header bar across the top for logos and adverts, a small bar down the left full of buttons representing the major sections, a main pane on the right for the content of the currently-selected section, and a footer on the bottom for things like a copyright message or the company address. Your site may differ, but the majority don't diverge all that far from this basic structure.
Why do you need this? Simple: because you're going to be pulling the content through a template, you need to be able to define that template. You should always try to have as much of the content as is reasonable represented as static HTML – the header, navigation bar and footer are often completely unchanging, so why build them on the fly. Use server-side includes and whatever other trickery your chosen Web server platform gives you to let your page-building scripts pull in these various lumps of HTML from static files.
Decide before you get going what your corporate standards will be. By this we mean stuff like how a date and/or time is represented, the format of usernames for the CMS, and such like. Build centralised, reusable functions in a shared library that you can refer to from wherever you wish (I always have functions called prettyDate and prettyTime for writing dates and times, for instance).
Once you have all of the above ingredients, you can put together your page-building scripts. Many sites have just the one script – it's called something like buildpage.asp and you pass it the ID of the page you want it to generate for you – while those with a selection of different page templates may have one script per template. This script can easily become unwieldy, so as you're writing it, ask yourself whether some of the functionality you're putting together is sufficient reusable that it can live in your central function library. Structure it sensibly and comment it to death, because this one script will probably be the single most complicated one in your site.
CMS user interface
Probably the last thing you'll develop is the set of forms that the users will exploit for adding, entering and deleting their content. Although you may write some of the GUI bits concurrently with earlier sections, nine times out of ten they're the last to be finished, because until you've got everything else working, although the users will be able to edit content, they won't be able to actually see the end result. Make sure, then, that the admin interfaces get done before the content interfaces – the users can be setting up access privileges, uploading rich media and so on long before you have your page script(s) done, so make sure they're able to do this work concurrently with your development effort.
With the best will in the world, you'll never absolutely finish building a CMS. Tastes and corporate requirements change, and there's every chance that you'll be doing modifications sooner rather than later. Bear two key principles in mind, then. First, make sure that when you're writing the CMS, you consider the most obvious changes people will want to make, and centralise their configuration (as we said with stuff like stylesheets and common template items).
Lastly, and most importantly, remember that you're (a) the techie and (b) the bottleneck. Your CMS is designed to enable non-technical content editors to edit their content, so make sure that you build it such that it's the editorial staff, and not you, that make the changes. After all, you wouldn't expect your users to have to ask Microsoft to turn their heading blue and underline it, would you?