Monday, 14 June, 2004

Database driven CMS / PostNuke design flaw

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.