Search moodle.org's
Developer Documentation

See Release Notes
Long Term Support Release

  • Bug fixes for general core bugs in 4.1.x will end 13 November 2023 (12 months).
  • Bug fixes for security issues in 4.1.x will end 10 November 2025 (36 months).
  • PHP version: minimum PHP 7.4.0 Note: minimum PHP version has increased since Moodle 4.0. PHP 8.0.x is supported too.
/lib/db/ -> upgrade.php (source)

[Source view]

Differences Between: [Versions 310 and 401] [Versions 311 and 401] [Versions 39 and 401] [Versions 400 and 401] [Versions 401 and 402] [Versions 401 and 403]

This file keeps track of upgrades to Moodle. Sometimes, changes between versions involve alterations to database structures and other major things that may break installations.

Copyright: 2006 onwards Martin Dougiamas http://dougiamas.com
License: http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
File Size: 3115 lines (142 kb)
Included or required: 3 times
Referenced: 0 times
Includes or requires: 0 files

Defines 1 function

  xmldb_main_upgrade()

Functions
Functions that are not part of a class:

xmldb_main_upgrade($oldversion)   X-Ref
Main upgrade tasks to be executed on Moodle version bump

This function is automatically executed after one bump in the Moodle core
version is detected. It's in charge of performing the required tasks
to raise core from the previous version to the next one.

It's a collection of ordered blocks of code, named "upgrade steps",
each one performing one isolated (from the rest of steps) task. Usually
tasks involve creating new DB objects or performing manipulation of the
information for cleanup/fixup purposes.

Each upgrade step has a fixed structure, that can be summarised as follows:

if ($oldversion < XXXXXXXXXX.XX) {
// Explanation of the update step, linking to issue in the Tracker if necessary
upgrade_set_timeout(XX); // Optional for big tasks
// Code to execute goes here, usually the XMLDB Editor will
// help you here. See {@link https://moodledev.io/general/development/tools/xmldb}.
upgrade_main_savepoint(true, XXXXXXXXXX.XX);
}

All plugins within Moodle (modules, blocks, reports...) support the existence of
their own upgrade.php file, using the "Frankenstyle" component name as
defined at {@link https://moodledev.io/general/development/policies/codingstyle/frankenstyle}, for example:
- {@link xmldb_page_upgrade($oldversion)}. (modules don't require the plugintype ("mod_") to be used.
- {@link xmldb_auth_manual_upgrade($oldversion)}.
- {@link xmldb_workshopform_accumulative_upgrade($oldversion)}.
- ....

In order to keep the contents of this file reduced, it's allowed to create some helper
functions to be used here in the {@link upgradelib.php} file at the same directory. Note
that such a file must be manually included from upgrade.php, and there are some restrictions
about what can be used within it.

For more information, take a look to the documentation available:
- Data definition API: {@link https://moodledev.io/docs/apis/core/dml/ddl}
- Upgrade API: {@link https://moodledev.io/docs/guides/upgrade}

param: int $oldversion
return: bool always true