As a developer of a number of plugins for Moodle, a couple of which have now been upgraded to work with Moodle 2.0, I'm wondering what is the cleanest upgrade path from Moodle 1.9 => 2.0, for the end user, and where I put any code that needs to be run during the transition?
As far as I can tell there are 4 possible ways around that the user could do the upgrade:
1. Install Moodle 2.0 versions of plugins, then upgrade core to Moodle 2.0 (I'm guessing this would be bad).
2. Install Moodle 2.0, install M2.0 versions of plugins, then (and only then) go to the 'Notifications' page to run the database / file storage upgrades (this could also be very messy - M2.0 plugins would be very broken until the upgrade was completed, maybe the upgrade code could also run in the wrong order and cause complications).
3. Install M2.0, go to notifications page, wait for upgrade to complete, install M2.0 plugins, go back to the notifications page (I'm guessing this is probably the safest option, so far).
4. Delete all contrib plugins, upgrade fully to M2.0, install new versions of all plugins (probably safest, but seems like a great way to lose all the data stored by those plugins).
Also, as stated above, how does my plugin detect that Moodle has just been upgraded to M2.0, so that I can move all the files into the new file system (along with and DB changes needed)? This is particularly an issue with my assignment plugin type (as I know they occasionally get left out in the API calls).
Good question! I would say that options 2 and 3 are the best. For now I might give a slight preference to option 3 just to isolate the plugin upgrade from the rest of the upgrade but it should not make that much of a difference. Peace - Anthony
Let me restate the question, so that we are all on the same page.
How do you upgrade from Moodle 1.9 to Moodle 2.0 when you have plugins?
From my experience so far, I agree options 2 and 3 are the best, but best doesn't necessarily imply success. Option 5 is successful: "Do not upgrade to Moodle 2.0!". This has been the most successful for me. Option 6 is better then 5: "Do not upgrade to Moodle 2.0 until the path for upgrading Moodle 1.9 with plugins has been made significantly easier and successful." but so far there is no difference between these options.
I have been tasked to migrate our Moodle to a new server computer. One goal is to upgrade from Moodle 1.8 to Moodle 2.0. My approach is to start with a clean install of Moodle 2.0 and verify it is all neat and clean and functioning properly. We have about 800 courses (for staff and students), with about 200 being heavily used. So, these courses need to get into the Moodle 2.0 server somehow. Of course, backing up the courses (so they can be restored into the destination) won't work because the versions of Moodle are different, so I have copied the current Moodle 1.8 server and upgraded it to Moodle 1.9. This was reasonably OK, and most of the plugins survived OK (i.e. with "installing" v1.9 versions of the plugins into /mod, /blocks, etc. into a clean Moodle 1.9 and then initiating the upgrade process). The aim is to then upgrade to Moodle 2.0 and then backup all the courses and restore them into the "clean" Moodle 2.0 that is waiting for them.
The problem at this point is that most of the plugins were rejected by the upgrade to Moodle 2.0 yet they are the latest versions. Also, the course backup mechanism is not wokring now because (it says) the courses have not been modified since the last backup, but I have no Moodle 2.0 backups. How do I force a backup of all courses?
The "latest" versions of a number of plugins appear to not be 2.0 compatible. For example, some plugins have on their page:
- Download latest version
- Download for Moodle 1.9
- Download for Moodle 1.8
Yet, the latest version does not work with Moodle 2.0. Also, when a plugin states for Moodle 1.9 or later, the "later" does not necessarily mean Moodle 2.0. It may only mean Moodle 1.9.1 (which is later).
So, if you, like me, are relying on plugins that are not available in Moodle 2.0, then you will have to decide between Moodle 1.9 with the plugins and keeping your existing courses and Moodle 2.0 without the plugins and starting your courses from scratch. Thus option 6 is the best and successful option (for the time being with hope that options 2 or 3 will eventually work).
The following plugins I have not been able to get working with Moodle 2.0:
- Appointment
- Book
- Brainstorm
- Face-to-Face
- Flashcard
- Manual
- Questionnaire
- Registration
- Scheduler
- Stamp Collection
- Technical Project
- Tracker
- Analog Clock
- Attendance
- Graph Stats / Usage
- Individual Learning Program
- jQuery Slideshow
- MRBS
- Certificate
- Story Telling
- Flash Activity (?)
- Hot Potatoes (?)
- Podcast (?)
- Skype (?)
- (maybe some others)
Some of these are dispensible, but some have become critical in our operations. Our students range from K to 12 plus staff. I would welcome information that helps reduce angst and helps make an informed decision about whether to try for Moodle 2.0 or not. So far, it looks like I should aim for Moodle 1.9.10 instead of Moodle 2.0. Can anyone confirm or reject? I have been aiming to get Moodle 2.0 running for next year. I am running out of time to change the goal.
Thanks.
couple of comments -
MRBS isn't really "safe" to use in a production site in it's 1.9 form - see Anthonys comments on this in the tracker and the forum - if you're using this in a 1.9 production site - I'd advise you to stop using it anyway.
Chardelle has already started the 2.0 conversion for certificate - I don't imagine it will take too much longer before she finishes it or someone else picks it up to complete the work.
Book Module - Petr already has an updated copy in github which works (AFAIK) with 2.0: https://github.com/skodak
Face to Face - new version is coming pretty soon - check out the face to face forum for updates.
Questionnaire - I'm pretty sure a good amount of work has gone into this recently and it might already be working - if not, check out the feedback module instead.
Analog Clock - you can use the Moodle HTML block and one of the many javascript clocks that are available - gives you a lot more flexibility than using a custom block - do a google search for "Javascript clock" - then paste the code into a Moodle html block.....although... personally I find the clock to be a gimmick that takes up screen real estate - most Computers have a clock viewable on the screen already....but I know there are a lot of people who like adding clocks to their pages!
..but...I'd suggest in your case that you should aim for a mid-year upgrade to 2.0 (if the extra modules you want have been completed by then)
good luck!
Thanks very much. Although it's not complete (i.e. for each plugin), it's just what I needed. Thanks for the estimate for when to aim for Moodle 2.0. That actually helps quite a lot.
MRBS is reasonably mission critical for us. We use it for all our bookings (some bookings are commercially based). I have made a couple of modifications to it: HTTPS and LDAP integration, both time-based and period-based bookings can be made.
Certificate is not critical but nice; looking forward to it. Not too much of a problem converting these manually (i.e. recreating).
Questionnaire is critical for is. We have some pretty big ones that are used as applications for certain programmes and some that are used in the reporting process with self-assessment. The feedback module was not sufficient for our purposes in these areas. We do use the feedback module where appropriate in other places. Maybe the new Feedback module is more powerful, but we would have to somehow migrate the Questionnaire modules to Feedback modules. Hopefully there is a non-manual method. Otherwise, that will hold us back too.
Although the Clock is mild, it is useful in lessons where time is critical. In my programing classes, for example, time can easily get away when you are so focused on the current activity. Your unconscious/subconscious is not really senstive to digital clocks. The Javascript suggestion is good for me, but I need a solution that a "normal" teacher can use. The HTML button has the same effect as showing them a motherboard: either blank face or random contortions of pain!
The main thing is to try to keep as much data (i.e. course activities and course files) when migrating to Moodle 2.0. Manual conversion of (i.e. manually re-creating) courses is not really an option for us; too many to convert. Which leads me back to the original question.
After "option 6" has succeeded, is not option 2 safer? Does option 3 create a window where a plugin misses the opportunity to upgrade? If Moodle has already done the upgrade process, might a plugin "think" it is being installed rather than upgraded? Thus, I guess that the best approach would be to try option 2 and then try option 3 for those that didn't work. But, then maybe that's contradicting "option 6". So, then, the question is do plugin developers consider how their plugins will be upgraded: do they expect option 2 or do they expect option 3?
It would be good if the Modules and Plugins database had a field for upgrading instructions next to the "Download version X" links.
Thanks again for your reply, much appreciated.
if you really want to upgrade now ( according to your statements around "Mission critical" plugins is probably not advisable) Option 2 with a combination of what Anthony mentions above is probably best - package a 2.0 codebase with any extra plugins that have been updated to 2.0 and delete the code for the plugins that haven't been upgraded yet - then run the upgrade. ... Then when the plugins are upgraded to 2.0 - install them manually and it will hopefully still have the database tables from your 1.9 version and might upgrade ok.
you should "probably" keep 1.9 backups of your courses with the extra modules in them so that if the upgrade doesn't pull through the old instances of your objects then you can do that manually.
good luck!
2,3 and 4 should all work (ideally!)
My concern with #4 is data loss. A backup is only as good as the restore. If a 2.0 version does not exist, I would tend to leave the data in the database and just let Moodle detect that the code is missing from the disk. Then once the code is developed it can be installed and the upgrade process for the plugin can be initiated. Peace - Anthony