There are some advantages to a database driven content management system (CMS) like PostNuke.  It’s nice to have the majority of the content in a single file (database) that can be easily backed up.  Having the database also makes it much easier to support a Web-based article entry mechanism.  I can visit my PostNuke powered site from any Web browser to post updates.  Another benefit is the ease with which I can change the site design.  Most of this is possible without a database, but it’s much more difficult.  But using a database has its disadvantages, too.  With a pure HTML site I have a mirror of the contents on my local computer, giving me a very good off-site backup.  With the database approach, I have to download the database myself (inconvenient) or depend on my hosting provider’s backups (risky).  With the database I’m also at the mercy of the CMS software.  Although all the information is in the database, getting it out in a usable form can be very difficult.  I wonder if it’s possible and reasonable to store most of the content in flat files on the Web server and use a database for indexing, classification, and perhaps some caching.

PostNuke also has what I consider a design flaw:  non-database site content (images in particular, and any static pages) are stored in folders within the program’s directory hierarchy.  For example, topic images are stored in /modules/topics/images and static html pages are stored in /modules/Static_Docs/data.  The /modules/topics and /modules/Static_Docs directories hold program code.  Mixing program code and application data like this makes it difficult to find the data, and also forces backup programs to back up unchanging program code.  I’ve run into the same problem with all too many Windows programs that install in the \Program Files directory and store their data in subdirectories.  Microsoft and most reasonable Windows development shops have reformed and now are storing their data within the Application Data directory structure, which makes it very easy to locate and backup user information.  Unix and Linux systems have been doing this for years, of course:  all user-specific program data is stored in the user’s home directory.  I wonder if the PostNuke development team would consider storing program data in a separate directory.  Guess I’ll hop over there and suggest it.

I spent a large part of the last 36 hours downloading PostNuke, installing it on my Web site, and then trying to make it do what I wanted it to do.  This was a big mistake, not because of the software quality, but because what PostNuke does and what I want done are two different things.  PostNuke is a content management system for Web sites.  It’s geared more towards news or blogging than to generalized content management.  At least, that’s what it appears to me.  I installed it here mostly because I want to make Random Notes more blog-like, and because I want the ability to add entries over the Web rather than by modifying the HTML file here and uploading it.  PostNuke looks like it will do the trick, but the conversion is not going to be a weekend job.

PostNuke is very good software.  Download, installation, and basic configuration were simple and painless, and worked flawlessly.  I was able to add articles to my site within an hour of starting the installation.  That includes time to upload everything to the Web server.  After that, though, things got more difficult for two reasons.  First, I was trying to fit my old site design into PostNuke’s blog-oriented mentality and second, the PostNuke documentation isn’t very detailed.  It’s a good reference guide and there are some good installation tutorials, but I haven’t yet run across a good discussion of the relationships among Sections, Categories, and Topics or other ways to organize files or articles on the site.

I did download a third party PostNuke module called Static_Docs, which I thought would help me incorporate my static pages into the PostNuke site.  Static_Docs wouldn’t install, though, because it expects the mySQL tables to have the “nuke_” prefix, but I used a different prefix when I installed PostNuke.  I’m sure I could have changed the SQL script that updates the tables, but by that time I had determined that the migration was going to take a while.  So I deleted the database and reverted to my old site design.

I think I’m going to get Apache, PHP, mySQL, and whatever else is required running on my Mandrake system here.  I’ll install PostNuke there and experiment.  I’ll either get my site running, or I’ll determine that PostNuke won’t do what I want done.