Serendipity35

When I first learned about Moodle I was excited about an LMS that was written by educators, for educators. When I found out that it was already ported to FreeBSD (my server operating system of choice), I immediately installed it from the FreeBSD Ports collection. For reasons I've described in another post, I configured it to use PostgreSQL as a database backend, and I was off and running, moving my Open Source Unix Certification curriculum from my own web-based delivery system to Moodle in just a few hours of code sorcery.

The Moodle folks are diligent about development, patches and bugfixes and before I finished the first section of my course, Moodle 1.6 was released. The main feature from Moodle 1.6 I wanted to be able to use (I had been using Moodle 1.5.x) was the "Student View" feature --the ability for me, as teacher, to see the course assignments the same way that the students would see them without having to create a phantom student account that I had to use to login and see the courses and assignments from the student's perspective.

Of course, when one is upgrading (or just changing) software in a production environment, the first thing anyone should do is backup everything that might get touched in the upgrade process in case the unexpexted happens and the upgrade breaks the software. A major change between the 1.5 version of Moodle and the 1.6 version was the requirement that the database backend support Unicode (UTF-8) characters so that any selected language could be generated from a standard set of characters without having to store every variant alphabet the world's languages contain. I backed up my PostgreSQL Moodle database, backed up my Moodle 1.5 directory and began the upgrade process.

The Moodle documentation included a script and instructions to import the old non-unicode PostegeSQL database and I began to climb the upslope to an upgrade.

The shell commands for migrating the database from the command line were (I think) Linux specific and didn't work at all in the FreeBSD environment. While Linux is an open source player and buzzword, it is curious why the BSD platforms are often ignored in many (not just Moodle) program configurations. FreeBSD is among the most popular (and is often the most reliable) operating system in the world. After an entire day of hand editing SQL files (not fun even for the enthusiastic), I had a database that worked correctly with Moodle 1.6.1

In late summer, 2006, there were a couple of Moodle security advisories that encouraged administrators to upgrade from Moodle 1.6.x to 1.6.2, then 1.6.3. I downloaded the source archive for the Moodle 1.6.2 upgrade, dutifully backed-up everything in sight and ran the upgrade process from within Moodle. The upgrade script ran fine until it had to alter my database tables that contained "Hot-potatoes" quiz information. The script just stopped at that upgrade segment never to error out and never to continue. The database tables it did alter made the database unrunnable for the older Moodle 1.6.1 version and left the installation completely broken. A few hours (and buckets of sweat) later, I managed to roll everything back to Moodle 1.6.1, reinstall the older database and bring back online my older (but working) Moodle installation.

I swore off (and at) any more upgrades until I had both a break in my classes and some demonic possession that forced me back into the database abyss. But, on November 7th, 2006, Moodle released version 1.7, and on November 29th, FreeBSD published a compatible version in the FreeBSD Ports collection. I backed-up (again) anything that wasn't nailed down and let FreeBSD's automated (and very reliable) portupgrade process transport me to Moodle 1.7.

Portupgrade reported no errors and it looked like Moodle 1.7 was mine to keep, but after I logged in as the moodle administrator, every choice I clicked on returned an "incompatible configuraton error" in an ominous red box and a suggestion (and a link to) check Moodle's online documentation. The link I followed related to upgrading to Moodle 1.7 and wasn't too helpful. Staring at a completely broken Moodle 1.7, I deleted everything that had been installed or upgraded (except my backups) and just did a fresh new install of Moodle 1.7.

Success!

Moodle 1.7 handled the upgrade of my 1.6.1 database without error and I got my courses back and all the content they had, pre-upgrade, contained. My moment of joy was temporarily squashed when I checked my student's grades for the past courses and found out thay had no grades to report, but some hacking around inside of Moodle's configuration modules lead me to the new "roles" functions where I had to re-assign my enrolled students their roles as students. Had I read the version 1.7 administrator's documentation and new features ahead of time, I would have been saved that extra Angst.

Moodle 1.7 looks terrific. Now that I've recovered from scrambling up the slippery grade, I'm enthusiastic, again. But, I am afraid I might be in a minority position. I know a lot of system administrators who don't host or teach their own courses. And I'm not at all certain I'd have gone through this upgrade process if I didn't have my own course materials living inside (and delivered by) Moodle. I haven't looked in much detail at how much faculty re-training might be required to adequately support Moodle 1.7's new features, but it looks like the people who train the trainers have a lot of independent work to do before they can offer support for this release.

I hope that running the Moodle Marathon to version 2.0 will be a bit more downhill.