So why don't we just...

It's been a while since substantial changes were made to the website. Let me clarify that: Website development has not halted, minor updates happen from week-to-week to keep things running smoothly, but new features have not 'happened' for a while.

'New features for the website?' I hear you ask... A good while back (almost a year ago to be precise), I posted a list of things to add on this blog. Currently the most important big features are an overhaul of the IVRPA mailinglist(s) and forum, as well as an integrated chat system for our member chats.

At times people see the lack of new features to the site as reluctance on my part. In part, that is true... Adding new features to the site takes time, and I have only limited time available; the IVRPA is my 'baby', but I have so many more babies. But it is not just my stubbornness or lack of time that is stopping me from adding features to the site.

The single biggest reason why I don't 'just add feature X' (Drupal-minded readers may read that as 'module X') to the site is 'data integrity' and 'future proofness'. As you probably know by now, the site is build on an open source Content Management System named Drupal. Many, many developers around the globe work on Drupal, and many many features are available as reasonably stable 'modules' which could be plugged into the site. The problem is that it is always questionable what the future of these contributed modules is. Most of the modules stem from the needs of a single developer for a single site. Some of the modules may continue to grow along the Drupal 'core', but some are bound to wither and die. I want to make sure that we don't depend on such modules too much, because that could mean that part of our data would 'die' with the module.

A good example of the problem of future-proofing our data is the use of the 'Flexinode' module which manages posting gallery items, news items and behind the scenes constructs such as IVRPA sponsors. This contributed module is great, but it has been superceeded by something greater, in the form of 'CCK' (Content Construction Kit). To put it blundly, Flexinode has been abandoned (...) and has never been updated to Drupal 5.x, let alone to Drupal 6.x.

This means that as long as we're using Flexinode, we can not upgrade to a newer version of Drupal, even if that would have many benefits for other parts of the IVRPA site(s). Just dropping flexinode would mean loosing all our current 'gallery' data (also on the photokina and conference subsites), which is not an acceptable option for me. In the long run (hopefully 'this year'), the IVRPA site will migrate towards CCK. CCK is moving closer and closer to the Drupal 'core', so its future, and the future of our data, is safe.

Just so you know why I didn't set up the IVRPA site with CCK in the first place; when the site was being built in 2006, flexinode was a production-ready, and CCK was far from that; there was no way to upload images and generic files with CCK. Update: here are some pros and cons about flexinode and cck, dating back to a couple of months after the IVRPA site launched.

So I hope you can see that even though there are - for example - some chat related modules, I don't want to just jump in the deep end before I see where the current developments are going.

Update (mar 19): I have updated SPi-V dev from Drupal 4.7/Flexinode to Drupal 5/CCK. Now SPi-V dev is a whole lot simpler than the IVRPA sites, but at least its some practice...