Content Management Software

The primary focus of the software is very clearly managing a personal weblog. There are some pretty powerful things in here, don't get me wrong, but there are an awful lot of hardcoded decisions by the programmer as well. These are things like forcing two 'adjectives' for every post — Music and Mood — rather than letting the blog-author specify a number of additional attributes when setting up the blog. It wouldn't be very hard, for example, to replace the 'Music' or 'Mood' templates with generic templates, so authors could have whatever they wanted as descriptors for each post. A blog about wines could have descriptors relating to vintages, grapes, vineyards, regions, etc, while one about food could have descriptors relating to ingredients, ethnicity, spiciness, carnivorous or vegetarian.

Possibly one of the worst things is the way dates are stored in the database. Not, as you would imagine, as a timestamp, but as a collection of strings with (and this is the stupidest thing) AM or PM specified. sure, this makes it easy for the programmer to patch up a defective entry later, but it means that you now require eight fields to store the posting time when it could be done easily with one. All Unix boxes have a counter of seconds since 1970, which functions as the system datestamp. This one counter specifies the posting time in UTC to the second, and is easily convertable to local time in Adis Adaba or whatever.

The data files are stored in a glob-delimited form ('Glob delimited' means that there's a non printing character which separates the various items of data) and this glob changes &emdash sometimes its the vertical bar character, sometimes it's a newline. The more logical choice of flat file storage would be an XML file, which is how my own Content Management System stores the rest of the site. The concept of splitting the body text with <br /> tags is inherently wrong as well. A paragraph is defined as something between <p>...</p> tags, not one lump of text with breaks scattered through it.

One aspect of the GM software which really annoyed me was that there are some components which are completely hardcoded and not changeable without editing the Perl code. Everything which is output to the HTML file should be definable by the user. My site is valid XHTML - I don't want someone else's stuff in there screwing up the validation.

There are many things which are excellent about GM - the simplicity of setting it up and the way it stores everything in flat files is good. The way it generates flat-files for the html is perfect for a site like mine where the content changes less often that the number of page-visits. If the content is changing more all the time, then of course a database backed site is ideal, but there is a risk of increasing the load times for each page. with my hourly hits going between 50 on average and 500 during the peak SARS traffic time, having the pages regenerated each time would have overloaded my server.

So, while I like GM enough to continue using it, I'm working an adapting it to use XML files for storage, better date storage, completely user-defined output and multiple generic descriptors. In fact, adapting it is the wrong phrase. 'Seeing how it does it, and then sorting out how to do it right ('right' being 'right in my particular context', of course). Just don't expect this to happen quickly, or even completely, or even to result in a product which would be useable by anyone except the author. I'm doing this to scratch a very specific itch.

And did I mention that the preview uses GM's own styles instead of the blog's styles? How chuffing useless is that?