Hi
You can only upgrade from 2.2 to 2.5 so you will need to upgrade from 2.0 to 2.2 first
I believe
Thanks Albert!
In this case, my question is...
Understanding I must firest upgrade from 2.0 to 2.2.... How big a task is it to upgrade a small Moodle 2.0 site to the latest 2.9 ?
In either case, you must upgrade to 2.2 before you can upgrade past that. For a small site, it may not be that painful, but it depends more on the plugins and theme the site uses. There were major theme changes in 2.7 so you will almost certainly have to pick a new theme. Just make sure you read the upgrade instructions. And, even though you are skipping versions, you should read the instructions for each version in between. Sometimes there are steps that need to be performed after an upgrade. Many of us would say it is safer to upgrade one version at a time, but the official position is that you can upgrade from 2.2.x to 2.9.x.
And as Howard said. Backup and verify that you can restore your backup because if something goes wrong during an upgrade, your backup is the only way to fix it. Backups include three parts: the public html/php files, moodledata files, and the database. You need to have a backup of all three to successfully restore.
I do not know the answer to #1 as we use mostly native Moodle.
For backups, there is a documentation page:
https://docs.moodle.org/29/en/Site_backup
I use a script for updates, but many on here would advise you to use Git. So here is my normal backup procedure. This assumes Linux. If you have Windows, the commands could be different.
#Path to your moodle site files
site='/home/user/public_html'
#Path to your moodledata (uploaded files, temp and cache)
files='/home/user/moodledata'
#Database info:
sqlhost='localhost'
sqluser='dbuser'
sqlpass='password'
db='moodledb'
mydate=$(date +%F)
echo "Putting site in maintenance mode..."
cd $site
php admin/cli/maintenance.php --enable
echo "Purging caches..."
php admin/cli/purge_caches.php
cd ..
echo "Creating SQL backup of $db..."
mysqldump --add-drop-table -h$sqlhost -u$sqluser -p$sqlpass $db > $db-backup-$mydate.sql
echo "Backing up programs and files..."
tar -cpzf _backup/$site-backup-$mydate.tgz $site $files $db-backup-$mydate.sql
rm $db-backup-$mydate.sql
#Out of maintenance mode
php admin/cli/maintenance.php --disable
Thanks. I don't think I'd be able to use this script as the site is on a shared host... no access to the "console" or command line.
I could be wrong.
Three of my shared hosting companies all provide access via ssh. If it doesn't appear that yours does, make sure to ask (or demand.)
Bret's script is very good, and I have learned from him. (Thanks Bret.)
Bret, help me understand a few things.
Does what you do in your script automatically make entries into the server's log file? Or would it make sense to log the events is your own "backup.log" file, somewhere? In particular, I would like to monitor when this script begins, and when it ends in order to know exactly how long my moodle is in Maintenance mode. I could probably (somehow) subtract mydate from an ending date (after maintenance mode is disabled.)
I see that you "echo" some messages. Are these really needed? Are these only there for a person who might be watching, or do they serve some other purpose?
When I do my current backup, I don't put my Moodle into maintenance mode. I can see the benefit - to keep the database and moodledata exactly in sync.
Hi Rick,
Glad it was helpful. I don't make any log entries. This was actually chopped out of my upgrade script, so it's not what I generally use for daily site backup. But any time I upgrade our live site, a full site backup gets done first.
Certainly you could pipe a couple of echo's to a log file to see each time the backup script started and ended. I don't do it here because upgrades are always in me-watching mode.
The echos are not needed. For me, since this is my upgrade script, it gives me a sense of where in the process the script is. Otherwise it would sit there for a long time with no feedback.
I only do my pre-upgrade backup in maintenance mode since that guarantees I have a good backup. For daily backups I dump the database and use rsync to download it and all the files to a local server where it gets backed up and shipped offsite per our normal backup policy. Plus rsync only has to copy the files that changed which significantly reduces the bandwidth requirements.
I do the offsite because once we had a disk controller die on the VPS host at the hosting company corrupting all the data. Yeah, they restored it, but we lost a few weeks in the process. Apparently, their idea of backup is not the same as mine. So now I have yesterday's backup on my local server, disk and tape backup so the ability to restore is more "guaranteed".
Thanks for your reply, Bret. Every little bit helps.
Bret and/or anyone else,
Seeing as the issue of backups came up, I have a fundamental backup question that I have never been able to properly answer...
I do backups regularly. However, should the need ever arise, and the site goes down, and I want to restore it, what do I do to ensure the latest backup is not corrupted in some way?
My nightmare scenario would be that I have been making regular backups, then the site crashes, and then I need to restore. However, I try backup #1, and it restores the site to something that doesn't work and/or s corrupt and won't restore properly. So I try backup #2, and since it was backing up my site that had a flaw in it that I never caught, it is corrupt also. And so and so on with all my backups.
Other than inspecting every backup I ever made, what can I do to ensure that if the site goes down I can restore it completely without error? I am looking for ideas on backup and restore procedures that will make my site bulletproof.
I regularly use the production backups to refresh my DEV and QA environments with the latest data from PROD. That confirms that the backups work.
Yes. There's no point taking backups if you don't use them to attempt to create a (working) copy of your Moodle site.
On anything more than a trivial site the ability to create backups and use them to make a parallel "test" site should be considered a core skill
Does anyone have an answer on nunmber 1 above? The question about QuizMaker?
Cheers
Take backups. Then check them. Then take more backups.
If you have backups then nothing bad can happen
Yup.... Well aware of backups, I would not proceed without them.
But alas, this doesn't answer my question
TinCan does not replace Scorm in moodle. There is no player for them... you need to link to something external.
Moodle quiz?
Hi Howard,
As mentioned it is an Articulate QuizMaker quiz. includes videos, etc.
If you intend to use SCORM (and I understand why you would) then you only have a very thin interface to Moodle. Presently this is just the way it works - and I don't see it changing soon. TinCan is in many respects even worse - you need to set up the TinCan resource outside of Moodle and then use an optional plugin to link to it and access the grades. Basically, it's still quite limited.
Either way, you are just using Moodle as a 'player' for the resource and having Moodle handle your users.
If you want a richer experience - in Moodle - then you should convert to using Moodle activities. It really comes down to what you need and where you are prepared to compromise.
I'm glad I spotted this thread. I sent an email to info@tincanapi.com with a related question, but the email address you provided (and the one published on your websites) doesn't work; the emails bounce.
Here's the response I wrote to the question you asked via email. It seems you've already figured out that upgrading your Moodle is a good idea, which is great.
