Anatomy of a CMS – Part 2

Continued from Anatomy of a CMS – Part 1

When I left off last time I had a very rudimentary system in place which mostly involved editing a Microsoft Access database directly to update any data. Not only did the learning curve involved make collaboration a problem, but the system was also prone to other errors such as data corruption and more that are common when working directly with Access files and then copying them back and forth with an FTP client.

After about a year of this system I had learned enough and coded enough to put in place a better system. This system, known originally as Webedit, allowed a user to perform all the data manipulation from a web browser such as IE thereby eliminating having to access database files directly and also reducing the learning curve involved to add or update data. It did however pose a few new problems for me.

First, I had to choose a back-end database that would work with the ASP coding I was working in at the time (this was before the days of .NET). Microsoft Access was a solid choice, but it was also rather limiting and prone to frequent corruptions. On the other hand, it was easy to backup in that I had only to copy one file to whatever backup location I had decided on. In addition, it was also easier in that I didn’t have to add too much to the server in order to keep things running. At this point though the site was getting big enough that I had to move on to something cheap that would also be easy to maintain and would not be prone to the corruption issues. Really there were 2 choices at the time. Microsoft’s SQL server and MySQL. Now I can probably post full entries on the choice here alone, but to make it simple the price and features along with the community support lead me to the MySQL option.

Beyond the back-end I also had to decide how to manage data. How would I branch out to be able to manipulate such diverse data over the whole site with one system? Also, with so many areas to edit, how would I control who would edit what?

The answer to the first question has become the backbone of most of my CMS coding every since. I started by dividing each area into pages or modules that functioned as applications in themselves and could be added or removed at will. For instance, the code to update the job openings data was kept completely separate from the code to update the departmental directory. In addition, separate database tables allowed me to store this data in whatever format I needed and eliminated the need to redesign the site around the CMS and instead allowed for the development of a CMS based on a site.

As for the users, I had to develop a system in which users could log in and access only the data that pertained to them. In Webedit this was done through a simple login system in which I stored the user data in one table and used a separate table to map the user to the pages they had permission to. It worked pretty well. Users could now log in, work on select data, and update the site directly from their browser. Like all early systems however there was some limitations.

Early on logins and passwords were stored in plain-text format on the database allowing anyone access to data they shouldn’t have had. In addition, as it was my first time working with such code security against injection attacks or even someone coming along later and sitting down at the same computer was non-existent. Webedit was simply found in a directory off the main site and open to the world. Finally, although more data could be entered, a user still had to know html in order to enter images, links, or anything else into their data. Forms were pretty much a collection of input boxes and text areas which although they were effective for basic data entry, couldn’t really provide the character or detail needed for many types of data.

It took about 3 years to work out the kinks in Webedit, but by 2005 it was a rather solid system used by 1 or 2 of us to update a single website. In addition it grew to accept entries from the public via the main homepage and could even handle simple tasks such as email subscriptions to areas like jobs and similar functions. Not bad for a part-time coding project.

In 2004 I decided I wanted my own page in addition to the Aviation page. The catch is what would I use to update it? By this point there were a few CMS systems on the market, but I still didn’t like what they could do. Webedit was working well for my office, but how could I use it for a commercially hosted site with completely different architecture and less ability to secure items like the database and others? Also by this time my lack of security knowledge was starting to show. We were hacked a few times at work and some rather obscene spam was appearing in places it shouldn’t.

It was time for Webedit to receive a major overhaul. I needed not only more updated code, but as ASP was rather obsolete by this time I needed a new framework as well. Hence work began on a new CMS.

To be continued….