Book Image

Moodle Administration Essentials

Book Image

Moodle Administration Essentials

Overview of this book

Table of Contents (15 chapters)
Moodle Administration Essentials
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Updating Moodle


As mentioned earlier, Moodle HQ releases updates on a regular basis, which include bug fixes and security patches. Hence, it is important to know how to update the Moodle codebase to keep it secure.

Upgrading from one version to another

Note

Most importantly, any Moodle site older than 2.2 being upgraded to above 2.2 must be first upgraded to 2.2 completely, and then upgraded to 2.X.

Your first step is to create a copy of your live site and practice the upgrade process on it from the beginning to the end, ensuring that everything upgrades as expected.

Cloning your Moodle site

These are the recommended steps to create a clone of your Moodle live site:

  1. Moodle code directory: Create a brand new directory and fully copy all directories and files from the live moodle code directory into it, following the installation guidelines for its location and permissions.

  2. Moodle data directory: Create a brand new moodledata folder, again following the installation guidelines for its location and permissions.

  3. Database: The following are the steps to create a new database:

    1. Create a new database in your database application, again following the installation guidelines.

    2. Create a new database user with relevant permissions to the new database, again following the installation guidelines.

    3. Populate the new database from a full MySQL or other database dump file of the live Moodle database.

    4. For instance, to create a MySQL dump in normal command line:

      mysqldump -h localhost -u <dbuser> --password=<dbpass> -C -Q -e --create-options <dbname> > dbnameclone.sql
      
    5. This also requires you to ensure correct character encoding is used if needed as a MySQL dump is not 100% reliable for all UTF-8 encoding.

    6. To populate the new database with the dump file:

    7. Check you are in the correct new database in MySQL command line and only then use the following query:

      source dbnameclone.sql;
      
  4. Config.php: This urgently needs to be changed so edit this in the new moodle code directory to point to the new moodledata directory, the new database, and the new URL as it will initially have the settings to the live site, which urgently needs to be changed.

  5. The cloned site should now be operational.

  6. Login: Check that the clone site is accessible.

  7. Upload a file resource to check that the moodledata directory permissions and locations are all working correctly.

  8. Review a course and check that it appears as it should.

  9. Update your user profile with a minor change and check that the new values are in the new database, not the live database.

  10. There is also an admin tool on your Moodle site to find and replace any potential hard-coded URLs for resources such as images. This is located at admin/tool/replace/index.php. Please note that this will only work on sites, which use either MySQL or Postgres.

    Note

    The following upgrade steps should, therefore, be run firstly and completely on your cloned site and only then on your live site.

Upgrade preparation

Put your site into maintenance mode by navigating to Administration | Site administration | Server | Maintenance mode. This prevents non-admin users from logging into the site and altering any of its contents, such as course resources, submitting assignments, posting to forums, and so on.

Note

Any of these types of alterations will not only render your backups obsolete, but also compromise the integrity of the final upgraded site.

Before you start any upgrades, you need to take a full backup of your Moodle site. This involves three components:

  • moodle code directory: This may contain external plugins and other customized changes to core Moodle

  • moodledata directory: This contains all stored moodle data files, which the Moodle code relies on for course resources, log files, and so on

  • moodle database: This contains all database records related to the Moodle site

Moodle code directory

Take a full backup of this directory and also have a list of all external plugins and any core code customizations, which have been implemented.

Moodle data directory

Take a full backup of this directory. Its location is found in the config.php script.

Moodle database

Take a full MySQL dump of the relevant Moodle database. This also requires you to ensure correct character encoding used if needed as the MySQL dump is not 100 percent reliable for all UTF-8 encoding.

Moodle download

As with an initial Moodle installation, we always recommend that you download your Moodle code directly from https://moodle.org/. For this example, we will be updating to Moodle Version 2.8.

You can either download the ZIP file from https://download.moodle.org/ and unzip it, or use Git to pull the code from the Moodle Git repository.

  1. First of all, on your server, locate and go to the directory containing the moodle site directory which you are upgrading.

  2. Download and unzip the ZIP file from https://moodle.org/ or use the following Git command (for versions other than 2.8, use the relevant branch name):

    git clone -b MOODLE_28_STABLE git://git.moodle.org/moodle.git <directory>
    

    Note

    Please note that this will overwrite the existing data in the target moodle code directory with the latest 2.8 moodle code.

Once you have completed the updating of the Moodle code directory, you then need to complete the following steps:

  1. Where external plugins have more up-to-date code for your upgrade version, replace the older plugin code completely, which is explained more in Chapter 6, Managing Site Plugins.

  2. Where you have made previous customizations to core Moodle code (which is not a recommended practice for this exact reason!), you will need to locate each file in turn and manually add the customized code into them.

  3. Copy the config.php script from the backup into the target moodle code directory.

  4. Check that all the moodle code directories, subdirectories, and files are web server readable.

  5. Check that your usual cron usage is enabled, either that the admin/cron.php script is executable via the browser or more typically that the site is listed in the cron program for your server, which is explained more in Chapter 8, Miscellaneous Admin Tasks.

  6. Go to the notifications page by navigating to Administration | Site administration | Notifications to kick off the final upgrade process and click on Continue:

  7. Once the upgrade process has been completed, purge all caches by navigating to Administration | Site administration | Development | Purge all caches. This will ensure that the browser displays the latest Moodle site and not any cached information.

  8. Test the site fully according to your organization's requirements. We would suggest at a minimum:

    1. Login as Admin, teacher, and student

    2. Upload a file resource

    3. Review a course and its contents

    4. Update your user profile

  9. Take your site out of maintenance mode, if previously enabled, by navigating to Administration | Site administration | Server | Maintenance mode.

Maintaining the version code

Each Moodle version branch is updated weekly to ensure that all code is up-to-date, which may include fixes to recently discovered issues.

Hence, if your site is 2.8, it will also be a version of 2.8, for instance 2.8.3. If you decide to upgrade to a more recent version of 2.8, for instance 2.8.6, you should still follow the exact same procedure as we explained earlier for the upgrade process. This ensures that if there are any issues during the upgrade process, you have an easily accessible original version to instantly roll back to.

When to update

Moodle has minor releases every 2 months and major releases every 6 months. It is advisable to update with every minor release if possible, and at least yearly with a major release.

There is also a long-term support release (currently 2.7 and the next one is 3.0) that can offer the opportunity to only do a major update every 3 years.