Ahh yes, the golden oldies -- this time by Tower of Power . But I did decide to contradict this advice, that is, I am going to upgrade Moodle in the middle of a semester. What has pushed me to this extremity?
- The version of Moodle we're using right now is from late August (Moodle 1.8.2+) and I'm getting unprecedented complaints about it's slowness. There's a known bug/inefficiency in the code which results in a hammering of the database. Something Needs to Be Done -- ie update production to 1.8.3.
- Taking advantage of this to apply a hack to edit resource without a preview (in Patches/Hacks).
- Add in the presistent request to download assignments as Zip file (as above).
- Exploit the hiatus to jazz up the incredibly dull theme we're currently using so that faculty don't have to use the Chameleon theme with it's own issues.
I've started with some housekeeping and am now ready to apply and test the download assignment submissions as Zip .
Two factors have made me more confident that I can pull this off:
- the support and experience of the moodle community, and in particular, the folks on this Eduspaces community.
- I have found that Linux in the form of Ubuntu has been so tractable -- what few problems I've encountered I've been able to quickly suss out. [My Ubuntu experience] This is in contrast to the grind of keeping OS X server going -- eg the so-called "performance cache"
But given the hassles I've had with the accursed ULPGC assignment and AWyatt's recent discovery that Upload and Review hack can bite back, why bother?
- The sting can be taken out by thoroughly documenting what you're doing. For me, the combination of my Tiddlywikis concerned with server stuff and Moodle issues help me to keep the details recorded, while this blog serves as a reminder "what was I thinking of ..." and do other folks think I'm totally bonkers?
- The functionality of the good hacks should eventually get incorporated into the Moodle codebase.
- Because I've adopted the upgrade policy of moving to a new database with a major upgrade I can selectively apply old hacks and carefully determine what modules cause problems.
The unfortunate reality is that Moodle is undergoing major internal evolution which I don't see finishing soon. The first major architectural change was the introduction of UTF-8 into the 1.6 database schema. That proved a major hurdle for many modules written for 1.5 but it had to be done. The 1.7/1.8 leap was roles and capabilities which changed a bunch of database tables and the way that teachers/students are accessed via the database. That broke many modules especially those that made direct calls to the database. I suspect that version 2.0 will again slaughter many modules but those that survive will undoubtedly be the fittest :-).
So my question is, can we take a (superficial) look at a plugin module we want to use and say "this looks like it's upgrade proof"? I'm thinking that there may be some metric or procedure that could be used to "rate the code" in terms of fitness to survive a database upgrade.
In the meantime my new policy will be to keep faculty aware that if they use a hack such as 'zip download' the assignment may well not be backed up and hence may not be available in the restored course.
Keywords: moodle
Comments
We're not seeing the performance issues, so we don't have a hugely compelling reason to upgrade now. The IE profile fix is useful, but I can do that without upgrading to 1.8.3. Given the number of things I have on my plate, I think we'll take the more leisurely upgrade path and shoot for 1.8.3 for the Dec/Jan break, with Moodle 1.8.3 being our stable version for Spring 2008. Then (hopefully) we can start testing Moodle 1.9. for Fall 2008.
Even if 2.0 comes out this summer (which seems unlikely, given the pace of 1.9). I think we'd likely wait a good long while ti implement it. You're absolutely right that 1.9/2.0 represent a chance for third-party module breakage rivaling that we saw with 1.7/1.8 and Roles. The Gradebook changes alone will likely play havoc with any number of modules. :)
I'll second using a wiki to track your changes; I'm using Mediawiki (it's part of our larger IT department wiki) and my documentation there is proving invaluable, both for tracking my changes and sharing those changes with the community.
The hacks for the non-previewing of resources and mass file downloads look good; I'm going to have to try those out during our own move to 1.8.3. The Resource form is a colossal pain, particularly once they removed support for frames (which we slipped in, since without frames or the no-preview hack, that interface breaks). I like redirecting back to the course page after adding a resource because it serves as confirmation that the resource addition really did work (which I think is what they were trying to get at with the resource preview).
I was under the impression that performance issues were not backported to the 1.8.3 upgrade? I hope I am wrong! Especially since I have no idea where I got that information . . .
We are waiting until the end of the semester to do any upgrading regardless. I have already moved all my shared resources OFF the moodle server, and it appears that other faculty have similar work arounds so I think we can wait another month. After several years of watching LMS server stats, I have observed that the last third of the semester generally sees far less activity than the first third, so I am pretty sure the benefits gained are not worth the possible risks for upgrading.
>I was under the impression that performance issues were not backported to the 1.8.3 upgrade?
I'm not sure what you mean by this, but according to the CHANGES file for 1.8.3 the fixes that affected bugs afflicting our installation have indeed been incorporated.
Thanks for that bit of info. I still think we will wait until the semester break . . .
atw
Looks like confirmation of major performance increases in 1.8.3+!
http://moodle.org/mod/forum/discuss.php?d=83281