Moodle is being updated constantly, which is common practice in open source development environments. A new version containing resolved bug fixes is created every night and, as mentioned earlier, a fully-tested version is released on a weekly basis. There is usually no need to install updates every week; however, there are a number of scenarios when you should upgrade your Moodle system:
Security patches have been issued
New features have been added
Bugs have been fixed that affect your setup
A new version is released
There are principally two ways Moodle systems can be updated. You can either run updates manually (using the web interface or the CLI) or stay up to date using Git commands. Both procedures are described in this section.
Either way, before you start, make sure you put Moodle in maintenance mode to ensure that no other user is logged in during the update. Go to Server | Maintenance mode, Enable the Maintenance mode, and enter a maintenance message:
You can also put Moodle in maintenance mode using its CLI as follows:
sudo –u www-data /usr/bin/php admin/cli/maintenance.php --enable
Using the --enablelater=MINUTES flag you can specify the time period before entering CLI maintenance mode. This is useful when you run an automatic update.
To change back to normal mode, use the --disable parameter instead of --enable as follows:
sudo –u www-data /usr/bin/php admin/cli/maintenance.php --disable
The high-level process for updating a Moodle system manually is as follows:
Creating a backup.
Creating a new Moodle system.
Installing the update.
If you are updating from a previous version of Moodle, the process is the same. However, double-check the Upgrading document at https://docs.moodle.org/en/Upgrading for any version-specific issues.
If you are still on version 1.9 or on a dinosaur release that is even older, you will need to get to version 2.0 first, before upgrading to 2.2, and then to the latest version.
Tip
Updating from Moodle 1.x to Moodle 3 is a big version jump that has some serious implications. For example, some theme elements will have to be recreated, custom code will need adjusting and, most importantly, your support and faculty staff is likely to require training before the new version is put in production.
Moving from Moodle 1.x to Moodle 3 is more a migration from one system to another than an update. Setting up a separate test system to test the migration process has proven valuable. You will have to plan and have a budget for this.
Before you install a new update, it is highly recommended that you run a backup of your Moodle system. While most updates will run smoothly, the backup will be required if you have to revert the system to the pre-update version. There are three parts that have to be backed up:
Database: There are two ways you can create a so-called database dump from a MySQL database, either via command line or via Moodle's optional database interface.
The simplest syntax for the command line tool is:
mysqldump -u <user> -p <database> > backup.sqlTo restore the database you need to use the
mysqlcommand line tool as follows:mysql -u <user> -p <database> < backup.sqlThe interface for the database tool is accessed via Server | Moodle Adminer. This is an optional module and has to be installed separately refer to Chapter 8, Moodle Plugins, for more details).
Click on the Dump link on the front page, select the database to export, and click on Export, as shown in the following screenshot. The output of the command will be displayed on screen.
Data directory: This is the
moodledatadirectory. Create a copy of this elsewhere on the server (usingcp –R) or create an archive using thetarcommand (tar –cvf moodledata).Moodle: This is the Moodle software itself. Create a copy of the directory elsewhere on the server. While only some parts of this backup are required (
config.php, added themes, modified language packs, and so on), it is good practice to create a backup of the entire software. Finally, rename your Moodle system frommoodleto, say,moodle.old(mv moodle moodle.old).
Note
For more information on backups, check out Chapter 13, Backup and Restore.
Once you have created a backup, it is time to download the new version of Moodle. This is done in the same way as described earlier, during the installation process.
First, create a new moodle directory (dirroot) and copy the new version to that location (using the same unzip or tar command as during the installation). Also make sure the permissions as well as user and group are correct.
Now, copy the following files and directories from your moodle.old directory to your new dirroot. The existing files and directories will have to be overwritten:
config.php.htaccess(only if present)Any theme folders that have been created
Any modified language packs
The content of the
localdirectoryAny third-party modules and custom code that is not located in
local
That's it! The next time you start Moodle, the update script will kick in. We'll go through that next.
Once you are more confident with the update process, you can copy the new version straight on top of the current version after you have created backups. This will save you the last steps of manually copying files from the old to the new versions.
Once you go to the location of your Moodle site and log in as administrator, the system will recognize that a new version is available and kick off the installer automatically.
The first screen displays the build of the new version (here, 3.0) and asks you to confirm that you wish to go ahead with the upgrade:
Next, a screen is displayed that provides a link to the release notes and performs the same server check as the one described during the installation.
Moodle plugins, whether core (Standard) or third-party (Additional), sometimes cause problems when upgrading Moodle. The Status column highlights any actions required or problems found. You should resolve any issues that have arisen. Refer to Chapter 8, Moodle Plugins, for more details.
Once this screen has been confirmed, the actual installation starts, during which new database fields are created and data is modified if and when necessary. Any new system settings that have been added to Moodle are shown and can be changed straightaway. For example, in the following screenshot, a new Always send email from the no-reply address parameter has been added:
Once the upgrade process has been completed, make sure you check the Notifications page as earlier. Also, don't forget to turn off the Maintenance mode!
As you would expect, Moodle updates can also be run using the already-discussed CLI. Once you have backed up your data and updated to the latest version, all you need to do is run the following script:
sudo –u www-data /usr/bin/php admin/cli/upgrade.php --non-interactive
Updating Moodle via CLI is even more powerful when combined with the Git checkout of the Moodle source code. That is what we look at next.
An alternative approach exists to keep a current version up-to-date. It uses an open source versioning system which is supported by Moodle, namely Git. All checked-in Moodle code is made available via this method, which allows you to update only the modules that have actually changed.
Setting up Git is a cumbersome process, which is beyond the scope of this book. You can find details at https://docs.moodle.org/en/Git_for_Administrators. However, once set up, Git is a very streamlined system to use, particularly, in conjunction with the CLI we discussed earlier. The following is a sample script which gets the latest version of the source code, puts Moodle in maintenance mode, merges the old code with the new, runs the upgrade script, and disables the maintenance mode:
git fetch sudo -u www-data /usr/bin/php admin/cli/maintenance.php --enable git merge origin/cvshead sudo -u www-data/usr/bin/php admin/cli/upgrade.php sudo -u www-data/usr/bin/php admin/cli/maintenance.php --disable
If you have changed any core code, potential conflicts might arise and will have to be resolved (Git will prompt you to do so).
You might also come across some conflicting advice on whether to use Git for production sites or not. The advantage is that your system is always up to date and that the updates are carried out automatically. The disadvantage is that the update process might require intervention to resolve any conflicts or it might fail, especially when a lot of third-party add-ons have been employed.
Moodle can notify you about a newly available version. In order to support this feature, you will need to change the Enable updates deployment settings in Server | Update notifications as follows:
Once this has been changed, you will be notified of any updates (system as well as plugins), and options will be shown in Notifications:
