MoodleDocs - User contributions [en]

User:Eloy Lafuente (stronk7)/Phpdoc types

2024-04-10T11:14:45Z

Stronk7: master2main

==Overview==
===Scope===

This document describes '''style''' guidelines for developers working on or with Moodle code. It talks purely about the mechanics of code layout and the choices we have made for Moodle.

For details about using the Moodle API to get things done, see the [[Coding|coding guidelines]].

===Goals===

Consistent coding style is important in any development project, and particularly when many developers are involved. A standard style helps to ensure that the code is easier to read and understand, which helps overall quality.

Abstract goals we strive for:

* simplicity
* readability
* tool friendliness, such as use of method signatures, constants, and patterns that support IDE tools and auto-completion of method, class, and constant names.

When considering the goals above, each situation requires an examination of the circumstances and balancing of various trade-offs.

Note that much of the existing Moodle code may not follow all of these guidelines - we continue to upgrade this code when we see it.

===Useful tools===

There are a couple of different tools available to help you in writing code that conforms to this guide.

; Code checker (integrates with [https://github.com/moodlehq/moodle-local_codechecker/blob/main/README.md#ide-integration eclipse/phpstorm]): http://moodle.org/plugins/view.php?plugin=local_codechecker
; Marina Glancy's Moodle PHPdoc checker : https://github.com/marinaglancy/moodle-local_moodlecheck

It is worth using both tools to check the code you are writing as they both perform slightly different checks.
If you can get your code to pass both then you are well on the way to making friends with those who will be reviewing your work.

==File Formatting==

===PHP tags===

Always use "long" php tags. However, to avoid whitespace problems, DO NOT include the closing tag at the very end of the file.

<syntaxhighlight lang="php">
<?php

require('config.php');

</syntaxhighlight>

===Indentation===

Use an indent of '''4 spaces''' with no tab characters. Editors should be configured to treat tabs as spaces in order to prevent injection of new tab characters into the source code.

Don't indent the main script level:

GOOD:
<syntaxhighlight lang="php">
<?php
require('config.php');
$a = required_param('a', PARAM_INT);
if ($a > 10) {
call_some_error($a);
} else {
do_something_with($a);
}
</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">
<?php
require('config.php');
$a = required_param('a', PARAM_INT);
if ($a > 10) {
call_some_error($a);
} else {
do_something_with($a);
}
</syntaxhighlight>

SQL queries use special indentation, see [[SQL coding style]].

===Maximum Line Length===

The key issue is readability.

Aim for 132 characters if it is convenient, it is not recommended to use more than 180 characters.

====Wrapping lines====

When wrapping a line, indent the follow-on line by 8 spaces rather than 4. For example:

<syntaxhighlight lang="php">
if (a_long_condition() &&
a_nother_long_condition()) {
do_something();
}
</syntaxhighlight>

Using eight spaces makes it easier to spot the difference between wrapped lines and indented blocks.

The example above is only an illustration; it is best practice to avoid wrapping lines in control structures. See below.

====Wrapping Arrays====

Associative arrays are a exception to the rule about 8-space indent for follow-on lines. The correct layout is:
<syntaxhighlight lang="php">
$plugininfo['preferences'][$plugin] = array(
'id' => $plugin,
'link' => $pref_url,
'string' => $modulenamestr
);
</syntaxhighlight>
Lining up the =>s is optional. Small arrays can be done on one line.

====Wrapping function declarations====
If you have many parameters, indent them in line with the first parameter:
<syntaxhighlight lang="php">
public function graded_users_iterator($course, $grade_items = null, $groupid = 0,
$sortfield1 = 'lastname', $sortorder1 = 'ASC',
$sortfield2 = 'firstname', $sortorder2 = 'ASC') {
</syntaxhighlight>

====Wrapping Control Structures====
If you have too many conditions in one control structure, try setting some variables before the start of the structure to improve readability.

GOOD:
<syntaxhighlight lang="php">
$coursecategory = $element['object']->is_course_item() or $element['object']->is_category_item();
$scalevalue = in_array($element['object']->gradetype, array(GRADE_TYPE_SCALE, GRADE_TYPE_VALUE));

if ($coursecategory and $scalevalue) {
</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">
if (($element['object']->is_course_item() or $element['object']->is_category_item())
and ($element['object']->gradetype == GRADE_TYPE_SCALE
or $element['object']->gradetype == GRADE_TYPE_VALUE)) {
</syntaxhighlight>

===Line Termination===

Use standard '''Unix''' text format. Lines must end only with a linefeed (LF). Linefeeds are represented as ordinal 10, or hexadecimal 0x0A.

Do not use carriage returns (CR) like old ''Macintosh'' computers (0x0D).

Do not use the carriage return/linefeed combination (CRLF) as ''Windows'' computers (0x0D, 0x0A).

Lines should not contain trailing spaces. In order to facilitate this convention, most editors can be configured to strip trailing spaces, such as upon a save operation. However, if you are editing an existing Moodle file and are planning to submit your changes for integration, please switch off that feature so that whitespace changes do not pollute the patch (other developers will have trouble viewing what you've done if every other line has been edited for whitespace).

==Naming Conventions==

===Filenames===

Filenames should :
* be whole english words
* be as short as possible
* use lowercase letters only
* end in .php, .html, .js, .css or .xml

===Classes===

Class names should always be lower-case English words, separated by underscores:

<syntaxhighlight lang="php">
class some_custom_class {
function class_method() {
echo 'foo';
}
}
</syntaxhighlight>

Always use () when creating new instances even if constructor does not need any parameters.

<syntaxhighlight lang="php">
$instance = new some_custom_class();
</syntaxhighlight>

When you want an plain object of no particular class, for example when you are preparing some data to insert into the database with $DB->insert_record, you should use the PHP standard class '''stdClass'''. For example:

<syntaxhighlight lang="php">
$row = new stdClass();
$row->id = $id;
$row->field = 'something';
$DB->insert_record('table', $row);
</syntaxhighlight>

''Before Moodle 2.0, we used to define a class '''object''' extending stdClass, and use new object(); This has now been deprecated. Please use stdClass instead.''

===Functions and Methods===

Function names should be simple English lowercase words, and start with the [[Frankenstyle]] prefix and plugin name to avoid conflicts between plugins. (Modules still use only plugin name for legacy reasons.) Words should be separated by underscores.

Verbosity is encouraged: function names should be as illustrative as is practical to enhance understanding.

Note there is no space between the function name and the following (brackets).

<syntaxhighlight lang="php">
function forum_set_display_mode($mode = 0) {
global $USER, $CFG;

if ($mode) {
$USER->mode = $mode;
} else if (empty($USER->mode)) {
$USER->mode = $CFG->forum_displaymode;
}
}
</syntaxhighlight>

====Function Parameters====

Parameters are always simple lowercase English words (sometimes more than one, like $initialvalue), and should always have sensible defaults if possible.

Use "null" as the default value instead of "false" for situations like this where a default value isn't needed.
<syntaxhighlight lang="php">
public function foo($required, $optional = null)
</syntaxhighlight>

However, if an optional parameter is boolean, and its logical default value should be true, or false, then using true or false is acceptable.

===Variables===

Variable names should always be easy-to-read, meaningful lower-case English words. If you really need more than one word then run them together, but keep them short as possible. Use '''plural''' names for arrays of objects. Use '''positive''' variables names always (allow, enable not prevent, disable).

GOOD: $quiz
GOOD: $errorstring
GOOD: $assignments (for an array of objects)
GOOD: $i (but only in little loops)
GOOD: $allowfilelocking = false

BAD: $Quiz
BAD: $camelCase
BAD: $aReallyLongVariableNameWithoutAGoodReason
BAD: $error_string
BAD: $preventfilelocking = true

Core global variables in Moodle are identified using uppercase variables (ie $CFG, $SESSION, $USER, $COURSE, $SITE, $PAGE, $DB and $THEME). Don't create any more!

===Constants===

Constants should always be in upper case, and always start with [[Frankenstyle]] prefix and plugin name (in case of activities the module name only for legacy reasons). They should have words separated by underscores.
<syntaxhighlight lang="php">
define('FORUM_MODE_FLATOLDEST', 1);
</syntaxhighlight>

===Booleans and the null value===

Use lower case for '''true''', '''false''' and '''null'''.

=== Namespaces ===

Namespaces are not required for any new code and there is no requirement to move non-namespaced classes to namespaces. If
namespaces are used - they must conform to these rules.

Classes belonging to a namespace must be created in a classes directory inside a plugin (e.g. mod/forum/classes), or for core code,
in lib/classes or subsystemdir/classes.

The classname and filename for all namespaced classes must conform to the
[[Automatic class loading|automatic class loading]] rules.

Use at most one namespace declaration per file.

GOOD:
<syntaxhighlight lang="php">
<? // This is a file mod/porridge/classes/local/equipment/spoon.php

namespace mod_porridge\local\equipment;

class spoon {
// Your code here.
}

// End of file.
</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">
namespace mod_porridge\local\equipment;

class spoon {
// Your code here.
}

namespace mod_porridge\local\procedures; // We are changing the namespace here, do not do it.

class eat {
// Another code here.
}

// End of file.
</syntaxhighlight>

The namespace declaration may be preceded with a doc block.

The [[Coding style#Classes|class naming]] rules also apply to the names for each level of namespace.

The namespace declaration must be the first non-comment line in the file, followed by one blank line, followed by the (optional)
"use" statements, one per line, followed by one blank line.

"use" statements should be used to avoid repetition of long namespaces in the code.

Do not import an entire namespace with a "use" statement, import individual classes only.

Do not use named imports ("use XXX as YYY;") unless it is absolutely required to resolve a conflict.

GOOD:
<syntaxhighlight lang="php">use mod_porridge\local\equipment\spoon; // One class per line.
use mod_porridge\local\equipment\bowl; // One class per line.

</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">use mod_porridge\local\equipment\spoon, mod_porridge\local\equipment\bowl; // Multiple classes per line.
use mod_porridge\local; // Importing an entire namespace.
use core; // Importing an entire namespace.
use mod_breakfast; // Importing an entire namespace.
use mod_porridge\local\equipment\spoon as silverspoon; // Named import with no good reason.

</syntaxhighlight>

Never use the __NAMESPACE__ magic constant.

Never use the "namespace" keyword anywhere but the namespace declaration.

BAD:
<syntaxhighlight lang="php">
$obj = new namespace\Another();
</syntaxhighlight>

Do not use bracketed "namespace" blocks.

BAD:
<syntaxhighlight lang="php">
namespace {
// Global scope.
}
</syntaxhighlight>

Namespaces MUST only be used for classes existing in a subfolder of "classes".

For new classes - the maximum level of detail should be used when deciding the namespace.

GOOD:
<syntaxhighlight lang="php">
namespace xxxx\yyyy; // xxxx is the component, yyyy is the api.

class zzzz {
}
</syntaxhighlight>

Never use a leading backslash (\) in "namespace" and "use" statements.

Global functions called from namespaced code should never use a leading
backslash (\). Classes from outside the current scope use the leading backslash
or are imported by the "use" keyword. See
[http://www.php.net/manual/en/language.namespaces.fallback.php PHP manual] for
details.

GOOD:
<syntaxhighlight lang="php">
namespace mod_breakfast\local;

use moodle_url;

echo get_string('goodmorning', 'mod_breakfast'); // No leading backslash for global functions.
$url = new moodle_url(...); // Leading backslash not needed here because we imported it into our namespace via "use".
$tasks = \core\task\manager::get_all_scheduled_tasks(); // Leading slash needed here.
$a = new \stdClass(); // Leading slash needed here.
</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">
namespace \mod_breakfast; // The leading backslash should not be here.

use \core\task\manager; // The leading backslash should not be here.

\get_string('xxxx', 'yyyy'); // The leading backslash should not be here.
</syntaxhighlight>

==== Parts of a namespace ====

Given the following fully qualified name of a class:

"\<level1>\<level2>\<level3>\...\<classname>"

There are clear rules for what is allowable at each level of namespace. Only the first level is mandatory. Nested namespaces are used when the class implements some core API or when the plugin maintainer want to organise classes to separate namespaces within the plugin - see rules regarding the level2 for details.

==== Rules for level1 ====

The first level MUST BE EITHER:
* a full component name (e.g. "\mod_forum"). All classes using namespaces in a plugin MUST be contained in
this level 1 namespace.
or
* "\core" for all core apis

==== Rules for level2 ====

The second level, when used, MUST BE EITHER:
* The short name of a core API (must be defined on https://docs.moodle.org/dev/API). The classes in this namespace must either implement or use the API in some way.
or
* "\local" for any other classes in a plugin, if the maintainer wants to organise them further (note that for most plugins, it's probably enough to have all their own classes in the root level1 namespace only).

==== Rules for level3 ====

There are no rules limiting what can be used as a level 3 namespace. This is where a plugin or addon can make extensive use of
namespaces with no chance of conflict with any other plugin or api, now and forever onwards.

==== Examples ====

GOOD:
<syntaxhighlight lang="php">
namespace mod_breakfast; // Plugin's own namespace when not using nested namespaces (typical)
namespace mod_breakfast\local; // Plugin's own namespace when using nested namespaces
namespace mod_breakfast\local\utils; // Plugin's own namespace when using nested namespaces with further organisation
namespace mod_breakfast\event; // Plugin's namespace to implement core API

</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">
namespace mymodule; // Violates the level1 rules - invalid component name
namespace mod_breakfast\myutilities; // Violates the level2 rules - invalid core API name
</syntaxhighlight>

== Strings ==

Since string performance is not an issue in current versions of PHP, the main criteria for strings is readability.

===Single quotes===

Always use single quotes when a string is literal, or contains a lot of double quotes (like HTML):

<syntaxhighlight lang="php">
$a = 'Example string';
echo '<span class="'.s($class).'"></span>';
$html = '<a href="http://something" title="something">Link</a>';
</syntaxhighlight>

===Double quotes===

These are a lot less useful in Moodle. Use double quotes when you need to include plain variables or a lot of single quotes.

<syntaxhighlight lang="php">
echo "<span>$string</span>";
$statement = "You aren't serious!";
</syntaxhighlight>

Complex SQL queries should be always enclosed in double quotes.

<syntaxhighlight lang="php">
$sql = "SELECT e.*, ue.userid
FROM {user_enrolments} ue
JOIN {enrol} e ON (e.id = ue.enrolid AND e.enrol = 'self' AND e.customint2 > 0)
JOIN {user} u ON u.id = ue.userid
WHERE :now - u.lastaccess > e.customint2";
</syntaxhighlight>

===Variable substitution===

Variable substitution can use either of these forms:

<syntaxhighlight lang="php">
$greeting = "Hello $name, welcome back!";

$greeting = "Hello {$name}, welcome back!";
</syntaxhighlight>

===String concatenation===

Strings must be concatenated using the "." operator.

<syntaxhighlight lang="php">
$longstring = $several.$short.'strings';
</syntaxhighlight>

If the lines are long, break the statement into multiple lines to improve readability. In these cases, put the "dot" at the end of each line.

<syntaxhighlight lang="php">
$string = 'This is a very long and stupid string because '.$editorname.
" couldn't think of a better example at the time.";
</syntaxhighlight>
The dot operator may be used without any space to either side (as shown in the above examples), or with spaces on each side; whichever the developer prefers.

===Language strings===

====Capitals====

Language strings should "Always look like this" and "Never Like This Example".

Capitals should only be used when:
# starting a sentence, or
# starting a proper name, like Moodle.

====Structure====

Strings should not be designed for UI concatenation, as it may cause problems in other languages. Each string should stand alone.

BAD:
$string['overduehandling'] = 'When time expires';
$string['overduehandlingautosubmit'] = 'the attempt is submitted automatically';
$string['overduehandlinggraceperiod'] = 'there is a grace period in which to submit the attempt, but not answer more questions';
$string['overduehandlingautoabandon'] = 'that is it. The attempt must be submitted before time expires, or it is not counted';

GOOD:
$string['overduehandling'] = 'Time expiry behaviour';
$string['overduehandlingautosubmit'] = 'Unfinished attempts will be auto-submitted immediately';
$string['overduehandlinggraceperiod'] = 'Unfinished attempts have a short grace period to be submitted for grading';
$string['overduehandlingautoabandon'] = 'Unfinished attempts are immediately discarded';

==Arrays==

===Numerically indexed arrays===

When declaring indexed arrays with the array function, a trailing space must be added after each comma delimiter to improve readability:

<syntaxhighlight lang="php">
$myarray = array(1, 2, 3, 'Stuff', 'Here');
</syntaxhighlight>

Multi-line indexed arrays are fine, but pad each successive lines as above with an 8-space indent:

<syntaxhighlight lang="php">
$myarray = array(
1, 2, 3, 'Stuff', 'Here',
$a, $b, $c, 56.44, $d, 500);
</syntaxhighlight>

===Associative arrays===

Use multiple lines if this helps readability. For example:

<syntaxhighlight lang="php">
$myarray = array(
'firstkey' => 'firstvalue',
'secondkey' => 'secondvalue'
);
</syntaxhighlight>

==Classes==

=== Class declarations ===

* Classes must be named according to Moodle's naming conventions.
* The brace should always be written on the line beside the class name.
* Every class must have a documentation block that conforms to the PHPDocumentor standard.
* All code in a class must be indented with 4 spaces.
* Placing additional code in class files is permitted but discouraged. In such files, two blank lines must separate the class from any additional PHP code in the class file.

: An example:

<syntaxhighlight lang="php">
/**
* Documentation Block Here
*/
class sample_class {
// All contents of class
// must be indented 4 spaces.
}
</syntaxhighlight>

===Class member variables===

Member variables must be named according to Moodle's variable naming conventions.

Any variables declared in a class must be listed at the top of the class, above the declaration of any methods.

The var construct is not permitted. Member variables always declare their visibility by using one of the '''private''', '''protected''', or '''public''' modifiers. Giving access to member variables directly by declaring them as public is permitted but discouraged in favor of accessor methods (set/get).

==Functions and methods==
===Function and method declaration===

Functions must be named according to the Moodle function naming conventions.

Methods inside classes must always declare their visibility by using one of the private, protected, or public modifiers.

As with classes, the brace should always be written on same line as the function name.

Don't leave spaces between the function name and the opening parenthesis for the arguments.

The return value must not be enclosed in parentheses. This can hinder readability, in additional to breaking code if a method is later changed to return by reference.

Return should only be one data type. It is discouraged to have multiple return types

<syntaxhighlight lang="php">
/**
* Documentation Block Here
*/
class sample_class {

/**
* Documentation Block Here
*/
public function sample_function() {
// All contents of function
// must be indented four spaces.
return true;
}
}
</syntaxhighlight>

===Function and method usage===

Function arguments should be separated by a single trailing space after the comma delimiter.

<syntaxhighlight lang="php">
three_arguments(1, 2, 3);
</syntaxhighlight>

==Control statements==

In general, use white space liberally between lines and so on, to add clarity.

===If / else===

Put a space before and after the control statement in brackets, and separate the operators by spaces within the brackets. Use inner brackets to improve logical grouping if it helps.

Indent with four spaces.

''Don't use elseif!''

Always use braces (even if the block is one line and PHP doesn't require it).

<syntaxhighlight lang="php">
if ($x == $y) {
$a = $b;
} else if ($x == $z) {
$a = $c;
} else {
$a = $d;
}
</syntaxhighlight>

===Switch===

Put a space before and after the control statement in brackets, and separate the operators by spaces within the brackets. Use inner brackets to improve logical grouping if it helps.

Always indent with four spaces. Content under each case statement should be indented a further four spaces.

<syntaxhighlight lang="php">
switch ($something) {
case 1:
break;

case 2:
break;

default:
break;
}
</syntaxhighlight>

===Foreach===

As above, uses spaces like this:

<syntaxhighlight lang="php">
foreach ($objects as $key => $thing) {
process($thing);
}
</syntaxhighlight>

===Ternary Operator===

The ternary operator is only permitted to be used for '''short''', '''simple to understand''' statements. If the statement can't be understood in one sentance, use an if statement instead.

Whitespace must be used around the operators to make it clear where the operation is taking place.

GOOD:
<syntaxhighlight lang="php">
$username = isset($user->username) ? $user->username : '';
</syntaxhighlight>

BAD:
<syntaxhighlight lang="php">
$toload = (empty($CFG->navshowallcourses))?self::LOAD_ROOT_CATEGORIES:self::LOAD_ALL_CATEGORIES;
$coefstring = ($coefstring=='' or $coefstring=='aggregationcoefextrasum') ? 'aggregationcoefextrasum' : 'aggregationcoef';
</syntaxhighlight>

==Require / include==

Each file that is accessed via browser should start by including the main config.php file.

<syntaxhighlight lang="php">
require(__DIR__ . '/../../config.php');
</syntaxhighlight>

Any other include/require should use an absolute path starting with <tt>$CFG->dirroot</tt> or <tt>$CFG->libdir</tt> or path starting with __FILE__ or __DIR__. Relative includes starting with "../" can [http://uk.php.net/manual/en/function.include.php sometimes behave strangely under PHP], so it is safer to avoid them. Our CLI script must not use relative config.php paths starting with "../".

Includes should generally only be done at the top of files or inside functions/methods that need them. Using include/require in the middle of a file in global scope very hard to audit the security of the code.

All other scripts with the exception of imported 3rd party libraries should use following code at the very top to prevent direct execution which might reveal error messages on misconfigured production servers.

<syntaxhighlight lang="php">
defined('MOODLE_INTERNAL') || die();
</syntaxhighlight>

==Documentation and comments==

Code documentation explains the code flow and the purpose of functions and variables. Use it whenever practical.

==PHPDoc==

Moodle stays as close as possible to "standard" [http://www.phpdoc.org/ PHPDoc format] to document our files, classes and functions. This helps IDEs (like Netbeans or Eclipse) work properly for Moodle developers, and also allows us to generate web documentation automatically.

PHPDoc has a number of tags that can be used in different places (files, classes and functions). We have some particular rules for using them in Moodle that you must follow:

===Types===

Some of the tags below (@param, @return...) do require the specification of a valid php type and a description. All these are allowed:

* PHP primitive types: int, bool, string...
* PHP complex types: array, stdClass (not Array, object).
* PHP classes:full or relative (to current namespace) class names.
* true, false, null (always lowercase).
* static: for methods returning a new instance of the child/caller class.
* self: for methods returning a new instance of the parent/called class.
* $this: for methods returning the current instance of the class.
* void: for methods with a explicit empty "return" statement.

Also, there are some basic rules about how to use those types:

* We use [http://php.net/manual/en/language.types.type-juggling.php short type names] (bool instead of boolean, int instead of integer).
* When multiple occurrences of a given "type" are used, it's highly recommended to document them as type[] instead of the simpler and less informative "array" alternative.
* When multiple different types are possible, they must be separated by a vertical bar (pipe).
* All primitives and keywords must be lowercase. The case of the complex types and classes must match the original.

===Tags===

==== @copyright ====

These include the year and copyright holder (creator) of the original file. Do not change these in existing files!

@copyright 2008 Kim Bloggs

==== @license ====

These must be GPL v3+ and use this format:

@license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later

==== @param ====

Don't put hyphens or anything fancy after the variable name, just a space.

@param [[#Types|type]] $name Description.

==== @return ====

The @return tag is mandatory if the function has a return statement, but can be left out if it does not have one.

The description portion is optional, it can be left out if the function is simple and already describes what is returned.

@return [[#Types|type]] Description.

==== @var ====

The @var tag is used to document class properties.

@var [[#Types|type]] Description.

Exceptionally, when none of the available [[#Types|type]] define the returned value, inline @ var phpdocs (within the body of the methods) are allowed clarifying the returned type. Don't abuse!

==== @uses ====

If a function uses die or exit, please add this tag to the docblock to help developers know this function could terminate the page:

@uses exit

==== @access ====

The access can be used to specify access control for an element

# Should only be used when the method definition does not already specify access control.
# In the case of functions, specifying public access is redundant and so should be avoided.

@access private

==== @package ====

The package tag should always be used to label php files with the correct [[Frankenstyle]] component name. Full rules are explained on that page, but in summary:

# If the file is part of any component plugin, then use the plugin component name (eg '''mod_quiz''' or '''gradereport_xls''')
# If the file is part of a core subsystem then it will be core_xxxx where xxxx is the name defined in get_core_subsystems(). (eg '''core_enrol''' or '''core_group''')
# If the file is one of the select few files in core that are not part of a subsystem (such as lib/moodlelib.php) then it just as a package of '''core'''.
# Each file can only be part of ONE package.

(We do not have standards for @subpackage at all. You can use within your @package how you like.)

@package gradereport_xls

==== @category ====

We use @category only to highlight the public classes, functions or files that are part of one of our [[Core APIs]], or that provide good example implementations of a Core API. The value must be one of the ones on the [[Core APIs]] page.

@category preferences

==== @since ====

When adding a new classes or function to the Moodle core libraries (or adding a new method to an existing class), use a @since tag to document which version of Moodle it was added in. For example:

@since Moodle 2.1

==== @see ====

If you want to refer the user to another related element (include, page, class, function, define, method, variable) then you can use @see.

@see some_other_function()

==== @link ====

If you want to refer the user to an external URL, use @link.

@link https://docs.moodle.org/dev/Core_APIs

==== inline @link ====

Occasionally you might want to refer to something else inline within your text, say in a function description. For these cases you can use an inline @link (with an element name OR a URL) and it looks like this:

/**
* This function uses {@link get_string()} to obtain the currency names...
* .....

==== @deprecated ====

When deprecating an old API, use a @deprecated tag to document which version of Moodle it was deprecated in, and add @todo and @see if possible. Make sure to mention relevant MDL issues. For example:

<syntaxhighlight lang="php">
/**
* ...
* @deprecated since Moodle 2.0 MDL-12345 - please do not use this function any more.
* @todo MDL-22334 This will be deleted in Moodle 2.2.
* @see class_name::new_function()
*/
</syntaxhighlight>

If it is important that developers update their code, consider also adding a debugging('...', DEBUG_DEVELOPER); call to repeat the deprecated message. If the old function can no longer be supported at all, you may have to throw a coding_exception. There are examples of the various options in lib/deprecatedlib.php.

==== @throws ====

This tag is valid and can be used optionally to indicate the method or function will throw and exception. This is to help developers know they may have to handle the exceptions from such functions.

===Files===

All files that contain PHP code should contain, without any blank line after the php open tag, a full GPL copyright statement at the top, plus a SEPARATE docblock right under it containing a:

# short one-line description of the file
# longer description of the file
# @package tag (required)
# @category tag (only when everything in the file is related to one of the [[Core APIs]])
# @copyright (required)
# @license (required)

<syntaxhighlight lang="php">
<?php
// This file is part of Moodle - http://moodle.org/
//
// Moodle is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// Moodle is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with Moodle. If not, see <http://www.gnu.org/licenses/>.

/**
* This is a one-line short description of the file.
*
* You can have a rather longer description of the file as well,
* if you like, and it can span multiple lines.
*
* @package mod_mymodule
* @category backup
* @copyright 2008 Kim Bloggs
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/
</syntaxhighlight>

===Classes===

All classes must have a complete docblock like this:

<syntaxhighlight lang="php">
/**
* Short description for class.
*
* Long description for class (if any)...
*
* @package mod_mymodule
* @copyright 2008 Kim Bloggs
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/
</syntaxhighlight>

(NOTE that classes that are fundamental to core APIs will also need a @category tag)

The exception are files containing only one class and nothing else. In that case the class is covered by the file docblock and adding an explicit class docblock is optional.

===Properties===

All properties should have a docblock with the following minimum information:

<syntaxhighlight lang="php">
class example {
/** @var string This variable does something */
protected $something;
}
</syntaxhighlight>
or
<syntaxhighlight lang="php">
class example {
/**
* This variable does something and has a very long description which can
* wrap on multiple lines
* @var string
*/
protected $something;
}
</syntaxhighlight>
Even if there are several properties all sharing something in common, do not use [http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#basics.docblocktemplate DocBlock templates]. Instead, document every property explicitly as in the following example:

<syntaxhighlight lang="php">
class zebra {
/** @var int The number of white stripes */
protected $whitestripes = 0;

/** @var int The number of black stripes */
protected $blackstripes = 0;

/** @var int The number of red stripes */
protected $redstripes = 0;
}
</syntaxhighlight>

===Constants===

Class constants should be documented in the following way:

<syntaxhighlight lang="php">
class sam {
/**
* This is used when Sam is in a good mood.
*/
const MOOD_GOOD = 0;
}
</syntaxhighlight>

===Functions===

All functions and methods should have a complete docblock like this:

<syntaxhighlight lang="php">
/**
* The description should be first, with asterisks laid out exactly
* like this example. If you want to refer to a another function,
* use @see as below. If it's useful to link to Moodle
* documentation on the web, you can use a @link below or also
* inline like this {@link https://docs.moodle.org/dev/something}
* Then, add descriptions for each parameter and the return value as follows.
*
* @see clean_param()
* @param int $postid The PHP type is followed by the variable name
* @param array $scale The PHP type is followed by the variable name
* @param array $ratings The PHP type is followed by the variable name
* @return bool A status indicating success or failure
*/
</syntaxhighlight>

The exception is overridden methods not changing the purpose of the parent one, nor the meaning of the arguments or return values. In this case you should omit the comment completely. Use of the @inheritdoc or @see tags is explicitly forbidden as a replacement for any complete docblock.

===Defines===

All defines should be documented in the following way:

<syntaxhighlight lang="php">
/**
* PARAM_INT - integers only, use when expecting only numbers.
*/
define('PARAM_INT', 'int');

/**
* PARAM_ALPHANUM - expected numbers and letters only.
*/
define('PARAM_ALPHANUM', 'alphanum');
</syntaxhighlight>

===Inline comments===

Inline comments must use the "// " (2 slashes + whitespace) style, laid out neatly so that it fits among the code and lines up with it. The first line of the comment must begin with a capital letter (or a digit, or '...') and the comment must end with a proper punctuation character. Permitted final characters are '.', '?' or '!'.

<syntaxhighlight lang="php">
function forum_get_ratings_mean($postid, $scale, $ratings = null) {
if (!$ratings) {

$ratings = array(); // Initialize the empty array.

$rates = $DB->get_records('forum_ratings', array('post' => $postid));

// ... then process each rating in
// turn.
foreach ($rates as $rate) {
do_something_with($rate);
}

// Do we need to tidy up?
if (!empty($rates))
// 42 more things happen here!
finsh_up();
}
</syntaxhighlight>

GOOD:
<syntaxhighlight lang="php">
// Comment explaining this piece of code.
</syntaxhighlight>
BAD:
<syntaxhighlight lang="php">
/* Comment explaining this piece of code. */
# Comment explaining this piece of code.
// comment explaining this piece of code (without capital letter and punctuation)
</syntaxhighlight>

If your comment is due to some MDL issue, please feel free to include the correct MDL-12345 in your comment. This makes it easier to track down decisions and discussions about things.

====Using TODO====

This is especially important if you know an issue still exists in that code that should be dealt with later. Use a TODO along with a MDL code to mark this. For example:

<syntaxhighlight lang="php">
// TODO MDL-12345 This works but is a bit of a hack and should be revised in future.
</syntaxhighlight>

If you have a big task that is nearly done, apart a few TODOs, and you really want to mark the big task as finished, then you should file new tracker tasks for each TODO and change the TODOs comments to point at the new issue numbers.

(The script .../lib/simpletest/todochecker.php in Moodle 2.0 will check this. Requires an admin login. This is a new requirement, see MDL-19772)

===CVS keywords===

We have stopped using CVS keywords such as $Id$ in Moodle 2.0 completely.

==Exceptions==

Use exceptions to report errors, especially in library code.

Throwing an exception has almost exactly the same effect as calling print_error, but it is more flexible. For example, the caller can choose to catch the exception and handle it in some way. It also makes it easier to write unit tests.

Any exception that is not caught will trigger an appropriate call to print_error, to report the problem to the user.

Do not abuse exceptions for normal code flow. Exceptions should only be used in erroneous situations.

===Exception classes===

We have a set of custom exception classes. The base class is moodle_exception. You will see that the arguments you pass to new moodle_exception(...) are very similar to the ones you would pass to print_error. There are more specific subclasses for particular types of error.

To get the full list of exception types, search for the regular expression 'class +\w+_exception +extends' or ask your IDE to list all the subclasses of moodle_exception.

Where appropriate, you should create new subclasses of moodle_exception for use in your code.

A few notable exception types:
; moodle_exception : base class for exceptions in Moodle. Use this when a more specific type is not appropriate.
; coding_exception : thrown when the problem seems to be caused by a developer's mistake. Often thrown by core code that interacts with plugins. If you throw an exception of this type, try to make the error message helpful to the plugin author, so they know how to fix their code.
; dml_exception (and subclasses) : thrown when a database query fails.
; file_exception : thrown by the File API.

==Dangerous functions and constructs==
PHP includes multiple questionable features that are highly discouraged because they are very often source of serious security problems.

# do not use ''eval()'' function - language packs are exception (to be solved in future).
# do not use ''preg_replace()'' with /e modifier - use callbacks in order to prevent unintended PHP execution.
# do not use backticks for shell command execution.
# do not use ''goto'', neither the operator neither labels - use other programming techniques to control the execution flow.

==Policy about coding-style only fixes==

Way before this coding-style guide was defined and agreed, a lot of code had been written already. Obviously such code does not follow the coding-style at all. While '''we enforce conformance for all the new code''', we are not paranoid about the status of all the previous one.

In any case, in order to normalize the (progressive, non-critical) transition, a policy issue (MDL-43233) was created and agreed about. And these are the rules to apply to coding-style only changes:

# Related coding-style changes (same lines, a variable within a method/function, adjacent comments...) within a real issue are allowed.
# Unrelated coding-style changes (other methods, blocks of code, comments...) within a real issue are only accepted for main and in a separate commit.
# Coding-style only issues are only accepted for main along the first 2 months of every cycle.

== Git commits ==

Constructing a clear and informative commit is an important aspect of the craft of creating open source code and the history of commits is a vital part of the communication between developers. Time should be spent on crafting commits appropriately and using the git tools to achieve it.

Git commits should:

* Tell a perfect, cleaned up version of the history. As if the code was written perfectly first time.
* Include the MDL-xxxx issue number associated with the change
* Include CODE AREA when appropriate. (Code area, is just a short name for the area of Moodle that this change affects. It can be a component name if that makes sense, but does not have to be.)
* Be formatted as:
<pre>
MDL-xxxx CODE AREA: short summary (72 chars soft limit)

Blank line on line 2, followed by an unlimited length detailed explanation
following if necessary. This section might include the motivation for the change
and contrast it with the previous behaviour.
</pre>

Git commits should not:
* Include changes from bugs found and fixed before integration
* Include many separate revisions to the same lines of code for a single issue
* Arbitrarily split when part of a atomic set of logical changes

For more guidance, see [[Commit cheat sheet]]

==Credits==

This document was drawn from the following sources:

# The original [https://docs.moodle.org/en/index.php?title=Development:Coding&oldid=53799 Coding guidelines] page
# The [http://framework.zend.com/manual/en/coding-standard.html Zend guidelines] and
# Feedback from all core Moodle developers

==See also==

* [[Javascript/Coding_style|Javascript coding style]]
* [[SQL coding style]]
* [[Coding]]
* [[CodeSniffer]]
* [http://moodle.org/plugins/view.php?plugin=local_codechecker Code Checker plugin]
* [[Accessibility#Moodle-related_accessibility_coding_guidelines|Accessibility coding guidelines]]

[[Category:Coding guidelines|Coding style]]

String API

2024-04-10T11:13:13Z

Stronk7: master2main

==Overview==
The String API is how you get language text strings to use in the user interface. It handles internationalisation issues, and will use a number of settings and environment variables to present the best text to every user. Moodle has a mechanism that allows a number of places to be searched (in order) to find language strings. This enables language strings to be packaged with plugins and avoids the step of having to copy the language files over to the language directory when a plugin is installed.

Moodle also provide general string functions like substr, strlen etc. for multibyte safe, string operations. It uses mbstring or iconv for UTF-8 strings and falls back to typo3.
==Basic concepts==
When it is required to lookup a string, two basic items of information are required.
# The component providing the string.
# The identifier of the string.
Example: The function call <tt>get_string('editingquiz', 'mod_quiz')</tt> will return "Editing quiz" if the current language is English, or relevant translation of the text. Here the string identifier is "editingquiz" and the string is provided by the "mod_quiz" component (that is the Quiz activity module).
===Adding language file to plugin===
Language support for plugin(s) is added by creating a '''lang/en/''' subdirectory in the plugin directory and putting the plugin's English string file there. The name of the string file is supposed to follow the plugin's [[Frankenstyle|component name]], so that it is something like <tt>plugintype_pluginname.php</tt>.

The default "en" language is the [[:en:Language FAQ#Which_is_the_official_language_for_Moodle.3F|Australian English]] which is same as the British English when it comes to spelling and grammar. American English is a separate language pack "en_us".

There is no need to include languages other than the default English, as almost all approved [https://lang.moodle.org/mod/forum/discuss.php?d=2485 plugin strings will be automatically imported into AMOS] for translation by the language packs translators.
===Adding a string to the language file===
Strings are defined via the associative array <tt>$string</tt> provided by the string file. The array key is the string identifier, the value is the string text in the given language.
<syntaxhighlight lang="php">
$string['editingquiz'] = 'Editing quiz';
$string['editingquiz_help'] = 'Help for editing quiz';
</syntaxhighlight>
===Run-time parameters===
Strings can define placeholders like <tt>{$a}</tt> or <tt>{$a->foobar}</tt>. These placeholders are replaced with a value passed to the <tt>get_string()</tt> function call.
<syntaxhighlight lang="php">
// Strings defined in the language file.
$string['greeting'] = 'Dear {$a}';
$string['info'] = 'There are {$a->count} new messages from {$a->from}.';

// Passing values for the placeholders.
echo get_string('greeting', 'tool_example', 'Mr. Anderson');
echo get_string('info', 'tool_example', ['count' => 42, 'from' => 'Mr. Smith']);
</syntaxhighlight>
== Help strings ==
Help strings are texts that are displayed in the help tooltips. There are certain conventions on how to define them.
[[Image:Roles help popup.png|thumb|Help popup containing "More help" link]] Help strings names start with the string name of the setting to which they apply, so that they are kept together in the language file.
* ''stringname'' - identifier of the string we provide the help for, may be used as a title of the help popup
* ''stringname_help'' - string with the help text
* ''stringname_link'' - an optional string naming a path in Moodle Docs, only if required, calculated just like the link in the footer to go to the right language etc, and shown after the help text in the popup as a link with an icon to "More help...". These strings don't usually need to be translated. (They were previously hidden in the AMOS UI then unhidden in 2023. See MDLSITE-7236 for details.)
* ''stringname_desc'' - an admin setting description replacing the legacy ''configstringname''
Example:
<syntaxhighlight lang="php">
$string['submissionsize'] = 'Submission size';
$string['submissionsize_help'] = 'Blah blah blah some useful text, optionally using Markdown syntax';
$string['submissionsize_link'] = 'mod/workshop/submission';
$string['submissionsize_desc'] = 'Default value for submission size. This value will be pre-filled and can be blah blah ...';
</syntaxhighlight>
Help string text should be short and simple - two small paragraphs maximum with no headings, no links, no bold, no tables etc.

[[:en:Markdown|Markdown]] can be used for some basic formatting of strings with the "_help" suffix. It is recommended to stick to paragraphs and lists only. Markdown can only be used for help strings, not for other language strings.
=== More help links ===
To display the optional ''More help...'' link at the bottom of the help popup, a string with the "_link" suffix must exist beside the relevant "_help" string. These link strings should consist of a short relative path like 'component/thing' (eg. 'mod/folder/view' or 'group/import'). This gets turned into a link to MoodleDocs in the user's language, and for the appropriate Moodle version.

Example:
<syntaxhighlight lang="php">
$string['groupimport_link'] = 'group/import';
</syntaxhighlight>
will make a link to something like <nowiki>'https://docs.moodle.org/32/en/group/import'</nowiki> (if you are an English user of Moodle 3.2). This page in turn should be a redirect page to the actual page providing the info. Note the <nowiki>'https://docs.moodle.org'</nowiki> part comes from $CFG->docroot.

The second option is that you can give an absolute link, if you want, and that will be used unmodified.
<syntaxhighlight lang="php">
$string['patronising_link'] = <nowiki>'http://lmgtfy.com/?q=Moodle+for+dummies';</nowiki>
</syntaxhighlight>
This case is detected by seeing if the string starts with <nowiki>http:// or https://</nowiki>. This option is useful if the documentation for your plugin is hosted at Github wiki, for example.

The third option is to start the link with <tt>%%WWWROOT%%</tt>. That is replaced by <tt>$CFG->wwwroot</tt>. This is useful for contributed plugins that want to keep the help within the plugin.
=== Words for roles ===
The following words should be used in the English (en) help strings whenever it is necessary to refer to people with particular roles in a generic sense.
* Participants - all people with a role
* Teachers - people with some sort of a facilitation/editing role
* Students - people primarily there to learn
* Users - people across the site
([[User:Martin Dougiamas|Martin Dougiamas]] 16:13, 20 April 2010 (UTC): I'm not entirely comfortable with this choice even though I just re-confirmed it, as I'd prefer to be using words like facilitator/moderator to subtly and continually promote a less transmissionist pedgagogy and I know many Moodle users would agree. However, I think these terms are far more commonly used in the community and in discussion, and from the point of view that we need to build a consistent system for usability they are less distracting and better for documentation.)

==Files==
String functions are defined in
# lib/moodlelib.php - locale related functions
# lib/textlib.class.php - general string functions (substr, strlen etc.)
==Functions and examples==
There are three main functions, used in moodle for getting/displaying the localised string, based on user preferred language.
===get_string()===
Returns a localised string for current user.

Example for displaying string "This is my plug-in" in any language that supports on your site, then you need to use the following identifier in language file (located in appropriate lang directory)
$string['plugintitle'] = 'This is my plug-in';
If you want to display this string in any supported language, then you would use this function.
echo get_string('plugintitle', 'module_pluginlangfilename');
If you want to substitute value in the language string then use '''{$a}''' for substituting value. $a is an object, string or number that can be used within translation strings. The variable has to be $a, and it has to be in single quotes. For example, if you want to display answer number in Drag & drop plugin then add
$string['answerno1'] = 'Answer {$a}'; //Substituting string/integer
$string['answerno2'] = 'Answer {$a->name}'; //Substituting object member
in qtype_dragdrop.php (Drag & Drop language file). And call it using
//Get string by substituting integer.
get_string('answerno1', 'qtype_dragdrop', $number);
//Get string by substituting object member integer
$user->number = 10;
get_string('answerno2', 'qtype_dragdrop', $user);
In Moodle 2.3 there is a new argument to this function $lazyload. Setting $lazyload to true causes get_string to return a lang_string object rather than the string itself.
$stringobject = get_string('answerno', 'qtype_dragdrop', $number, true);
The fetching of the string is then put off until the string object is first used. The object can be used by calling it's out method or by casting the object to a string, either directly e.g.
(string)$stringobject
or indirectly by using the string within another string or echoing it out e.g.
echo $stringobject;
return "<p>{$stringobject}</p>";
Note: using $lazyload and attempting to use the string as an array key will cause a fatal error as objects cannot be used as array keys.
===get_strings()===
Converts an array of string names to localised strings for a specific plugin. lazy loading is not supported in this function.
$txt = get_strings(array('enable', 'disable', 'up', 'down', 'none'), 'qtype_dragdrop');
echo $txt->up; //Display localised string for up
echo $txt->down //Display localised string for down
===print_string()===
Prints out a translated string by using '''get_string()''' function
===lang_string class===
In Moodle 2.3 a special class (lang_string) is used to create an object representation of a string request. In this case string processing doesn't occur until the object is first used. The class was created especially to aid performance in areas where strings were required to be generated but were not necessarily used. As an example the admin navigation tree when generated uses over 1500 strings, of which normally only 1/3 are ever actually printed at any time. The performance advantage is achieved by not actually processing strings that aren't being used, as such reducing the processing required for the page.

lang_string class can be used in two ways
# Setting $lazyload (fourth argument of the get_string function), to true.
$string = get_string('yes', 'qtype_dragdrop', null, true);
# Direct instantiation
$string = new lang_string('yes', 'qtype_dragdrop', null, 'en');
== String manager ==
Most of function listed above are just handful wrappers for the methods provided by the string manager class. Some strings related functionality is available only via directly calling the manager's methods.
<syntaxhighlight lang="php">
$stringman = get_string_manager();
</syntaxhighlight>
The factory function get_string_manager() returns singleton instance of <tt>core_string_manager_install</tt> in early stages of the site installation, or instance of <tt>core_string_manager_standard</tt> in all normal situations. These managers implement interface <tt>core_string_manager</tt>. Methods provided by the interface are
;get_string():Returns the given component string localised in the given language. Can be used to obtain the translation of the string in the other language than the current user's language.
;string_exists():Does the given string actually exist? This is typically checked by a code like
<syntaxhighlight lang="php">
if (get_string_manager()->string_exists('stringidentifier', 'component_name')) {
// Do something.
}
</syntaxhighlight>
;string_deprecated():Has the string been deprecated? See [[String deprecation]] for details.
;get_list_of_countries():Returns a localised list of all country names, sorted by country keys.
;get_list_of_languages():Returns a localised list of languages, sorted by code keys.
;translation_exists():Checks if the translation exists for the given language.
;get_list_of_translations():Returns localised list of installed language packs.
;get_list_of_currencies():Returns localised list of known currencies.
;load_component_strings():Loads all strings for one component.
;reset_caches():Invalidates all caches, should the manager use some.
;get_revision():Returns string revision counter.
=== Custom string managers ===
{{Moodle 2.9}}Plugins can provide custom implementation of the string manager. This is supposed to be used in experimental and/or development scenarios only, not in typical production environment. See MDL-49361 for use cases and implementation details. An example of such an implementation can be found at [https://github.com/mudrd8mz/moodle-local_stringman moodle-local_stringman.git] repository.
<syntaxhighlight lang="php">
// Custom string manager class can be defined in the main config.php file.
$CFG->customstringmanager = '\local_stringman\dummy_string_manager';
</syntaxhighlight>
==textlib (core_text) class==
textlib class provide pool of safe functions to operate on UTF-8 text. textlib provide set of static functions to operate on strings and gets included in setup.php

{{Moodle 2.6}}In Moodle 2.6 the textlib class was renamed to '''core_text'''.
===asort()===
Locale aware sorting, the key associations are kept, values are sorted alphabetically.
===code2utf8===
Returns the utf8 string corresponding to the unicode value
===convert===
Converts the text between different encodings. It uses iconv extension with //TRANSLIT parameter, fall back to typo3
===encode_mimeheader===
Generate a correct base64 encoded header to be used in MIME mail messages.
===entities_to_utf8===
Converts all the numeric entities &#nnnn; or &#xnnn; to UTF-8
===specialtoascii===
Converts upper unicode characters to plain ascii, the returned string may contain unconverted unicode characters.
===strlen===
Multibyte safe strlen() function, uses iconv for utf-8, falls back to typo3.
===strpos===
Find the position of the first occurrence of a substring in a string. UTF-8 ONLY safe strpos(), uses iconv.
===strrpos===
Find the position of the last occurrence of a substring in a string. UTF-8 ONLY safe strrpos(), uses iconv.
===strtolower===
Multibyte safe strtolower() function, uses mbstring, falls back to typo3.
===strtotitle===
Makes first letter of each word capital - words must be separated by spaces.
===strtoupper===
Multibyte safe strtoupper() function, uses mbstring, falls back to typo3.
===substr===
Multibyte safe substr() function, uses iconv for utf-8, falls back to typo3.
===trim_utf8_bom===
Removes the BOM from unicode string. [http://unicode.org/faq/utf_bom.html more info]
===utf8_to_entities===
Converts all Unicode chars > 127 to numeric entities &#nnnn; or &#xnnn;
==FAQ==
===When should I use a lang_string object?===
The lang_string object is designed to be used in any situation where a string may not be needed, but needs to be generated. The admin navigation tree is a good example of where lang_string objects should be used. A more practical example would be any class that requires strings that may not be printed (after all classes get renderer by renderers and who knows what they will do ;))
===When should I not use a lang_string object?===
Don't use lang_strings when you are going to use a string immediately. There is no need as it will be processed immediately and there will be no advantage, and in fact perhaps a negative hit as a class has to be instantiated for a lang_string object, however get_string won't require that.
===Limitation of lang_string===
lang_string object cannot be used as an array offset. Doing so will result in PHP throwing an error. (You can use it as an object property!)
===How to compare strings properties in two object===
collatorlib_property_comparison class can be used to compare properties of two objects
===Should the colon sign be hard-coded or included in a language string?===
The colon sign should not be hard-coded because languages may use a different symbol, or have a space before or after the colon sign. Instead, the colon sign may be included in a language string, though please consider first if it is really necessary. A colon sign in a field label is not recommended. (MDL-12192 is for removing existing hard-coded colon signs.)<syntaxhighlight lang="php">
// Do NOT hard code any punctuation:
$string['fieldname'] = 'Name';

echo get_string('fieldname', 'mod_foobar') . ': ' . $somevalue;

// Slightly better with no hard coded colon:
$string['fieldname'] = 'Name: ';

echo get_string('fieldname', 'mod_foobar') . $somevalue;

// Better with no assumed word order:
$string['fieldname'] = 'Name: {$a->name}';

echo get_string('fieldname', 'mod_foobar', ['name' => $somevalue]);

</syntaxhighlight>

===Changing or creating a new lang string?===
New strings were required in 1.x times when we did not have branches for translations. Since 2.0, for changes in main, structural and/or semantic modification of a string (such as adding or removing {$a} placeholders etc) is acceptable as such strings are highlighted in AMOS as outdated. Of course, if lang pack maintainers do not pay attention to it, mismatch can happen - but this is considered to be the lang pack bug.

When a new string is introduced, the old one should be [[String deprecation | deprecated or removed]] so that unused strings do not accumulate.
:A) Basically I see it as (for main only issues):
:
:# Any change is allowed (semantic or structural). It does not have sense to keep the old string because there won't be use for it when the new Moodle version is released. So we can forget about the old one 100%. Of course if the string is radically different, then it may have sense to create a new, completely different string (and proceed with next point).
:# If for any reason we stop using any string (because a feature is out or because we have decided to create a new different string instead of change existing)), then:
:#* if the old string is really specific (not suitable for reuse) we can safely proceed to delete it,.
:#* If the string belongs to a plugin, IMO we can also proceed to delete it (reuse of plugin strings should not be allowed).
:#* But, if the string is generic (may be reused) and it's not part of a plugin then the string must be deprecated.

:B) And, for issues involving stables, only small semantic changes are allowed. No structural, no deprecation and no deletion. Ever. If still something different must be shown it will be, always, via new string. When applied to main, these changes will also imply the [[String deprecation | standard old string deprecation]]. No CPY instruction will be performed between the old and the new strings (safest, easier, consistent behavior, no matter there are some cases where the instruction may be acceptable. Stop overthinking. Now!).
===User names placeholders===
Some strings may contain placeholders to display the user's name. Common examples include various email templates or welcome messages. Developers may be tempted to use just the user's firstname in such cases, to make the text feel informal and friendlier:
<syntaxhighlight lang="php">
// Do NOT do this.
$string['welcome'] = 'Hello {$a}! Welcome to the course.';
</syntaxhighlight>
But some cultures or institutions may want the full name or last name to be used, rather than the first name. To enable sites to easily customise such strings and have lastname and alternatename placeholders available, the following pattern should be used.

Let the language strings file for the given component define the default display of the name:
<syntaxhighlight lang="php">
$string['welcome'] = 'Hello {$a->firstname}! Welcome to the course.';
</syntaxhighlight>
Then in the file making use of the string:
<syntaxhighlight lang="php">
$namefields = [
'fullname' => fullname($USER),
'alternativefullname' => fullname($USER, true),
];

foreach (\core_user\fields::get_name_fields() as $namefield) {
$namefields[$namefield] = $USER->{$namefield};
}

echo get_string('welcome', 'xyz_component', $namefields);
</syntaxhighlight>
That way, the string can be locally customised and use any combination of the following placeholders as needed: firstnamephonetic, lastnamephonetic, middlename, alternatename, firstname, lastname, fullname and alternativefullname.
<syntaxhighlight lang="php">
// Locally customised variant of the string.
$string['welcome'] = 'Welcome to the course, {$a->fullname}';
</syntaxhighlight>
==See also==
* [[Output_functions]]
* [[Core APIs]]
* [[AMOS]]
* The section 'Language strings' in [[Coding style]]
* [[String deprecation]]
* [[Improving English language strings]]
[[Category:API]]
[[Category:Language]]

Commit cheat sheet

2024-04-10T11:11:38Z

Stronk7: master2main

You can consider this page as a list to check before you submit a patch for inclusion into Moodle.

== Split your work into a logical set of patches ==

Keep in mind that your commits will be reviewed before they are accepted. If the patch does one clear thing and does it well, the review process is fun. Git allows you to prepare patches on your branch into a sequence of logical steps. For example, when changing some API, divide the change into two steps. In the first commit, change the API. In the following commit, change all places that use the API. <tt>git rebase -i</tt> is one of the commands you can use to do this.

== Provide clear commit messages ==

Consider the commit message as an email for the developer who would explore the change in the future. We recommend to follow common Git guidelines for formatting. The first line of commit message is generally treated as commit subject and should not exceed 72 characters. Include the MDL issue number and the area/component at the beginning of the subject line. Please note that 'code area' refers to the code areas being affected by this commit - correct the MDL's components reported against if needed. If you are writing more than one line, the second line must be empty. All the lines should though wrap at the 72nd mark. We can only hardly follow the [https://www.google.com/?q=git%2050/72%20rule 50/72 rule] in Moodle given the extra information expected at first (subject) line.

MDL-xxxxx code area: short description of the patch

The subject line is followed by an empty line and then a paragraph or two of
a longer description follows if necessary. This longer description is useful
for issues with longer history of comments in the linked MDL so that it
summarizes the patch without the need to go through the whole discussion.

Obviously, avoid messages like "as agreed in the chat" as they will become
useless after a relatively short time.

Most of Git tools are optimised for this format and they can display the log of commits best then.

::Tip: the command <tt>git log --no-merges</tt> will show you recent commit messages. Hopefully those are all good examples to copy.

== Names in the commit message ==

Retain the authorship of the patch. If the patch was submitted by someone else - for example a community member who published it in the tracker or in a forum - use the --author parameter. Make sure that your ''real'' name and contact email are recorded in patch. We use real names written in capital letters like "John Smith". Please do not use names like <strike>"john smith", "John S", "johnny7887"</strike>. If you use --author parameter, apply the same rules for the name of the author. See almost any Git tutorial on how to set your name and email in the global Git configuration.

=== Creating a commit with multiple authors ===

If your work is the result of collaborative work, you can use the [https://docs.github.com/en/github/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors github convention] to credit other authors.

Rebase all the commits into a single commit, and add the mention ''Co-authored-by: Firstname Lastname <email>'' at the end of the commit message. You must credit only one author per line. You don't need to add yourself in the commit message.

e.g. https://github.com/moodle/moodle/commit/fbb219617b5

== Provide clear and operational instructions to test your patch ==

In the tracker issue, please describe how the change can be tested. Please avoid vague phrases like "Make sure there is no regression in the core" or "Test all places where XXX is used". Also, try to avoid requiring resources that are really difficult to gather, if possible - as in "Use production data from a server with 100.000+ students".

If you have permission, edit the tracker issue and put the testing instructions into the "Testing instructions" field. If you do not have permission to edit that field, then write them in a comment on the tracker issue.

It helps if you state your estimation of the testing difficulty so that testers can pick issues for them:

;Easy : (average community member should be able to test it) - can be tested pretty easily via the web interface only at a public test site
;Moderate : (knowledgeable administrator should be able to test it) - requires local installation, for example to test some 1.9 -> 2.0 upgrade steps or some non-standard environment (for example MNet features, specific platform etc)
;Hard : (development skills are required to test it) - for example may require data hacking at SQL level to simulate data corruption or modifying the code to reproduce the problem

Example testing instructions:

(difficulty: easy, requires teacher access to a course)
1. Log in as a teacher and go to a course
2. Turn editing mode on
3. TEST: Make sure that the control icons appear next to the activity titles
4. Turn editing mode off
5. TEST: Make sure that the control icons are not displayed now

== Introducing new strings ==

Firstly, think twice and try to think in a non-English language. Any string you introduce is supposed to be translated by translators who usually do it for free in their own time. Do not waste their time by using get_string() for debugging messages that are likely to almost never appear. It is warmly recommended to let Helen review your strings before you submit them. This way we can keep the terminology and the style consistent. When introducing new strings, keep them alphabetically sorted. Using a self-descriptive names of the string identifier and the placeholder properties helps the translators to guess the context. Compare the following

<syntaxhighlight lang="php">
$string['grade'] = 'Grade {$a}';
</syntaxhighlight>

with

<syntaxhighlight lang="php">
$string['maxgradevalue'] = 'Grade {$a->value}';
</syntaxhighlight>

In the first case, it is pretty difficult to guess whether the "Grade" in the string is a noun (as in "Grade 12/30") or a verb (as in "Grade submission"). In many languages, the translation depends on it. The second case is more self-descriptive as it indicates that the placeholder will contain a value.

Another good example of how _not_ to name string identifiers would be something like

<syntaxhighlight lang="php">
$string['post'] = 'Post';
</syntaxhighlight>

Note that there is no clue if the "post" here is used as a noun (e.g. describing one particular forum post) or a verb (such as an action of posting into a forum). In many languages, the translation is different for either case.

See [[Help strings]] if you are introducing a new help string.

== Include AMOS script in the commit if needed ==

If you change the identifier of a string or split a string into two forks, provide a script for AMOS in the commit message. Since Moodle 2.0, the translations are kept on separated branches again. The AMOS plugin at http://lang.moodle.org tracks the changes in string files and automatically records modifications, additions and removals of strings. Therefore strings can be re-worded freely on stable branches and should be removed from the main branch if they are not needed any more (do not remove strings from stable branches).

If you change the identifier of the string (that is the key in the $string array), move the string from one file to another or you are introducing a new string as a copy of some current one, you should provide instructions for AMOS so that the action can be applied in all language packs. That will save valuable translators' time. Instructions for AMOS are being put into the commit message of a commit that modifies the original English string files. The commit message containing such a script may look like this:

MDL-xxxxx code area: short description of the patch<br />
It is recommended to leave a blank line between the commit message and the
script block.<br />
AMOS BEGIN
MOV [configfoobar,core_admin],[foobar_desc,core_admin]
CPY [submission,mod_assignment],[submission,mod_workshop]
AMOS END

See [[Automated_Manipulation_of_Strings_2.0#AMOS_script]] for more details of the syntax. See [http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=AMOS+BEGIN the log history] real examples of usage.

==Removing strings==

When a new feature completely replaces an existing feature, any strings which are no longer used should be removed from the code in the main branch. See [[String deprecation]] for more information.

== Main version changes ==

If your commit requires a change to the main version number in version.php (and corresponding upgrade in lib/db/upgrade.php), you should increment that version number by .01, and let integrators deal with merge conflicts (for example if multiple people that week submit several .01 updates).

(Note there may be policies about avoiding the type of changes which require version.php updates, especially in stable branches.)

[[Category:Git]]

Tracker issue versions

2024-04-10T11:05:49Z

Stronk7: master2main

Here there are some notes about how we handle both the affected and fix versions fields in the Tracker. To be applied along the whole [[Process]].

=== Some general and simple rules ===

* When '''filling "affected versions"''' (creating an issue or triaging it, usually) it's interesting to add there '''as many versions as possible''' (as far as they are affected, of course). And ideally not more than '''1 version by branch''' (i.e. don't put 3.6.1 and 3.6.2 together, the former alone is enough).
* When '''filling "fix versions"''' (usually as part of the integration process) a simple rule must be observed: '''"or stables or main"'''. Never mix them in the same issue. The idea beyond that is to avoid presenting in release notes for the next major release something that has been already fixed in the latest stable minor.

=== Must fix versions ===

Part of the process, some weeks before X.Y freeze, the corresponding "Must fix for X.Y" version is created. That version is critical to be able to detect, filter and organize all the issues that need to be fixed before release. Some important points about the handling of those "must fix" versions:
* They must be '''added to the "fix versions"''' field. That's their correct place (there is a [https://tracker.moodle.org/issues/?filter=20021 filter in charge of detecting wrong uses], in order to proceed to fix them).
* Once the issue is integrated, the "Must fix for X.Y" version '''must be removed'''.
* Once the release happens, there must be ZERO "must-fix" issues and '''the version is archived''' as part of the release process.
* Issues having a "must-fix" fix version '''must be given absolute priority''' within the process.

=== Regression versions ===

At the same time that a major X.Y version is packaged and released, its corresponding "X.Y regressions" version is created. That version is important to mark and track all the issues (on creation or triaging) that are a direct regression caused by the X.Y release. Some important points about the use of those "regression" versions:
* They must be '''added to the "affected versions"''' field. That's their correct place (there is a [https://tracker.moodle.org/issues/?filter=21627 filter in charge of detecting wrong uses], in order to proceed to fix them).
* They '''are not removed''' once an issue is fixed. They remain there, in the "affected versions" field, forever.
* Eventually, once a '''given X.Y version falls out of support''' and given that there are ZERO unresolved issues with a "X.Y regression" version, '''the version is archived'''.
* Issues having a "regressions" affected version '''should be given high priority''' within the process.

==See also==

* [[Tracker]]
* [[Bug triage]]
* [[Release process]]

[[Category:Tracker]]

Moodle versions

2024-04-10T11:03:55Z

Stronk7: master2main

==Moodle versions and branches==

Understanding the Moodle versioning scheme will help you when using our repositories to get your code (e.g. for an [[:en:Upgrading|upgrade]]). Knowing the correct versions is also very useful when reporting bugs in our [http://tracker.moodle.org tracker].

[[Image:versions.png|thumb|left|668px|Schema of Moodle source code branches, versions and maturity levels]]
<br clear="all" />

== Major and minor versions ==

Moodle version numbers consist of three numbers separated by a dot, for example 1.9.11 or 2.0.2. The first two numbers, like 1.9 or 2.0, represent the ''major version''. The third number distinguishes ''minor versions'' within the same major version. When a new major version is released, it starts with the minor version set to 0 (zero). So Moodle 2.0.1 was the first minor update of Moodle 2.0.0.

Generally, the Moodle HQ team maintains the two most recent major versions of Moodle (a notable exception to the rule was for Moodle 1.9 which was supported much longer).

== Versions and branches ==

Moodle developers use the source code management (SCM) system ''''Git'''' to track changes in the code. As in many SCMs, the history of changes in Git is represented via so called branches. You can consider a branch as a labeled sequence of source code changes.

There is a branch created for every major version of Moodle. All Moodle 1.9 versions come from MOODLE_19_STABLE branch and all Moodle 2.0 versions come from MOODLE_20_STABLE branch. There is also a main development branch called "main" that holds the changes for the next future version. At the moment, the changes on the main branch will be included in Moodle 2.1 release.

== Releases ==

Since version 2.0, Moodle aims to release the new major version every six months or so. See [[Roadmap]] page for a schedule.

Minor versions are released every two months, including both bugs and security issues fixed. See [[Releases#General release calendar|Releases]] page for more details and information.

In the meantime between two releases, Moodle HQ team publish updates for the most recent stable versions. These updates are published every week, usually on Thursday. They are known as ''weekly builds'' and are identified by a small increment in the version and a build date like [https://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=d8b0be3eb38b8b7991af470776cfb15d30d43de6 20200723]. That is a timestamp in a form YYYYMMDD when the weekly build was released. These weekly builds are labelled with a version number suffixed with a plus sign. So 3.9.1+ denotes some weekly build extending the 3.9.1 minor release.

== Source code maturity levels ==

During its life cycle, the Moodle code branch goes through several maturity levels.
* At the beginning, the branch is considered as being in ''alpha'' state. During this period, new features are added to the branch. API and database structure may change as needed. These versions are intended mainly for developers as nothing is guaranteed (the version may or may not install and upgrade, for example).
* When it is decided that no new feature will be added to the branch (so called feature freeze), ''beta'' maturity level is reached. Developers focus on testing, bugs fixing and stabilizing the branch.
* When all known critical and blocker bugs are fixed and no new bugs are reported for some time of testing, a preview version of the branch can be released as so called release candidate. When the first release candidate version (RC1) has been published, ''release candidate'' maturity level is reached. During this period, several RC versions can be issued, for example 2.1RC1, 2.1RC2, 2.1RC3 etc.
* Finally, the new major version is released and the branch reaches ''stable'' maturity level. From now on, the database structure and API do not change on this branch. A corresponding MOODLE_xx_STABLE is created and minor versions and weekly builds are created off it.

==Version numbers==

Each plugin's version.php file can specify a minimum version of Moodle required for the plugin to work, for example

$plugin->version = 2011080200;
$plugin->requires = 2011070101;

For the version numbers related to each release, see the [[Releases]] page.

==How to increment version numbers in core==

In Moodle core, when we branch from main, we also branch version numbers. That means that no version number in a stable branch should ever be higher than on main (or a higher branched version).

The version number is constructed as '''YYYYMMDDRR.XX'''.

* '''YYYYMMDD''' is the date of the branching point. If on main, a branch has not happened, so it should be set to the current date. Otherwise it should not be changed (left as it was)
* '''RR''' is the release increment. This is the incremental counter for changes on a single branch or day (if in main).
* '''XX''' is the micro increment. This 'fraction increment' was introduced when after we realised that it might be possible to have more than 99 upgrade steps on a stable branch (in the RR increment). It tends to only be used in the main version number file.

===Rules for stable branches===

* If a 'micro increment' (.XX) exists
** Developers should only increment the 'micro increment' 'XX'
** The integration team reserve the use of 'RR' to branch between point releases.
* If a 'micro increment' (.XX) does not exist
** Please increment the RR.

===Rules for main===
* You must increment the whole version number to the current date.
* So, on 6th February 2013, the version number is set to: '''2013020600.00'''

===Why we branch versions ===
Imagine the following problem scenario:
# Moodle 2.4 is released, mod_forum is set to version 2012120300
# In main only, Eloy updates drops a DB field in an upgrade step and sets the moodle version to 2013010100
# In 2.4.1 and main, Dan fixes a problem in a capability definition and sets the version in both branches to 2013010200. (note: Oh no! we've incorrectly changed the branching date for the entire future 2.4.x!)
# Moodle 2.5 is released and the mod_forum is set to version 2013060100
# After the release, Helen updates her Moodle from Moodle 2.4.1 to 2.5.

The implications of Dan changing the 2.4.x version to 2013010200 in step 3, means that Eloy's upgrade step from 2 will never get run. '''This is very bad!'''

===I know that there are no changes between STABLE and main, can I set the version number as the same? ===
Not for core plugins, sorry. There are too many developers working on the same code and it prevents accidents if we avoid doing this for core.

== See also ==

* [[Releases]]
* [[:en:Git for Administrators|Git for Administrators]]
* http://download.moodle.org

[[es:Versiones de Moodle]]

Maintaining Moodle customisations with Git

2024-04-10T11:00:33Z

Stronk7: master2main

{{draft}}

Git makes it very easy to maintain local customisations to Moodle alongside updates from the official Moodle repository.
This page assumes you installed Moodle following [[Installing Moodle from Git repository]]. It also assumes you understand basic version control principles (repositories, branches, conflicts) and have a basic working knowledge of Git.

First, from your moodle directory, create a branch of <tt>main</tt> which will contain your customised Moodle. This is the branch you'll publish to other servers.
git checkout main
git checkout -b mycustommoodle

Switched to a new branch 'mycustommoodle'
Next, create a new branch for developing your customisation, and move to that branch:
git checkout -b myfeature

Switched to a new branch 'myfeature'
This will give you a seperate copy of the Moodle code to work on without affecting the main branch. It's not recommended that you do this on your production server, as it will cause the code to be available immediately as it's saved.

Do your customisations, add any new files to git, and commit the changes
git add .
git status
git commit -m "Description of the change"

Switch back to the <tt>mycustommoodle</tt> branch and merge the changes
git checkout mycustommoodle
git merge myfeature
Any future development can take place on the myfeature branch, and be merged into mycustommoodle in this way

Even after local modifications have been made, you can pull in updates from the official git repository
git checkout main
git fetch
git merge origin/main
git checkout mycustommoodle
git merge main

=== Conflicts ===
If you create a local modification to a file, and that same file is modified in the official repository, you may find that a conflict is created when you do <tt>git merge origin/main</tt>.

To resolve this, you will need to find the conflicts (the attempt to merge will tell you where they are) and resolve them. The [http://www.kernel.org/pub/software/scm/git/docs/git-merge.html|<tt>git merge</tt> man page] has more information on the presentation and resolution of conflicts.

After the conflict is resolved, you'll need to commit the resolved files.
git commit -a
Once a conflict has been resolved, even if you keep your local modification over the upstream modification, there wont be a conflict next time you merge.

== See also ==
; Moodle forum discussions
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [http://moodle.org/mod/forum/discuss.php?d=165236 Best way to manage CONTRIB code with GIT]
* [http://moodle.org/mod/forum/discuss.php?d=167063 Handy Git tip for tracking 3rd-party modules and plugins]
* [http://moodle.org/mod/forum/discuss.php?d=167730 Moodle Git repositories]

; External resources
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday GIT With 20 Commands Or So]
* [http://gitref.org/ Git Reference]
* [http://progit.org/book/ Pro Git book]

[[Category:Git]]

Writing PHPUnit tests

2024-03-25T15:26:35Z

Stronk7: (amend commitid)

{{Moodle 2.3}}

Moodle PHPUnit integration is designed to allow easy adding of new tests. At the start of each test the state is automatically reset to fresh new installation (unless explicitly told not to reset).
=Namespaces=
All the stuff under **/tests directories is [[Coding style#Namespaces_within_.2A.2A.2Ftests_directories|subject to some simple rules]] when using namespaces. They apply to test cases, fixtures, generators and, in general, any class within those directories. Take a look to them! (grand summary = 100% the same rules that are applied to **/classes directories).
=Testcase classes=
There are three basic test class that are supposed to used in all Moodle unit tests - basic_testcase, advanced_testcase and provider_testcase. '''Please note it is strongly recommended to put only one testcase into each class file.'''
;basic_testcase : Very simple tests that do not modify database, dataroot or any PHP globals. It can be used for example when trying examples from the official PHPUnit tutorial.
;advanced_testcase : Enhanced testcase class enhanced for easy testing of Moodle code.
;provider_testcase: Enhanced testcase class, enhanced for easy testing of [[Privacy API|Privacy Providers]].
There is a fourth testcase class that is specially designed for testing of our Moodle database layer, it should not be used for other purposes.
== Assertions ==
The complete list of assertions can be found in the links below.
{| class="wikitable" border="1"
|-
! Moodle version
! PHPUnit version
!Links
|-
| Moodle 3.11
| PHPUnit 9.5
|[https://phpunit.readthedocs.io/en/9.5/assertions.html Documentation]
|-
| Moodle 3.10
| PHPUnit 8.5
|[https://phpunit.readthedocs.io/en/8.5/assertions.html Documentation]
|-
| Moodle 3.7 - 3.9
| PHPUnit 7.5
|[https://phpunit.readthedocs.io/en/7.5/assertions.html Documentation]
|-
| Moodle 3.4 - 3.6
| PHPUnit 6.5
|[https://phpunit.de/manual/6.5/en/assertions.html Documentation]
|}
==Sample plugin testcase==
PHPUnit tests are located in <tt>tests/*_test.php</tt> files in your plugin, for example <tt>mod/myplugin/tests/sample_test.php</tt>, the file should contain only one class that extends <tt>advanced_testcase</tt>:
<syntaxhighlight lang="php">
namespace mod_myplugin;

class sample_test extends \advanced_testcase {
public function test_adding() {
$this->assertEquals(2, 1+2);
}
}
</syntaxhighlight>
See [[PHPUnit integration#Class and file naming rules]] for more information.
==Inclusion of Moodle library files==
If you want to include some Moodle library files you should always declare '''global $CFG'''. The reason is that testcase files may be included from non-moodle code which does not make the global $CFG available automatically.
==Automatic state reset==
By default after each test Moodle database and dataroot is automatically reset to the original state which was present right after installation. make sure to use $this->resetAfterTest() to indicate that the database or changes of standard global variables are expected.

If you received the error "Warning: unexpected database modification, resetting DB state" it is because the test is not using <tt>$this->resetAfterTest()</tt>.
<syntaxhighlight lang="php">
namespace mod_myplugin;

class test_something extends \advanced_testcase {
public function test_deleting() {
global $DB;
$this->resetAfterTest(true);
$DB->delete_records('user');
$this->assertEmpty($DB->get_records('user'));
}
public function test_user_table_was_reset() {
global $DB;
$this->assertEquals(2, $DB->count_records('user', array()));
}
}
</syntaxhighlight>
=Generators=
Tests that need to modify default installation may use generators to create new courses, users, etc. All examples on this page should be used from test methods of a test class derived from advanced_testcase.

Note if you are using PHPUnit [https://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.data-providers @dataProvider] functions to provide parameters to unit tests, you can not use the data generator or change the user etc in the data provider function. Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation.
==Creating users==
At the start of each test there are only two users present - guest and administrator. If you need to add more test accounts use:
<syntaxhighlight lang="php">
$user = $this->getDataGenerator()->create_user();
</syntaxhighlight>
You may also specify properties of the user account, for example:
<syntaxhighlight lang="php">
$user1 = $this->getDataGenerator()->create_user(array('email'=>'user1@example.com', 'username'=>'user1'));
</syntaxhighlight>
By default no user is logged-in, use setUser() method to change current $USER value:
<syntaxhighlight lang="php">
$this->setUser($user1);
</syntaxhighlight>
Guest and admin accounts have a shortcut methods:
<syntaxhighlight lang="php">
$this->setGuestUser();
$this->setAdminUser();
</syntaxhighlight>
Null can be used to set current user back to not-logged-in:
<syntaxhighlight lang="php">
$this->setUser(null);
</syntaxhighlight>
==Creating course categories==
<syntaxhighlight lang="php">
$category1 = $this->getDataGenerator()->create_category();
$category2 = $this->getDataGenerator()->create_category(array('name'=>'Some subcategory', 'parent'=>$category1->id));
</syntaxhighlight>
==Creating courses==
<syntaxhighlight lang="php">
$course1 = $this->getDataGenerator()->create_course();

$category = $this->getDataGenerator()->create_category();
$course2 = $this->getDataGenerator()->create_course(array('name'=>'Some course', 'category'=>$category->id));
</syntaxhighlight>
==Creating activities==
Some activity plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php.

Example of creation of new course with one page resource:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$generator = $this->getDataGenerator()->get_plugin_generator('mod_page');
$generator->create_instance(array('course'=>$course->id));
</syntaxhighlight>
The following is functionally the same, but a bit shorter:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$page = $this->getDataGenerator()->create_module('page', array('course' => $course->id));
</syntaxhighlight>
==Creating cohorts==
{{Moodle 2.4}}
Since 2.4 there the data generator supports creation of new cohorts.
<syntaxhighlight lang="php">
$cohort = $this->getDataGenerator()->create_cohort();
</syntaxhighlight>
==Simplified user enrolments==
{{Moodle 2.4}}
Instead of standard enrolment API it is possible to use simplified method in data generator. It is intended to be used with self and manual enrolment plugins.
<syntaxhighlight lang="php">
$this->getDataGenerator()->enrol_user($userid, $courseid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid, 'manual');
</syntaxhighlight>
==Creating scales==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_scale();
$this->getDataGenerator()->create_scale(array('name' => $name, 'scale' => $scale, 'courseid' => $courseid, 'userid' => $userid, 'description' => description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
==Creating roles==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_role();
$this->getDataGenerator()->create_role(array('shortname' => $shortname, 'name' => $name, 'description' => description, 'archetype' => $archetype));
</syntaxhighlight>
==Creating tags==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_tag();
$this->getDataGenerator()->create_tag(array(
'userid' => $userid,
'rawname' => $rawname,
'name' => $name,
'description' => $description,
'descriptionformat' => $descriptionformat,
'flag' => $flag
));
</syntaxhighlight>
==Groups==
===Creating groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group(array('courseid' => $courseid));
$this->getDataGenerator()->create_group(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding users to groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid));
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid, 'component' => $component, 'itemid' => $itemid));
</syntaxhighlight>
===Creating groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid));
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding groups to groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping_group(array('groupingid' => $groupingid, 'groupid' => $groupid));
</syntaxhighlight>
==Repositories==
===Creating repository instances===
{{Moodle 2.5}}
Some respository plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository($type, $record, $options);
</syntaxhighlight>
===Creating repository types===
{{Moodle 2.5}}
Some respository plugins include type generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository_type($type, $record, $options);
</syntaxhighlight>
==Creating grades==
===Grade categories===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid));
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid, 'fullname' => $fullname));
</syntaxhighlight>
===Grade items===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_item();
$this->getDataGenerator()->create_grade_item(array('itemtype' => $itemtype, 'itemname' => $itemname, 'outcomeid' => $outcomeid, 'scaleid' => $scaleid, 'gradetype' => $gradetype));
</syntaxhighlight>
===Outcomes===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_outcome();
$this->getDataGenerator()->create_grade_item(array('fullname' => $fullname));
</syntaxhighlight>
==Other types of plugin==
{{Moodle 2.5}}
Any other type of plugin can have a generator. The generator class should extend component_generator_base, and then you can get an instance using $mygenerator = $this->getDataGenerator()->get_plugin_generator($frankenstylecomponentname);

For some types of plugin, like mod documented above, there may be a more specific class than component_generator_base to extend, like testing_module_generator. That will give a consistent set of method names to use. Otherwise, you can create whatever methods you like on your generator, to create the different things you need to work whith.
=Long tests=
All standard test should execute as fast as possible. Tests that take a longer time to execute (>10s) or are otherwise expensive (such as querying external servers that might be flooded by all dev machines) should be execute only when PHPUNIT_LONGTEST is true. This constant can be set in phpunit.xml or directly in config.php.
=Large test data=
See advanced_testcase::createXMLDataSet() and advanced_testcase::createCsvDataSet() and related functions there for easier ways to manage large test data sets within files rather than arrays in code. See [[PHPUnit_integration#Extra_methods]]
=Testing sending of messages=
{{Moodle 2.4}}
You can temporarily redirect all messages sent via message_send() to a message sink object. This allows developers to verify that the tested code is sending expected messages.

To test code using messaging first disable the use of transactions and then redirect the messaging into a new message sink, you can inspect the results later.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
$sink = $this->redirectMessages();
//... code that is sending messages
$messages = $sink->get_messages();
$this->assertEquals(3, count($messages));
//.. test messages were generated in correct order with appropriate content
</syntaxhighlight>
=Testing sending of emails=
{{Moodle 2.6}}
You can temporarily redirect emails sent via email_to_user() to a email message sink object. This allows developers to verify that the tested code is sending expected emails.

To test code using messaging first unset 'noemailever' setting and then redirect the emails into a new message sink where you can inspect the results later.
<syntaxhighlight lang="php">
unset_config('noemailever');
$sink = $this->redirectEmails();
//... code that is sending email
$messages = $sink->get_messages();
$this->assertEquals(1, count($messages));
</syntaxhighlight>
=Logstores=
You can test events which were written to a logstore, but you must disable transactions, enable at least one valid logstore, and disable logstore buffering to ensure that the events are written to the database before the tests execute.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
set_config('enabled_stores', 'logstore_standard', 'tool_log');
set_config('buffersize', 0, 'logstore_standard');
get_log_manager(true);
</syntaxhighlight>
=Check your coverage=
{{Moodle 3.7}}
PHPUnit has the ability to generate code coverage information for your unit tests.

Prior to Moodle 3.7, this coverage would load all files and generate coverage for everything regardless of whether that file could be covered at all, or whether it was intentionally covered.

Since Moodle 3.7 the '''phpunit.xml''' configuration contains generated coverage include and exclude information for each component.
==Generating include and exclude configuration==
{{Moodle 3.11}}
You can programatically describe which files will be checked for coverage by creating a <tt>coverage.php</tt> file alongside the tests that you are writing.

Since Moodle 4.0, a default configuration is applied for all plugins and it is not necessary to supply a coverage.php unless you wish to cover additional files.

The <tt>coverage.php</tt> file allows you to list include and exclude files and folders within the component being
tested. All paths specified are relative to the component being tested. For example, when working with '''mod_forum''' your
code will be in '''mod/forum''', and its unit tests will be in '''mod/forum/tests/example_test.php'''. The coverage file
for this would be in '''mod/forum/tests/coverage.php''' and all paths specified would be relative to '''mod/forum'''.

It is possible to specify a combination of included files, included folders, excluded files, and excluded folders. This would allow you, for example, to include the entire '''classes''' directory, but exclude.a specific file or folder within it.

The following is an example <tt>coverage.php</tt> file from '''mod_forum''':

Note: For Moodle versions 3.7 to 3.10, the [https://docs.moodle.org/dev/index.php?title=Writing_PHPUnit_tests&oldid=58177#Check_your_coverage syntax used] was slightly different.
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'externallib.php',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
Also, note that you can better define which class or function each test is effectively covering by using the <tt>@covers</tt> annotation as [https://phpunit.readthedocs.io/en/9.5/code-coverage-analysis.html#specifying-covered-code-parts described in the documention].

Since Moodle 4.0, the following default configuration is applied:{{Moodle 4.0}}
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'tests/generator',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [
'externallib.php',
'lib.php',
'locallib.php',
'renderer.php',
'rsslib.php',
];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
If a coverage.php file already exists, then the defaults will be added to the values already defined.
=Best practice=
There are several best practices, suggestions, and things to avoid which you should consider when writing unit tests. Some of these are described below.
==Code coverage==
PHPUnit has the ability to generate code coverage information for your unit tests and this is well supported since.Moodle 3.7. We recommend that you consider checking the coverage of your plugins when you write your code.

We recommend that you explicitly set the @covers annotation as described in the [https://phpunit.readthedocs.io/en/9.5/annotations.html#appendixes-annotations-covers-tables-annotations PHPUnit documentation].
==Keep use of resetAfterTest to a minimum==
Although many of the examples described above use the <syntaxhighlight lang="php">resetAfterTest</syntaxhighlight> nomenclature to reset the database and filesystem after your test completes, you should ideally not use this unless you have to.
Generally speaking you should aim to write code which is mockable, and does not require real fixtures.
Use of resetAfterTest will also slow your tests down.
==Be careful with shared setUp and instance variables==
You should be careful of how you create and use instance variables in PHPUnit tests for two main reasons:
# If you create any fixtures in the setUp, or call the resetAfterTest function, these fixtures and conditions will apply for _all_ tests in the testsuite. You will not be able to add another test to the suite which does not require these conditions without those conditions being fulfilled anyway. This can lead to slow tests.
# PHPUnit creates an instance of each testcase during its bootstrap phase, and does not dispose of it for the lifetime of the test run. Anything which causes data to be stored as instance data within the testcase will be stored in memory until the _entire suite_ completes. This means that any fixture which is setup and not actively discarded will not be garbage collected and lead to memory bloat. In severe cases this can lead to memory exhaustion.

Existing testcases which contain setUp which either generate data, or set resetAfterTest should be phased out, and no new cases should be introduced.
==Make use of the dataProvider functionality==
The dataProvider functionality of PHPUnit is an extremely powerful and useful feature which allows you to verify a function quickly and easily with a range of different conditions.
However, the following rules should be followed when using dataProviders:
* Keep addition of resettable data requiring resetAfterTest to a minimum - this will lead to many slow tests
* Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation. The dataProvider is called after the testSuite is instantiated, but before any tests are run. Each test will run a full setUp and tearDown, which will destroy any data which was created.
<syntaxhighlight lang="php">
/**
* Test function accepts parameters passed from the specified data provider.
*
* @dataProvider foobar_provider
* @param int $foor
* @param int $bar
*/
public function test_foobar(int $foo, int $bar) {
// Perform the tests here.
}

/**
* Data provider for {@see self::test_foobar()}.
*
* @return array List of data sets - (string) data set name => (array) data
*/
public function foobar_provider(): array {
return [
'Same numbers' => [
'foo' => 42,
'bar' => 42,
],
'Different numbers' => [
'foo' => 21,
'bar' => 84,
],
];
}
</syntaxhighlight>
=Extra test settings=
Usually the test should not interact with any external systems and it should work the same on all systems. But sometimes you need to specify some option for connection to external systems or system configuration. It is intentionally not possible to use $CFG settings from config.php.

There are several ways how to inject your custom settings:
* define test setting constants in your phpunit.xml file
* define test setting constants in your config.php
These constants may be then used in your test or plugin code.
=Upgrading unit tests to work with Moodle 4.4 and up (PHPUnit 9.6)=
{{Moodle 4.4}}

With Moodle 4.4, '''PHPUnit was upgraded to 9.6''' (from 9.5 being used in previous versions). This was done to '''warn to developers in advance''' about functionality that has been deprecated in the 9.5 series and will be removed so will stop working with the next major update to PHPUnit 10.x (see MDL-81266 and linked issues for more details).

While everything should continue working without modification with PHPUnit 9.6, you will may get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be analysed''', replacing or removing them as soon as possible, because all those warnings will become errors with next PHPUnit upgrade.

A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/stronk7/moodle/commit/b2131ceff74da4c23928936f238d676a08e07d7f lib/upgrade.txt] file. With main points being:
* MDL-81281. A number of attribute-related assertions have been deprecated, will be removed with PHPUnit 10. Alternatives for '''some''' of them are available:
- assertClassHasAttribute()
- assertClassNotHasAttribute()
- assertClassHasStaticAttribute()
- assertClassNotHasStaticAttribute()
- assertObjectHasAttribute() => assertObjectHasProperty()
- assertObjectNotHasAttribute() => assertObjectNotHasProperty()
* MDL-81266. A number of deprecation, notice, warning and error expectations have been deprecated, will be removed with PHPUnit 10. No alternative exists. A working replacement is available in the linked issue, hopefully there aren't many cases.
- expectDeprecation()
- expectDeprecationMessage()
- expectDeprecationMessageMatches()
- expectError()
- expectErrorMessage()
- expectErrorMessageMatches()
- expectNotice()
- expectNoticeMessage()
- expectNoticeMessageMatches()
- expectWarning()
- expectWarningMessage()
- expectWarningMessageMatches()
* MDL-81308. The <tt>->withConsecutive()</tt> functionality on PHPUnit mocks has been '''silently''' deprecated, will be removed with PHPUnit 10. Note that this won't affect PHPUnit 9.6 runs and an alternative path will be proposed in the linked issue, part of the PHPUnit 10 epic.
* <tt>PHPUnit\Framework\TestCase::getMockClass()</tt> has been deprecated, will be removed with PHPUnit 10. No clear alternative exists and won't be investigated, because there aren't cases in core.
* Cannot use the <tt>Test</tt> suffix on abstract test case classes. Proceed to rename them to end with <tt>TestCase</tt> instead.

=Upgrading unit tests to work with Moodle 3.11 and up (PHPUnit 9.5)=
{{Moodle 3.11}}

With Moodle 3.11, '''PHPUnit was upgraded to 9.5''' (from 8.5 being used in previous versions). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.11 (7.3, 7.4 and [[Moodle and PHP|8.0]]) (see MDL-71036 and linked issues for more details).

While a lot of existing tests will work without modification with PHPUnit 9.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 9.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2020/02/migrating-to-phpunit-9 A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-9.html PHPUnit 9 release Announcement].
* These multiple detailed changelogs (because all them have included modifications requiring changes): [https://github.com/sebastianbergmann/phpunit/blob/9.0.0/ChangeLog-9.0.md 9.0], [https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md 9.1], [https://github.com/sebastianbergmann/phpunit/blob/9.3.0/ChangeLog-9.3.md 9.3], [https://github.com/sebastianbergmann/phpunit/blob/9.5.0/ChangeLog-9.5.md 9.5]
* [https://phpunit.readthedocs.io/en/9.5/ Official PHPUnit manual].
A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/e3a46964dc6d8ca1558c6e1e8dfdf3c1745eeaed/lib/upgrade.txt#L5-L65 lib/upgrade.txt] file. With main points being:
* All the changes that were deprecated with PHPUnit 8.5 (see the section below) are now removed and will lead to errors.
* <tt>assertContains()</tt> now performs stricter comparison (like <tt>assertSame()</tt> does). New <tt>assertContainsEquals()</tt> has been created to provide the old behavior.
* Changes to the <tt>phpunit.xml</tt> schema, mostly internal. These only will impact if you are using custom <tt>phpunit.xml</tt> files:
** The previous <tt><filter></tt> section is now (better) called <tt><coverage></tt>. And, within it:
*** <tt><whitelist></tt> has been replaced by <tt><include></tt>.
*** <tt><exclude></tt> is not a child of <tt><whitelist></tt> anymore, but of <tt><coverage></tt>.
** But with implications when defining the [[#Check your coverage|coverage information]] because <tt>$whitelistxxx</tt> properties used by the <tt>coverage.php</tt> files have been deprecated, instead use <tt>includelistfolders</tt> and <tt>includelistfiles</tt> (to better map the elements in the xml).
* Warning: It's not possible to run individual test files any more. Use any of the alternative execution methods (filter, suite, config) to specify which tests you want to run. This will be hopefully fixed in MDL-71049 once it has been agreed which the best way to proceed is.
* Deprecations, deprecations, deprecations. Lots of them in often used assertions: file assertions, regexp assertions, exception expectations... again, note that all them will become errors with the next PHPUnit update, so '''the recommendation is to update them ASAP'''.
Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/fc335f5...713722c browse the changes associated with the issue], hopefully with useful explanations in the commit messages.

=Upgrading unit tests to work with Moodle 3.10 and up (PHPUnit 8.5)=
{{Moodle 3.10}}

With Moodle 3.10, '''PHPUnit was upgraded to 8.5''' (from 7.5 being used in older version). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.10 (7.2, 7.3 and 7.4) and also to provide an '''easier jump to PHPUnit 9.x''' that will be needed for Moodle 3.11 (php versions 7.3, 7.4 and 8.0), removing a lot of deprecated stuff in advance. (see MDL-67673 and MDL-64600 for more details).

While 99% of existing tests will work without modification with PHPUnit 8.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 8.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2019/02/help-my-tests-stopped-working A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-8.html PHPUnit 8 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/130104cf796a88dd1547dc5beb8bd555c2deb55e/ChangeLog-8.0.md Detailed changelog of the release].
* [https://phpunit.readthedocs.io/en/8.5/ Official PHPUnit manual].
* A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/6594c54b2eef62499d304bfa0939999e3a14246e/lib/upgrade.txt#L5-L37 lib/upgrade.txt] file. With main points being:
** Support for PHP 7.0 dropped (because all template methods (<tt>setUp()</tt>, <tt>tearDown()</tt>..) now require to return void. This will mostly impact 3rd-part plugins that were still running the same tests against old branches of Moodle with PHP 7.0 support.
** <tt>PHPUnit/DBUnit</tt> has been removed are replaced by a lightweight alternative.
** Deprecations, deprecations, deprecations. Lots of them in often used assertions (<tt>assertContains()</tt>, <tt>assertEquals()</tt>...) and also <tt>@expectedExceptionXXX</tt> annotations. Again, note that all them will become errors with PHPUnit 9.
* Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/5903054...b13ec3c browse the changes associated with the issue], hopefully with useful enough explanations in the commit messages.
=Upgrading unit tests to work with Moodle 3.7 and up (PHPUnit 7.5)=
{{Moodle 3.7}}

With Moodle 3.7, '''PHPUnit was upgraded to 7.5''' (from 6.x being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.7 (7.1, 7.2 and 7.3). (see MDL-65204 and linked issues for more details). While internally [https://phpunit.de/announcements/phpunit-7.html a lot of things changed with PHPUnit 7] (PHP 7.1-isms, typed signatures, void returns, assertEquals() changes), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

To find more information about the changes coming with PHPUnit 7, it's recommended to read the following resources:
* [https://phpunit.de/announcements/phpunit-7.html PHPUnit 7 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/520723129e2b3fc1dc4c0953e43c9d40e1ecb352/ChangeLog-7.5.md Detailed changelog of the release], paying special attention to the added, deprecated, changed and deleted sections.
* [https://phpunit.readthedocs.io/en/7.5/ Official PHPUnit manual].
* Changes performed into core, mainly: new, stricter, signatures ([https://github.com/moodle/moodle/commit/26218b7 26218b7]) and assertEquals() changes, specially important when comparing strings, now performed using strict (===) equals ([https://github.com/moodle/moodle/commit/85f47ba 85f47ba]).
=Upgrading unit tests to work with Moodle 3.4 and up (PHPUnit 6)=
{{Moodle 3.4}}

With Moodle 3.4, '''PHPUnit was upgraded to 6.4''' (from 5.5 being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.4 (7.0, 7.1 and 7.2). (see MDL-60611 and linked issues for more details). While internally [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues a lot of things changed with PHPUnit 6] (namespaced classes being the more noticeable), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

Still, in '''some cases, it will impossible to maintain compatibility''' of tests between old (pre 3.4) tests and new ones, especially '''when direct use of any phpunit class is performed'''. Luckily, both GitHub Actions and CI tests will detect this situation and it shouldn't be hard to keep all supported branches in core passing ok. Plugins may be trickier, if the same branch is attempting to work against multiple core branches and they are using some phpunit class directly.

To find more information about the changes coming with PHPUnit 6, it's recommended to read the following resources:
* [https://thephp.cc/news/2017/02/migrating-to-phpunit-6 A very good mini-guide] showing all the important changes.
* [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues PHPUnit 6 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/9d0c024d2099531442d862b66b0ad7cf35ed8e78/ChangeLog-6.0.md Detailed changelog of the release], paying special attention to the changed and deleted sections.
* Changes performed into core, mainly: namespace class renaming ([https://github.com/moodle/moodle/commit/801a372dadb6e11c8781547603e3f0a59ce5638f 801a372]) and deprecated stuff ([https://github.com/moodle/moodle/commit/796e48a58bf18533bdca423fff7949ab119101c4 796e48a])
=See also=
* [[PHPUnit integration]]
* [[PHPUnit]]
[[Category:Unit testing]]

Writing PHPUnit tests

2024-03-25T13:58:22Z

Stronk7: /* Upgrading unit tests to work with Moodle 4.4 and up (PHPUnit 9.6) */

{{Moodle 2.3}}

Moodle PHPUnit integration is designed to allow easy adding of new tests. At the start of each test the state is automatically reset to fresh new installation (unless explicitly told not to reset).
=Namespaces=
All the stuff under **/tests directories is [[Coding style#Namespaces_within_.2A.2A.2Ftests_directories|subject to some simple rules]] when using namespaces. They apply to test cases, fixtures, generators and, in general, any class within those directories. Take a look to them! (grand summary = 100% the same rules that are applied to **/classes directories).
=Testcase classes=
There are three basic test class that are supposed to used in all Moodle unit tests - basic_testcase, advanced_testcase and provider_testcase. '''Please note it is strongly recommended to put only one testcase into each class file.'''
;basic_testcase : Very simple tests that do not modify database, dataroot or any PHP globals. It can be used for example when trying examples from the official PHPUnit tutorial.
;advanced_testcase : Enhanced testcase class enhanced for easy testing of Moodle code.
;provider_testcase: Enhanced testcase class, enhanced for easy testing of [[Privacy API|Privacy Providers]].
There is a fourth testcase class that is specially designed for testing of our Moodle database layer, it should not be used for other purposes.
== Assertions ==
The complete list of assertions can be found in the links below.
{| class="wikitable" border="1"
|-
! Moodle version
! PHPUnit version
!Links
|-
| Moodle 3.11
| PHPUnit 9.5
|[https://phpunit.readthedocs.io/en/9.5/assertions.html Documentation]
|-
| Moodle 3.10
| PHPUnit 8.5
|[https://phpunit.readthedocs.io/en/8.5/assertions.html Documentation]
|-
| Moodle 3.7 - 3.9
| PHPUnit 7.5
|[https://phpunit.readthedocs.io/en/7.5/assertions.html Documentation]
|-
| Moodle 3.4 - 3.6
| PHPUnit 6.5
|[https://phpunit.de/manual/6.5/en/assertions.html Documentation]
|}
==Sample plugin testcase==
PHPUnit tests are located in <tt>tests/*_test.php</tt> files in your plugin, for example <tt>mod/myplugin/tests/sample_test.php</tt>, the file should contain only one class that extends <tt>advanced_testcase</tt>:
<syntaxhighlight lang="php">
namespace mod_myplugin;

class sample_test extends \advanced_testcase {
public function test_adding() {
$this->assertEquals(2, 1+2);
}
}
</syntaxhighlight>
See [[PHPUnit integration#Class and file naming rules]] for more information.
==Inclusion of Moodle library files==
If you want to include some Moodle library files you should always declare '''global $CFG'''. The reason is that testcase files may be included from non-moodle code which does not make the global $CFG available automatically.
==Automatic state reset==
By default after each test Moodle database and dataroot is automatically reset to the original state which was present right after installation. make sure to use $this->resetAfterTest() to indicate that the database or changes of standard global variables are expected.

If you received the error "Warning: unexpected database modification, resetting DB state" it is because the test is not using <tt>$this->resetAfterTest()</tt>.
<syntaxhighlight lang="php">
namespace mod_myplugin;

class test_something extends \advanced_testcase {
public function test_deleting() {
global $DB;
$this->resetAfterTest(true);
$DB->delete_records('user');
$this->assertEmpty($DB->get_records('user'));
}
public function test_user_table_was_reset() {
global $DB;
$this->assertEquals(2, $DB->count_records('user', array()));
}
}
</syntaxhighlight>
=Generators=
Tests that need to modify default installation may use generators to create new courses, users, etc. All examples on this page should be used from test methods of a test class derived from advanced_testcase.

Note if you are using PHPUnit [https://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.data-providers @dataProvider] functions to provide parameters to unit tests, you can not use the data generator or change the user etc in the data provider function. Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation.
==Creating users==
At the start of each test there are only two users present - guest and administrator. If you need to add more test accounts use:
<syntaxhighlight lang="php">
$user = $this->getDataGenerator()->create_user();
</syntaxhighlight>
You may also specify properties of the user account, for example:
<syntaxhighlight lang="php">
$user1 = $this->getDataGenerator()->create_user(array('email'=>'user1@example.com', 'username'=>'user1'));
</syntaxhighlight>
By default no user is logged-in, use setUser() method to change current $USER value:
<syntaxhighlight lang="php">
$this->setUser($user1);
</syntaxhighlight>
Guest and admin accounts have a shortcut methods:
<syntaxhighlight lang="php">
$this->setGuestUser();
$this->setAdminUser();
</syntaxhighlight>
Null can be used to set current user back to not-logged-in:
<syntaxhighlight lang="php">
$this->setUser(null);
</syntaxhighlight>
==Creating course categories==
<syntaxhighlight lang="php">
$category1 = $this->getDataGenerator()->create_category();
$category2 = $this->getDataGenerator()->create_category(array('name'=>'Some subcategory', 'parent'=>$category1->id));
</syntaxhighlight>
==Creating courses==
<syntaxhighlight lang="php">
$course1 = $this->getDataGenerator()->create_course();

$category = $this->getDataGenerator()->create_category();
$course2 = $this->getDataGenerator()->create_course(array('name'=>'Some course', 'category'=>$category->id));
</syntaxhighlight>
==Creating activities==
Some activity plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php.

Example of creation of new course with one page resource:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$generator = $this->getDataGenerator()->get_plugin_generator('mod_page');
$generator->create_instance(array('course'=>$course->id));
</syntaxhighlight>
The following is functionally the same, but a bit shorter:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$page = $this->getDataGenerator()->create_module('page', array('course' => $course->id));
</syntaxhighlight>
==Creating cohorts==
{{Moodle 2.4}}
Since 2.4 there the data generator supports creation of new cohorts.
<syntaxhighlight lang="php">
$cohort = $this->getDataGenerator()->create_cohort();
</syntaxhighlight>
==Simplified user enrolments==
{{Moodle 2.4}}
Instead of standard enrolment API it is possible to use simplified method in data generator. It is intended to be used with self and manual enrolment plugins.
<syntaxhighlight lang="php">
$this->getDataGenerator()->enrol_user($userid, $courseid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid, 'manual');
</syntaxhighlight>
==Creating scales==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_scale();
$this->getDataGenerator()->create_scale(array('name' => $name, 'scale' => $scale, 'courseid' => $courseid, 'userid' => $userid, 'description' => description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
==Creating roles==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_role();
$this->getDataGenerator()->create_role(array('shortname' => $shortname, 'name' => $name, 'description' => description, 'archetype' => $archetype));
</syntaxhighlight>
==Creating tags==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_tag();
$this->getDataGenerator()->create_tag(array(
'userid' => $userid,
'rawname' => $rawname,
'name' => $name,
'description' => $description,
'descriptionformat' => $descriptionformat,
'flag' => $flag
));
</syntaxhighlight>
==Groups==
===Creating groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group(array('courseid' => $courseid));
$this->getDataGenerator()->create_group(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding users to groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid));
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid, 'component' => $component, 'itemid' => $itemid));
</syntaxhighlight>
===Creating groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid));
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding groups to groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping_group(array('groupingid' => $groupingid, 'groupid' => $groupid));
</syntaxhighlight>
==Repositories==
===Creating repository instances===
{{Moodle 2.5}}
Some respository plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository($type, $record, $options);
</syntaxhighlight>
===Creating repository types===
{{Moodle 2.5}}
Some respository plugins include type generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository_type($type, $record, $options);
</syntaxhighlight>
==Creating grades==
===Grade categories===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid));
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid, 'fullname' => $fullname));
</syntaxhighlight>
===Grade items===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_item();
$this->getDataGenerator()->create_grade_item(array('itemtype' => $itemtype, 'itemname' => $itemname, 'outcomeid' => $outcomeid, 'scaleid' => $scaleid, 'gradetype' => $gradetype));
</syntaxhighlight>
===Outcomes===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_outcome();
$this->getDataGenerator()->create_grade_item(array('fullname' => $fullname));
</syntaxhighlight>
==Other types of plugin==
{{Moodle 2.5}}
Any other type of plugin can have a generator. The generator class should extend component_generator_base, and then you can get an instance using $mygenerator = $this->getDataGenerator()->get_plugin_generator($frankenstylecomponentname);

For some types of plugin, like mod documented above, there may be a more specific class than component_generator_base to extend, like testing_module_generator. That will give a consistent set of method names to use. Otherwise, you can create whatever methods you like on your generator, to create the different things you need to work whith.
=Long tests=
All standard test should execute as fast as possible. Tests that take a longer time to execute (>10s) or are otherwise expensive (such as querying external servers that might be flooded by all dev machines) should be execute only when PHPUNIT_LONGTEST is true. This constant can be set in phpunit.xml or directly in config.php.
=Large test data=
See advanced_testcase::createXMLDataSet() and advanced_testcase::createCsvDataSet() and related functions there for easier ways to manage large test data sets within files rather than arrays in code. See [[PHPUnit_integration#Extra_methods]]
=Testing sending of messages=
{{Moodle 2.4}}
You can temporarily redirect all messages sent via message_send() to a message sink object. This allows developers to verify that the tested code is sending expected messages.

To test code using messaging first disable the use of transactions and then redirect the messaging into a new message sink, you can inspect the results later.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
$sink = $this->redirectMessages();
//... code that is sending messages
$messages = $sink->get_messages();
$this->assertEquals(3, count($messages));
//.. test messages were generated in correct order with appropriate content
</syntaxhighlight>
=Testing sending of emails=
{{Moodle 2.6}}
You can temporarily redirect emails sent via email_to_user() to a email message sink object. This allows developers to verify that the tested code is sending expected emails.

To test code using messaging first unset 'noemailever' setting and then redirect the emails into a new message sink where you can inspect the results later.
<syntaxhighlight lang="php">
unset_config('noemailever');
$sink = $this->redirectEmails();
//... code that is sending email
$messages = $sink->get_messages();
$this->assertEquals(1, count($messages));
</syntaxhighlight>
=Logstores=
You can test events which were written to a logstore, but you must disable transactions, enable at least one valid logstore, and disable logstore buffering to ensure that the events are written to the database before the tests execute.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
set_config('enabled_stores', 'logstore_standard', 'tool_log');
set_config('buffersize', 0, 'logstore_standard');
get_log_manager(true);
</syntaxhighlight>
=Check your coverage=
{{Moodle 3.7}}
PHPUnit has the ability to generate code coverage information for your unit tests.

Prior to Moodle 3.7, this coverage would load all files and generate coverage for everything regardless of whether that file could be covered at all, or whether it was intentionally covered.

Since Moodle 3.7 the '''phpunit.xml''' configuration contains generated coverage include and exclude information for each component.
==Generating include and exclude configuration==
{{Moodle 3.11}}
You can programatically describe which files will be checked for coverage by creating a <tt>coverage.php</tt> file alongside the tests that you are writing.

Since Moodle 4.0, a default configuration is applied for all plugins and it is not necessary to supply a coverage.php unless you wish to cover additional files.

The <tt>coverage.php</tt> file allows you to list include and exclude files and folders within the component being
tested. All paths specified are relative to the component being tested. For example, when working with '''mod_forum''' your
code will be in '''mod/forum''', and its unit tests will be in '''mod/forum/tests/example_test.php'''. The coverage file
for this would be in '''mod/forum/tests/coverage.php''' and all paths specified would be relative to '''mod/forum'''.

It is possible to specify a combination of included files, included folders, excluded files, and excluded folders. This would allow you, for example, to include the entire '''classes''' directory, but exclude.a specific file or folder within it.

The following is an example <tt>coverage.php</tt> file from '''mod_forum''':

Note: For Moodle versions 3.7 to 3.10, the [https://docs.moodle.org/dev/index.php?title=Writing_PHPUnit_tests&oldid=58177#Check_your_coverage syntax used] was slightly different.
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'externallib.php',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
Also, note that you can better define which class or function each test is effectively covering by using the <tt>@covers</tt> annotation as [https://phpunit.readthedocs.io/en/9.5/code-coverage-analysis.html#specifying-covered-code-parts described in the documention].

Since Moodle 4.0, the following default configuration is applied:{{Moodle 4.0}}
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'tests/generator',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [
'externallib.php',
'lib.php',
'locallib.php',
'renderer.php',
'rsslib.php',
];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
If a coverage.php file already exists, then the defaults will be added to the values already defined.
=Best practice=
There are several best practices, suggestions, and things to avoid which you should consider when writing unit tests. Some of these are described below.
==Code coverage==
PHPUnit has the ability to generate code coverage information for your unit tests and this is well supported since.Moodle 3.7. We recommend that you consider checking the coverage of your plugins when you write your code.

We recommend that you explicitly set the @covers annotation as described in the [https://phpunit.readthedocs.io/en/9.5/annotations.html#appendixes-annotations-covers-tables-annotations PHPUnit documentation].
==Keep use of resetAfterTest to a minimum==
Although many of the examples described above use the <syntaxhighlight lang="php">resetAfterTest</syntaxhighlight> nomenclature to reset the database and filesystem after your test completes, you should ideally not use this unless you have to.
Generally speaking you should aim to write code which is mockable, and does not require real fixtures.
Use of resetAfterTest will also slow your tests down.
==Be careful with shared setUp and instance variables==
You should be careful of how you create and use instance variables in PHPUnit tests for two main reasons:
# If you create any fixtures in the setUp, or call the resetAfterTest function, these fixtures and conditions will apply for _all_ tests in the testsuite. You will not be able to add another test to the suite which does not require these conditions without those conditions being fulfilled anyway. This can lead to slow tests.
# PHPUnit creates an instance of each testcase during its bootstrap phase, and does not dispose of it for the lifetime of the test run. Anything which causes data to be stored as instance data within the testcase will be stored in memory until the _entire suite_ completes. This means that any fixture which is setup and not actively discarded will not be garbage collected and lead to memory bloat. In severe cases this can lead to memory exhaustion.

Existing testcases which contain setUp which either generate data, or set resetAfterTest should be phased out, and no new cases should be introduced.
==Make use of the dataProvider functionality==
The dataProvider functionality of PHPUnit is an extremely powerful and useful feature which allows you to verify a function quickly and easily with a range of different conditions.
However, the following rules should be followed when using dataProviders:
* Keep addition of resettable data requiring resetAfterTest to a minimum - this will lead to many slow tests
* Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation. The dataProvider is called after the testSuite is instantiated, but before any tests are run. Each test will run a full setUp and tearDown, which will destroy any data which was created.
<syntaxhighlight lang="php">
/**
* Test function accepts parameters passed from the specified data provider.
*
* @dataProvider foobar_provider
* @param int $foor
* @param int $bar
*/
public function test_foobar(int $foo, int $bar) {
// Perform the tests here.
}

/**
* Data provider for {@see self::test_foobar()}.
*
* @return array List of data sets - (string) data set name => (array) data
*/
public function foobar_provider(): array {
return [
'Same numbers' => [
'foo' => 42,
'bar' => 42,
],
'Different numbers' => [
'foo' => 21,
'bar' => 84,
],
];
}
</syntaxhighlight>
=Extra test settings=
Usually the test should not interact with any external systems and it should work the same on all systems. But sometimes you need to specify some option for connection to external systems or system configuration. It is intentionally not possible to use $CFG settings from config.php.

There are several ways how to inject your custom settings:
* define test setting constants in your phpunit.xml file
* define test setting constants in your config.php
These constants may be then used in your test or plugin code.
=Upgrading unit tests to work with Moodle 4.4 and up (PHPUnit 9.6)=
{{Moodle 4.4}}

With Moodle 4.4, '''PHPUnit was upgraded to 9.6''' (from 9.5 being used in previous versions). This was done to '''warn to developers in advance''' about functionality that has been deprecated in the 9.5 series and will be removed so will stop working with the next major update to PHPUnit 10.x (see MDL-81266 and linked issues for more details).

While everything should continue working without modification with PHPUnit 9.6, you will may get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be analysed''', replacing or removing them as soon as possible, because all those warnings will become errors with next PHPUnit upgrade.

A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/commit/28892562ca4c06f4f57ca1588c04e608b3d0e22c lib/upgrade.txt] file. With main points being:
* MDL-81281. A number of attribute-related assertions have been deprecated, will be removed with PHPUnit 10. Alternatives for '''some''' of them are available:
- assertClassHasAttribute()
- assertClassNotHasAttribute()
- assertClassHasStaticAttribute()
- assertClassNotHasStaticAttribute()
- assertObjectHasAttribute() => assertObjectHasProperty()
- assertObjectNotHasAttribute() => assertObjectNotHasProperty()
* MDL-81266. A number of deprecation, notice, warning and error expectations have been deprecated, will be removed with PHPUnit 10. No alternative exists. A working replacement is available in the linked issue, hopefully there aren't many cases.
- expectDeprecation()
- expectDeprecationMessage()
- expectDeprecationMessageMatches()
- expectError()
- expectErrorMessage()
- expectErrorMessageMatches()
- expectNotice()
- expectNoticeMessage()
- expectNoticeMessageMatches()
- expectWarning()
- expectWarningMessage()
- expectWarningMessageMatches()
* MDL-81308. The <tt>->withConsecutive()</tt> functionality on PHPUnit mocks has been '''silently''' deprecated, will be removed with PHPUnit 10. Note that this won't affect PHPUnit 9.6 runs and an alternative path will be proposed in the linked issue, part of the PHPUnit 10 epic.
* <tt>PHPUnit\Framework\TestCase::getMockClass()</tt> has been deprecated, will be removed with PHPUnit 10. No clear alternative exists and won't be investigated, because there aren't cases in core.
* Cannot use the <tt>Test</tt> suffix on abstract test case classes. Proceed to rename them to end with <tt>TestCase</tt> instead.

=Upgrading unit tests to work with Moodle 3.11 and up (PHPUnit 9.5)=
{{Moodle 3.11}}

With Moodle 3.11, '''PHPUnit was upgraded to 9.5''' (from 8.5 being used in previous versions). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.11 (7.3, 7.4 and [[Moodle and PHP|8.0]]) (see MDL-71036 and linked issues for more details).

While a lot of existing tests will work without modification with PHPUnit 9.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 9.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2020/02/migrating-to-phpunit-9 A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-9.html PHPUnit 9 release Announcement].
* These multiple detailed changelogs (because all them have included modifications requiring changes): [https://github.com/sebastianbergmann/phpunit/blob/9.0.0/ChangeLog-9.0.md 9.0], [https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md 9.1], [https://github.com/sebastianbergmann/phpunit/blob/9.3.0/ChangeLog-9.3.md 9.3], [https://github.com/sebastianbergmann/phpunit/blob/9.5.0/ChangeLog-9.5.md 9.5]
* [https://phpunit.readthedocs.io/en/9.5/ Official PHPUnit manual].
A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/e3a46964dc6d8ca1558c6e1e8dfdf3c1745eeaed/lib/upgrade.txt#L5-L65 lib/upgrade.txt] file. With main points being:
* All the changes that were deprecated with PHPUnit 8.5 (see the section below) are now removed and will lead to errors.
* <tt>assertContains()</tt> now performs stricter comparison (like <tt>assertSame()</tt> does). New <tt>assertContainsEquals()</tt> has been created to provide the old behavior.
* Changes to the <tt>phpunit.xml</tt> schema, mostly internal. These only will impact if you are using custom <tt>phpunit.xml</tt> files:
** The previous <tt><filter></tt> section is now (better) called <tt><coverage></tt>. And, within it:
*** <tt><whitelist></tt> has been replaced by <tt><include></tt>.
*** <tt><exclude></tt> is not a child of <tt><whitelist></tt> anymore, but of <tt><coverage></tt>.
** But with implications when defining the [[#Check your coverage|coverage information]] because <tt>$whitelistxxx</tt> properties used by the <tt>coverage.php</tt> files have been deprecated, instead use <tt>includelistfolders</tt> and <tt>includelistfiles</tt> (to better map the elements in the xml).
* Warning: It's not possible to run individual test files any more. Use any of the alternative execution methods (filter, suite, config) to specify which tests you want to run. This will be hopefully fixed in MDL-71049 once it has been agreed which the best way to proceed is.
* Deprecations, deprecations, deprecations. Lots of them in often used assertions: file assertions, regexp assertions, exception expectations... again, note that all them will become errors with the next PHPUnit update, so '''the recommendation is to update them ASAP'''.
Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/fc335f5...713722c browse the changes associated with the issue], hopefully with useful explanations in the commit messages.

=Upgrading unit tests to work with Moodle 3.10 and up (PHPUnit 8.5)=
{{Moodle 3.10}}

With Moodle 3.10, '''PHPUnit was upgraded to 8.5''' (from 7.5 being used in older version). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.10 (7.2, 7.3 and 7.4) and also to provide an '''easier jump to PHPUnit 9.x''' that will be needed for Moodle 3.11 (php versions 7.3, 7.4 and 8.0), removing a lot of deprecated stuff in advance. (see MDL-67673 and MDL-64600 for more details).

While 99% of existing tests will work without modification with PHPUnit 8.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 8.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2019/02/help-my-tests-stopped-working A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-8.html PHPUnit 8 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/130104cf796a88dd1547dc5beb8bd555c2deb55e/ChangeLog-8.0.md Detailed changelog of the release].
* [https://phpunit.readthedocs.io/en/8.5/ Official PHPUnit manual].
* A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/6594c54b2eef62499d304bfa0939999e3a14246e/lib/upgrade.txt#L5-L37 lib/upgrade.txt] file. With main points being:
** Support for PHP 7.0 dropped (because all template methods (<tt>setUp()</tt>, <tt>tearDown()</tt>..) now require to return void. This will mostly impact 3rd-part plugins that were still running the same tests against old branches of Moodle with PHP 7.0 support.
** <tt>PHPUnit/DBUnit</tt> has been removed are replaced by a lightweight alternative.
** Deprecations, deprecations, deprecations. Lots of them in often used assertions (<tt>assertContains()</tt>, <tt>assertEquals()</tt>...) and also <tt>@expectedExceptionXXX</tt> annotations. Again, note that all them will become errors with PHPUnit 9.
* Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/5903054...b13ec3c browse the changes associated with the issue], hopefully with useful enough explanations in the commit messages.
=Upgrading unit tests to work with Moodle 3.7 and up (PHPUnit 7.5)=
{{Moodle 3.7}}

With Moodle 3.7, '''PHPUnit was upgraded to 7.5''' (from 6.x being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.7 (7.1, 7.2 and 7.3). (see MDL-65204 and linked issues for more details). While internally [https://phpunit.de/announcements/phpunit-7.html a lot of things changed with PHPUnit 7] (PHP 7.1-isms, typed signatures, void returns, assertEquals() changes), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

To find more information about the changes coming with PHPUnit 7, it's recommended to read the following resources:
* [https://phpunit.de/announcements/phpunit-7.html PHPUnit 7 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/520723129e2b3fc1dc4c0953e43c9d40e1ecb352/ChangeLog-7.5.md Detailed changelog of the release], paying special attention to the added, deprecated, changed and deleted sections.
* [https://phpunit.readthedocs.io/en/7.5/ Official PHPUnit manual].
* Changes performed into core, mainly: new, stricter, signatures ([https://github.com/moodle/moodle/commit/26218b7 26218b7]) and assertEquals() changes, specially important when comparing strings, now performed using strict (===) equals ([https://github.com/moodle/moodle/commit/85f47ba 85f47ba]).
=Upgrading unit tests to work with Moodle 3.4 and up (PHPUnit 6)=
{{Moodle 3.4}}

With Moodle 3.4, '''PHPUnit was upgraded to 6.4''' (from 5.5 being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.4 (7.0, 7.1 and 7.2). (see MDL-60611 and linked issues for more details). While internally [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues a lot of things changed with PHPUnit 6] (namespaced classes being the more noticeable), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

Still, in '''some cases, it will impossible to maintain compatibility''' of tests between old (pre 3.4) tests and new ones, especially '''when direct use of any phpunit class is performed'''. Luckily, both GitHub Actions and CI tests will detect this situation and it shouldn't be hard to keep all supported branches in core passing ok. Plugins may be trickier, if the same branch is attempting to work against multiple core branches and they are using some phpunit class directly.

To find more information about the changes coming with PHPUnit 6, it's recommended to read the following resources:
* [https://thephp.cc/news/2017/02/migrating-to-phpunit-6 A very good mini-guide] showing all the important changes.
* [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues PHPUnit 6 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/9d0c024d2099531442d862b66b0ad7cf35ed8e78/ChangeLog-6.0.md Detailed changelog of the release], paying special attention to the changed and deleted sections.
* Changes performed into core, mainly: namespace class renaming ([https://github.com/moodle/moodle/commit/801a372dadb6e11c8781547603e3f0a59ce5638f 801a372]) and deprecated stuff ([https://github.com/moodle/moodle/commit/796e48a58bf18533bdca423fff7949ab119101c4 796e48a])
=See also=
* [[PHPUnit integration]]
* [[PHPUnit]]
[[Category:Unit testing]]

Writing PHPUnit tests

2024-03-25T13:21:09Z

Stronk7: Documenting the upgrade to PHPUnit 9.6

{{Moodle 2.3}}

Moodle PHPUnit integration is designed to allow easy adding of new tests. At the start of each test the state is automatically reset to fresh new installation (unless explicitly told not to reset).
=Namespaces=
All the stuff under **/tests directories is [[Coding style#Namespaces_within_.2A.2A.2Ftests_directories|subject to some simple rules]] when using namespaces. They apply to test cases, fixtures, generators and, in general, any class within those directories. Take a look to them! (grand summary = 100% the same rules that are applied to **/classes directories).
=Testcase classes=
There are three basic test class that are supposed to used in all Moodle unit tests - basic_testcase, advanced_testcase and provider_testcase. '''Please note it is strongly recommended to put only one testcase into each class file.'''
;basic_testcase : Very simple tests that do not modify database, dataroot or any PHP globals. It can be used for example when trying examples from the official PHPUnit tutorial.
;advanced_testcase : Enhanced testcase class enhanced for easy testing of Moodle code.
;provider_testcase: Enhanced testcase class, enhanced for easy testing of [[Privacy API|Privacy Providers]].
There is a fourth testcase class that is specially designed for testing of our Moodle database layer, it should not be used for other purposes.
== Assertions ==
The complete list of assertions can be found in the links below.
{| class="wikitable" border="1"
|-
! Moodle version
! PHPUnit version
!Links
|-
| Moodle 3.11
| PHPUnit 9.5
|[https://phpunit.readthedocs.io/en/9.5/assertions.html Documentation]
|-
| Moodle 3.10
| PHPUnit 8.5
|[https://phpunit.readthedocs.io/en/8.5/assertions.html Documentation]
|-
| Moodle 3.7 - 3.9
| PHPUnit 7.5
|[https://phpunit.readthedocs.io/en/7.5/assertions.html Documentation]
|-
| Moodle 3.4 - 3.6
| PHPUnit 6.5
|[https://phpunit.de/manual/6.5/en/assertions.html Documentation]
|}
==Sample plugin testcase==
PHPUnit tests are located in <tt>tests/*_test.php</tt> files in your plugin, for example <tt>mod/myplugin/tests/sample_test.php</tt>, the file should contain only one class that extends <tt>advanced_testcase</tt>:
<syntaxhighlight lang="php">
namespace mod_myplugin;

class sample_test extends \advanced_testcase {
public function test_adding() {
$this->assertEquals(2, 1+2);
}
}
</syntaxhighlight>
See [[PHPUnit integration#Class and file naming rules]] for more information.
==Inclusion of Moodle library files==
If you want to include some Moodle library files you should always declare '''global $CFG'''. The reason is that testcase files may be included from non-moodle code which does not make the global $CFG available automatically.
==Automatic state reset==
By default after each test Moodle database and dataroot is automatically reset to the original state which was present right after installation. make sure to use $this->resetAfterTest() to indicate that the database or changes of standard global variables are expected.

If you received the error "Warning: unexpected database modification, resetting DB state" it is because the test is not using <tt>$this->resetAfterTest()</tt>.
<syntaxhighlight lang="php">
namespace mod_myplugin;

class test_something extends \advanced_testcase {
public function test_deleting() {
global $DB;
$this->resetAfterTest(true);
$DB->delete_records('user');
$this->assertEmpty($DB->get_records('user'));
}
public function test_user_table_was_reset() {
global $DB;
$this->assertEquals(2, $DB->count_records('user', array()));
}
}
</syntaxhighlight>
=Generators=
Tests that need to modify default installation may use generators to create new courses, users, etc. All examples on this page should be used from test methods of a test class derived from advanced_testcase.

Note if you are using PHPUnit [https://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.data-providers @dataProvider] functions to provide parameters to unit tests, you can not use the data generator or change the user etc in the data provider function. Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation.
==Creating users==
At the start of each test there are only two users present - guest and administrator. If you need to add more test accounts use:
<syntaxhighlight lang="php">
$user = $this->getDataGenerator()->create_user();
</syntaxhighlight>
You may also specify properties of the user account, for example:
<syntaxhighlight lang="php">
$user1 = $this->getDataGenerator()->create_user(array('email'=>'user1@example.com', 'username'=>'user1'));
</syntaxhighlight>
By default no user is logged-in, use setUser() method to change current $USER value:
<syntaxhighlight lang="php">
$this->setUser($user1);
</syntaxhighlight>
Guest and admin accounts have a shortcut methods:
<syntaxhighlight lang="php">
$this->setGuestUser();
$this->setAdminUser();
</syntaxhighlight>
Null can be used to set current user back to not-logged-in:
<syntaxhighlight lang="php">
$this->setUser(null);
</syntaxhighlight>
==Creating course categories==
<syntaxhighlight lang="php">
$category1 = $this->getDataGenerator()->create_category();
$category2 = $this->getDataGenerator()->create_category(array('name'=>'Some subcategory', 'parent'=>$category1->id));
</syntaxhighlight>
==Creating courses==
<syntaxhighlight lang="php">
$course1 = $this->getDataGenerator()->create_course();

$category = $this->getDataGenerator()->create_category();
$course2 = $this->getDataGenerator()->create_course(array('name'=>'Some course', 'category'=>$category->id));
</syntaxhighlight>
==Creating activities==
Some activity plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php.

Example of creation of new course with one page resource:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$generator = $this->getDataGenerator()->get_plugin_generator('mod_page');
$generator->create_instance(array('course'=>$course->id));
</syntaxhighlight>
The following is functionally the same, but a bit shorter:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$page = $this->getDataGenerator()->create_module('page', array('course' => $course->id));
</syntaxhighlight>
==Creating cohorts==
{{Moodle 2.4}}
Since 2.4 there the data generator supports creation of new cohorts.
<syntaxhighlight lang="php">
$cohort = $this->getDataGenerator()->create_cohort();
</syntaxhighlight>
==Simplified user enrolments==
{{Moodle 2.4}}
Instead of standard enrolment API it is possible to use simplified method in data generator. It is intended to be used with self and manual enrolment plugins.
<syntaxhighlight lang="php">
$this->getDataGenerator()->enrol_user($userid, $courseid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid, 'manual');
</syntaxhighlight>
==Creating scales==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_scale();
$this->getDataGenerator()->create_scale(array('name' => $name, 'scale' => $scale, 'courseid' => $courseid, 'userid' => $userid, 'description' => description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
==Creating roles==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_role();
$this->getDataGenerator()->create_role(array('shortname' => $shortname, 'name' => $name, 'description' => description, 'archetype' => $archetype));
</syntaxhighlight>
==Creating tags==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_tag();
$this->getDataGenerator()->create_tag(array(
'userid' => $userid,
'rawname' => $rawname,
'name' => $name,
'description' => $description,
'descriptionformat' => $descriptionformat,
'flag' => $flag
));
</syntaxhighlight>
==Groups==
===Creating groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group(array('courseid' => $courseid));
$this->getDataGenerator()->create_group(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding users to groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid));
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid, 'component' => $component, 'itemid' => $itemid));
</syntaxhighlight>
===Creating groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid));
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding groups to groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping_group(array('groupingid' => $groupingid, 'groupid' => $groupid));
</syntaxhighlight>
==Repositories==
===Creating repository instances===
{{Moodle 2.5}}
Some respository plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository($type, $record, $options);
</syntaxhighlight>
===Creating repository types===
{{Moodle 2.5}}
Some respository plugins include type generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository_type($type, $record, $options);
</syntaxhighlight>
==Creating grades==
===Grade categories===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid));
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid, 'fullname' => $fullname));
</syntaxhighlight>
===Grade items===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_item();
$this->getDataGenerator()->create_grade_item(array('itemtype' => $itemtype, 'itemname' => $itemname, 'outcomeid' => $outcomeid, 'scaleid' => $scaleid, 'gradetype' => $gradetype));
</syntaxhighlight>
===Outcomes===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_outcome();
$this->getDataGenerator()->create_grade_item(array('fullname' => $fullname));
</syntaxhighlight>
==Other types of plugin==
{{Moodle 2.5}}
Any other type of plugin can have a generator. The generator class should extend component_generator_base, and then you can get an instance using $mygenerator = $this->getDataGenerator()->get_plugin_generator($frankenstylecomponentname);

For some types of plugin, like mod documented above, there may be a more specific class than component_generator_base to extend, like testing_module_generator. That will give a consistent set of method names to use. Otherwise, you can create whatever methods you like on your generator, to create the different things you need to work whith.
=Long tests=
All standard test should execute as fast as possible. Tests that take a longer time to execute (>10s) or are otherwise expensive (such as querying external servers that might be flooded by all dev machines) should be execute only when PHPUNIT_LONGTEST is true. This constant can be set in phpunit.xml or directly in config.php.
=Large test data=
See advanced_testcase::createXMLDataSet() and advanced_testcase::createCsvDataSet() and related functions there for easier ways to manage large test data sets within files rather than arrays in code. See [[PHPUnit_integration#Extra_methods]]
=Testing sending of messages=
{{Moodle 2.4}}
You can temporarily redirect all messages sent via message_send() to a message sink object. This allows developers to verify that the tested code is sending expected messages.

To test code using messaging first disable the use of transactions and then redirect the messaging into a new message sink, you can inspect the results later.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
$sink = $this->redirectMessages();
//... code that is sending messages
$messages = $sink->get_messages();
$this->assertEquals(3, count($messages));
//.. test messages were generated in correct order with appropriate content
</syntaxhighlight>
=Testing sending of emails=
{{Moodle 2.6}}
You can temporarily redirect emails sent via email_to_user() to a email message sink object. This allows developers to verify that the tested code is sending expected emails.

To test code using messaging first unset 'noemailever' setting and then redirect the emails into a new message sink where you can inspect the results later.
<syntaxhighlight lang="php">
unset_config('noemailever');
$sink = $this->redirectEmails();
//... code that is sending email
$messages = $sink->get_messages();
$this->assertEquals(1, count($messages));
</syntaxhighlight>
=Logstores=
You can test events which were written to a logstore, but you must disable transactions, enable at least one valid logstore, and disable logstore buffering to ensure that the events are written to the database before the tests execute.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
set_config('enabled_stores', 'logstore_standard', 'tool_log');
set_config('buffersize', 0, 'logstore_standard');
get_log_manager(true);
</syntaxhighlight>
=Check your coverage=
{{Moodle 3.7}}
PHPUnit has the ability to generate code coverage information for your unit tests.

Prior to Moodle 3.7, this coverage would load all files and generate coverage for everything regardless of whether that file could be covered at all, or whether it was intentionally covered.

Since Moodle 3.7 the '''phpunit.xml''' configuration contains generated coverage include and exclude information for each component.
==Generating include and exclude configuration==
{{Moodle 3.11}}
You can programatically describe which files will be checked for coverage by creating a <tt>coverage.php</tt> file alongside the tests that you are writing.

Since Moodle 4.0, a default configuration is applied for all plugins and it is not necessary to supply a coverage.php unless you wish to cover additional files.

The <tt>coverage.php</tt> file allows you to list include and exclude files and folders within the component being
tested. All paths specified are relative to the component being tested. For example, when working with '''mod_forum''' your
code will be in '''mod/forum''', and its unit tests will be in '''mod/forum/tests/example_test.php'''. The coverage file
for this would be in '''mod/forum/tests/coverage.php''' and all paths specified would be relative to '''mod/forum'''.

It is possible to specify a combination of included files, included folders, excluded files, and excluded folders. This would allow you, for example, to include the entire '''classes''' directory, but exclude.a specific file or folder within it.

The following is an example <tt>coverage.php</tt> file from '''mod_forum''':

Note: For Moodle versions 3.7 to 3.10, the [https://docs.moodle.org/dev/index.php?title=Writing_PHPUnit_tests&oldid=58177#Check_your_coverage syntax used] was slightly different.
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'externallib.php',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
Also, note that you can better define which class or function each test is effectively covering by using the <tt>@covers</tt> annotation as [https://phpunit.readthedocs.io/en/9.5/code-coverage-analysis.html#specifying-covered-code-parts described in the documention].

Since Moodle 4.0, the following default configuration is applied:{{Moodle 4.0}}
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'tests/generator',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [
'externallib.php',
'lib.php',
'locallib.php',
'renderer.php',
'rsslib.php',
];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
If a coverage.php file already exists, then the defaults will be added to the values already defined.
=Best practice=
There are several best practices, suggestions, and things to avoid which you should consider when writing unit tests. Some of these are described below.
==Code coverage==
PHPUnit has the ability to generate code coverage information for your unit tests and this is well supported since.Moodle 3.7. We recommend that you consider checking the coverage of your plugins when you write your code.

We recommend that you explicitly set the @covers annotation as described in the [https://phpunit.readthedocs.io/en/9.5/annotations.html#appendixes-annotations-covers-tables-annotations PHPUnit documentation].
==Keep use of resetAfterTest to a minimum==
Although many of the examples described above use the <syntaxhighlight lang="php">resetAfterTest</syntaxhighlight> nomenclature to reset the database and filesystem after your test completes, you should ideally not use this unless you have to.
Generally speaking you should aim to write code which is mockable, and does not require real fixtures.
Use of resetAfterTest will also slow your tests down.
==Be careful with shared setUp and instance variables==
You should be careful of how you create and use instance variables in PHPUnit tests for two main reasons:
# If you create any fixtures in the setUp, or call the resetAfterTest function, these fixtures and conditions will apply for _all_ tests in the testsuite. You will not be able to add another test to the suite which does not require these conditions without those conditions being fulfilled anyway. This can lead to slow tests.
# PHPUnit creates an instance of each testcase during its bootstrap phase, and does not dispose of it for the lifetime of the test run. Anything which causes data to be stored as instance data within the testcase will be stored in memory until the _entire suite_ completes. This means that any fixture which is setup and not actively discarded will not be garbage collected and lead to memory bloat. In severe cases this can lead to memory exhaustion.

Existing testcases which contain setUp which either generate data, or set resetAfterTest should be phased out, and no new cases should be introduced.
==Make use of the dataProvider functionality==
The dataProvider functionality of PHPUnit is an extremely powerful and useful feature which allows you to verify a function quickly and easily with a range of different conditions.
However, the following rules should be followed when using dataProviders:
* Keep addition of resettable data requiring resetAfterTest to a minimum - this will lead to many slow tests
* Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation. The dataProvider is called after the testSuite is instantiated, but before any tests are run. Each test will run a full setUp and tearDown, which will destroy any data which was created.
<syntaxhighlight lang="php">
/**
* Test function accepts parameters passed from the specified data provider.
*
* @dataProvider foobar_provider
* @param int $foor
* @param int $bar
*/
public function test_foobar(int $foo, int $bar) {
// Perform the tests here.
}

/**
* Data provider for {@see self::test_foobar()}.
*
* @return array List of data sets - (string) data set name => (array) data
*/
public function foobar_provider(): array {
return [
'Same numbers' => [
'foo' => 42,
'bar' => 42,
],
'Different numbers' => [
'foo' => 21,
'bar' => 84,
],
];
}
</syntaxhighlight>
=Extra test settings=
Usually the test should not interact with any external systems and it should work the same on all systems. But sometimes you need to specify some option for connection to external systems or system configuration. It is intentionally not possible to use $CFG settings from config.php.

There are several ways how to inject your custom settings:
* define test setting constants in your phpunit.xml file
* define test setting constants in your config.php
These constants may be then used in your test or plugin code.
=Upgrading unit tests to work with Moodle 4.4 and up (PHPUnit 9.6)=
{{Moodle 4.4}}

With Moodle 4.4, '''PHPUnit was upgraded to 9.6''' (from 9.5 being used in previous versions). This was done to '''warn to developers in advance''' about functionality that has been deprecated in the 9.5 series and will be removed so will stop working with the next major update to PHPUnit 10.x (see MDL-81266 and linked issues for more details).

While everything should continue working without modification with PHPUnit 9.6, you will may get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be analysed''', replacing or removing them as soon as possible, because all those warnings will become errors with next PHPUnit upgrade.

A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/commit/28892562ca4c06f4f57ca1588c04e608b3d0e22c lib/upgrade.txt] file. With main points being:
* MDL-81281. A number of attribute-related assertions have been deprecated, will be removed with PHPUnit 10. Alternatives for '''some''' of them are available:
- assertClassHasAttribute()
- assertClassNotHasAttribute()
- assertClassHasStaticAttribute()
- assertClassNotHasStaticAttribute()
- assertObjectHasAttribute() => assertObjectHasProperty()
- assertObjectNotHasAttribute() => assertObjectNotHasProperty()
* MDL-81266. A number of deprecation, notice, warning and error expectations have been deprecated, will be removed with PHPUnit 10. No alternative exists. A working replacement is available in the linked issue, hopefully there aren't many cases.
- expectDeprecation()
- expectDeprecationMessage()
- expectDeprecationMessageMatches()
- expectError()
- expectErrorMessage()
- expectErrorMessageMatches()
- expectNotice()
- expectNoticeMessage()
- expectNoticeMessageMatches()
- expectWarning()
- expectWarningMessage()
- expectWarningMessageMatches()
* MDL-81308. The <tt>->withConsecutive()</tt> functionality on PHPUnit mocks has been '''silently''' deprecated, will be removed with PHPUnit 10. Note that this won't affect PHPUnit 9.6 runs and an alternative path will be proposed in the linked issue, part of the PHPUnit 10 epic.
* <tt>PHPUnit\Framework\TestCase::getMockClass()</tt> has been deprecated, will be removed with PHPUnit 10. No clear alternative exists and won't be investigated, because there aren't case in core.
* Cannot use the <tt>Test</tt> suffix on abstract test case classes. Proceed to rename them to end with <tt>TestCase</tt> instead.

=Upgrading unit tests to work with Moodle 3.11 and up (PHPUnit 9.5)=
{{Moodle 3.11}}

With Moodle 3.11, '''PHPUnit was upgraded to 9.5''' (from 8.5 being used in previous versions). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.11 (7.3, 7.4 and [[Moodle and PHP|8.0]]) (see MDL-71036 and linked issues for more details).

While a lot of existing tests will work without modification with PHPUnit 9.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 9.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2020/02/migrating-to-phpunit-9 A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-9.html PHPUnit 9 release Announcement].
* These multiple detailed changelogs (because all them have included modifications requiring changes): [https://github.com/sebastianbergmann/phpunit/blob/9.0.0/ChangeLog-9.0.md 9.0], [https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md 9.1], [https://github.com/sebastianbergmann/phpunit/blob/9.3.0/ChangeLog-9.3.md 9.3], [https://github.com/sebastianbergmann/phpunit/blob/9.5.0/ChangeLog-9.5.md 9.5]
* [https://phpunit.readthedocs.io/en/9.5/ Official PHPUnit manual].
A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/e3a46964dc6d8ca1558c6e1e8dfdf3c1745eeaed/lib/upgrade.txt#L5-L65 lib/upgrade.txt] file. With main points being:
* All the changes that were deprecated with PHPUnit 8.5 (see the section below) are now removed and will lead to errors.
* <tt>assertContains()</tt> now performs stricter comparison (like <tt>assertSame()</tt> does). New <tt>assertContainsEquals()</tt> has been created to provide the old behavior.
* Changes to the <tt>phpunit.xml</tt> schema, mostly internal. These only will impact if you are using custom <tt>phpunit.xml</tt> files:
** The previous <tt><filter></tt> section is now (better) called <tt><coverage></tt>. And, within it:
*** <tt><whitelist></tt> has been replaced by <tt><include></tt>.
*** <tt><exclude></tt> is not a child of <tt><whitelist></tt> anymore, but of <tt><coverage></tt>.
** But with implications when defining the [[#Check your coverage|coverage information]] because <tt>$whitelistxxx</tt> properties used by the <tt>coverage.php</tt> files have been deprecated, instead use <tt>includelistfolders</tt> and <tt>includelistfiles</tt> (to better map the elements in the xml).
* Warning: It's not possible to run individual test files any more. Use any of the alternative execution methods (filter, suite, config) to specify which tests you want to run. This will be hopefully fixed in MDL-71049 once it has been agreed which the best way to proceed is.
* Deprecations, deprecations, deprecations. Lots of them in often used assertions: file assertions, regexp assertions, exception expectations... again, note that all them will become errors with the next PHPUnit update, so '''the recommendation is to update them ASAP'''.
Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/fc335f5...713722c browse the changes associated with the issue], hopefully with useful explanations in the commit messages.

=Upgrading unit tests to work with Moodle 3.10 and up (PHPUnit 8.5)=
{{Moodle 3.10}}

With Moodle 3.10, '''PHPUnit was upgraded to 8.5''' (from 7.5 being used in older version). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.10 (7.2, 7.3 and 7.4) and also to provide an '''easier jump to PHPUnit 9.x''' that will be needed for Moodle 3.11 (php versions 7.3, 7.4 and 8.0), removing a lot of deprecated stuff in advance. (see MDL-67673 and MDL-64600 for more details).

While 99% of existing tests will work without modification with PHPUnit 8.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 8.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2019/02/help-my-tests-stopped-working A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-8.html PHPUnit 8 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/130104cf796a88dd1547dc5beb8bd555c2deb55e/ChangeLog-8.0.md Detailed changelog of the release].
* [https://phpunit.readthedocs.io/en/8.5/ Official PHPUnit manual].
* A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/6594c54b2eef62499d304bfa0939999e3a14246e/lib/upgrade.txt#L5-L37 lib/upgrade.txt] file. With main points being:
** Support for PHP 7.0 dropped (because all template methods (<tt>setUp()</tt>, <tt>tearDown()</tt>..) now require to return void. This will mostly impact 3rd-part plugins that were still running the same tests against old branches of Moodle with PHP 7.0 support.
** <tt>PHPUnit/DBUnit</tt> has been removed are replaced by a lightweight alternative.
** Deprecations, deprecations, deprecations. Lots of them in often used assertions (<tt>assertContains()</tt>, <tt>assertEquals()</tt>...) and also <tt>@expectedExceptionXXX</tt> annotations. Again, note that all them will become errors with PHPUnit 9.
* Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/5903054...b13ec3c browse the changes associated with the issue], hopefully with useful enough explanations in the commit messages.
=Upgrading unit tests to work with Moodle 3.7 and up (PHPUnit 7.5)=
{{Moodle 3.7}}

With Moodle 3.7, '''PHPUnit was upgraded to 7.5''' (from 6.x being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.7 (7.1, 7.2 and 7.3). (see MDL-65204 and linked issues for more details). While internally [https://phpunit.de/announcements/phpunit-7.html a lot of things changed with PHPUnit 7] (PHP 7.1-isms, typed signatures, void returns, assertEquals() changes), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

To find more information about the changes coming with PHPUnit 7, it's recommended to read the following resources:
* [https://phpunit.de/announcements/phpunit-7.html PHPUnit 7 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/520723129e2b3fc1dc4c0953e43c9d40e1ecb352/ChangeLog-7.5.md Detailed changelog of the release], paying special attention to the added, deprecated, changed and deleted sections.
* [https://phpunit.readthedocs.io/en/7.5/ Official PHPUnit manual].
* Changes performed into core, mainly: new, stricter, signatures ([https://github.com/moodle/moodle/commit/26218b7 26218b7]) and assertEquals() changes, specially important when comparing strings, now performed using strict (===) equals ([https://github.com/moodle/moodle/commit/85f47ba 85f47ba]).
=Upgrading unit tests to work with Moodle 3.4 and up (PHPUnit 6)=
{{Moodle 3.4}}

With Moodle 3.4, '''PHPUnit was upgraded to 6.4''' (from 5.5 being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.4 (7.0, 7.1 and 7.2). (see MDL-60611 and linked issues for more details). While internally [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues a lot of things changed with PHPUnit 6] (namespaced classes being the more noticeable), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

Still, in '''some cases, it will impossible to maintain compatibility''' of tests between old (pre 3.4) tests and new ones, especially '''when direct use of any phpunit class is performed'''. Luckily, both GitHub Actions and CI tests will detect this situation and it shouldn't be hard to keep all supported branches in core passing ok. Plugins may be trickier, if the same branch is attempting to work against multiple core branches and they are using some phpunit class directly.

To find more information about the changes coming with PHPUnit 6, it's recommended to read the following resources:
* [https://thephp.cc/news/2017/02/migrating-to-phpunit-6 A very good mini-guide] showing all the important changes.
* [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues PHPUnit 6 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/9d0c024d2099531442d862b66b0ad7cf35ed8e78/ChangeLog-6.0.md Detailed changelog of the release], paying special attention to the changed and deleted sections.
* Changes performed into core, mainly: namespace class renaming ([https://github.com/moodle/moodle/commit/801a372dadb6e11c8781547603e3f0a59ce5638f 801a372]) and deprecated stuff ([https://github.com/moodle/moodle/commit/796e48a58bf18533bdca423fff7949ab119101c4 796e48a])
=See also=
* [[PHPUnit integration]]
* [[PHPUnit]]
[[Category:Unit testing]]

XMLDB Defining one XML structure

2023-09-10T15:00:09Z

Stronk7: Redirected page to XMLDB defining an XML structure

#REDIRECT [[XMLDB defining an XML structure]]

XMLDB defining an XML structure

2023-09-10T14:50:24Z

Stronk7: MDL-76459 - expand database identifiers

[[XMLDB Documentation|XMLDB Documentation]] > [[XMLDB roadmap|Roadmap]] > Defining one XML structure
----

== Justification ==

Moodle supports a number of Database Engines, including MySQL, MariaDB, Postgresql, OCI, and MS SQL Server. Each of
these has a slightly different format for some of their table creation statements.

XMLDB has been created as a standardised format to describe the structure of the database in a human-readable format
which the Moodle installer can turn into DDL commands to create the database structure.

The Moodle XMLDB editor must be used to correctly define the XMLDB structure for all tables within Moodle. It is also able to convert the XMLDB structure into upgrade scripts which can be copied and pasted into Moodle <tt>upgrade.php</tt> files.

== The XMLDB editor ==
[[XMLDB_editor | Main article]]

Although the XML is pretty simple to read (and to write), one of the major drawbacks was its easy and error-prone adoption by the developers. Also some problems with versioning systems getting crazy with XML files (thanks ML!) pointed us to the requirement to use one high-density format (it means, physically '''long lines''') in our XML files.

After some intense thoughts we decided to build one specialised editor for our XML format. This editor should be easy to use and provide support for all the objects present one Moodle DB. And it's done (and will support future enhancements easily, we hope).

The XMLDB Editor makes the addition of tables/fields/keys/indexes practically a trivial task, allowing the developer to spend the time coding and improving things instead of fighting against XML files and the errors caused by manual editing (of course, the developer is free to use such extra-time as desired, beers, dance, books, music...) ;-)

All the new '''install.xml''' files, present under each '''db''' directory in Moodle can be edited (and we recommend it) with just some clicks and keystrokes. Those '''install.xml''' will contain all the info needed to generate the specific objects needed for each RDBMS supported. Obviously, such files, are the neutral replacement for all the *.sql files used until now.

=== Launching ===

Just login to your server as an administrator and, under the Development tab of the Administration Block, you'll see a new link pointing to the "XMLDB Editor".

One '''important note''' is that, to be able to handle files properly, the web server needs write access to all those "db" directories where the "install.xml" files reside (and to the files themselves, of course). ;-)

That's all!

=== Use===

We really think the XMLDB Editor is pretty easy to use, so here you won't see a complete guide to use it. We highly recommend you to play with it for a while, viewing how it works and how it modifies the '''install.xml''' files.

It's organised in a top-bottom structure, where you start '''loading''' (or '''creating''') a new XMLDB file. Then, you can '''edit''' such file and its '''general structure''' will be showed. This structure has one type of elements, '''tables''' and the XMLDB Editor allows you to '''add''', '''edit''', '''delete''', and '''move''' them easily. Additionally it is possible to turn an existing table (under MySQL and MariaDB) into an XMLDB structure, allowing you to retrofit any table from the DB to XMLDB Editor.

'''Note: If you can't click on the create links....''' you must first create the /db folder (as shown in the list, but it may not really exist) and then make sure it is writeable by the webserver

While editing tables you will see their '''fields''', '''keys''' and '''indexes''' and you'll be able to handle all them easily. Note that some fields can be no-editable. It uses to be because they are being used in some way (part of one key or index) and the idea is to warn you about that.

Fields can be edited and you can specify their '''name''', '''type''', '''length''', '''decimals''', '''null-ability''', '''defaults''' and so one. Exactly the same for both '''keys''' and '''indexes'''.

One interesting feature is that all the XMLDB Editor pages allow you to enter one '''comment''' about the item being modified (table, index, key, field, etc). Use it at your entire needs, sure it helps other developers to understand a bit more the DB model.

Please, don't forget to read and understand the next section, where we talk about '''some important guidelines''' to create and handle XMLDB files.

== Conventions ==

Apart of the [[Database| Database Structures guidelines]], some more conventions should be followed:

# About names:
## All lowercase names (tables, indexes, keys and fields).
## Table names and field names must use only a-z, 0-9 and _ chars. Table names can be at most 53 characters long (28 before Moodle 4.3); column names at most 63 characters long (30 before Moodle 4.3).
## Key and index names under the XMLDB Files must be formed by concatenating the name of the fields present in the key/index with the '"-" (minus) character.
## Primary key always must be named "primary" (this is one exception to the previous convention).
## It's highly recommended to avoid [[XMLDB_reserved_words|reserved words]] completely. We know we have some of them now but they should be completely out for next releases.
# About NULLS
## Avoid creating all the fields as NOT NULL with the ''silly'' default value <nowiki>''</nowiki> (empty string). The underlying code used to create tables will handle it properly but the XMLDB structure must be REAL. Read more in the [[XMLDB_Problems#NOT_NULL_fields_using_a_DEFAULT_.27.27_clause|Problems Page]].
# About FOREIGN KEYS
## Under the tables of every XMLDB file, you must define the existing '''Foreign Keys''' (FK) properly. This will allow everybody to know a bit better the structure, allow to evolve to a better constrained system in the future and will provide the underlying code with the needed info to create the proper indexes.
## Note that, if you define any field combination as FK you won't have to create any index on that fields, the code will do it automatically!
## Respect Convention 1.3
# About UNIQUE KEYS
## Declare any fields as UNIQUE KEY (UK) only if they are going to be used as target for one FK. Create unique indexes instead.
## Respect Convention 1.3

== One example: the assignment module ==

Here we are going to examine the [http://cvs.moodle.org/moodle/mod/assignment/db/install.xml?view=markup current implementation of the XMLDB Schema for the assignment module] (a simple one). It has been completely generated with the XMLDB Editor but it's nice to know a bit more about the XML internals.

As you can see the structure is pretty simple:

* XMLDB
** TABLES, one or more, each one with
*** FIELDS
*** KEYS
*** INDEXES
*** SENTENCES

First of all you should note that all the elements contain the '''PREVIOUS''' and '''NEXT''' attributes. They allow us to keep everything ordered although it isn't meaningful at all from the RDBMS perspective. Also the '''COMMENT''' field is present everywhere to be used as desired.

=== The TABLE element ===

We can ignore the TABLE element, as it's simply one container for the internals (FIELDS, KEYS and INDEXES). Let's go to examine them a bit more:

==== The FIELD element ====

It maps with one field in the DB (obviously). For each field you can define its '''name''', '''type''' (from a list of [[XMLDB column types|neutral types]]), '''length''', '''decimals''' (for some types), '''notnull''' (true/false), '''unsigned''' (true/false), '''sequence''' (if it's autonumeric or serial, true/false) and '''default''' (to assign a default value).

So, in our example, we have two tables, assignment and assignment_submissions, each one with its own fields, defining all the information related above. Please note that naming conventions are followed.

==== The KEY element ====

Here is where all the PRIMARY KEYS (PK), UNIQUE KEYS (UK) and FOREIGN KEYS (FK) will be defined. For each key we define its '''name''', '''type''', '''fields''' (that belongs to it) and optionally (if the key is one FK) the target '''reftable''' and '''reffields'''.

In our example, the assignment table has one (mandatory!) PK (called, "primary", rules are rules) built with the "id" field.

The other table, the "assignment_submissions" one, also has its PK (called "primary" once more) and one FK, with the field "assignment" pointing to the field "id" of the table "assignment". Note that the FK follows the name conventions and its name is, simply, the name of the fields being part of it ("assignment"). Also, the FK has as target to one PK of the same module.

Finally, note that there isn't any index created for all these keys. Moodle will generate them automatically when the table is created. All the keys will have their corresponding index. Point. ;-)

==== The INDEX element ====

Where all the indexes will be defined. For each index you can define its '''name''', '''unique''' (true/false) and the '''fields''' (as a comma-separated string) that it comprises. Please note that naming conventions are followed.

Also, some "obvious index", like the one based in the "assignment" field of the "assignment_submissions" table doesn't exist. Yes, you know why: Because such column has been defined as a FK and the index will be automatically created (see previous section).

== DTD and XML schema ==

Not sure if this will be usable for somebody but here you can find one [http://cvs.moodle.org/moodle/lib/xmldb/xmldb.dtd?view=co automatically generated DTD] for the XMLDB files. Also one [http://cvs.moodle.org/moodle/lib/xmldb/xmldb.xsd?view=co automatically generated XML Schema] is available. Any improvement/fix to them will be welcome!

== See also ==

* [[XMLB List of files to create|List of files to create]]: The list of files to be created from scratch. Used to follow the progress.
* http://www.hitsw.com/xml_utilites/: One online XML-DTD-Schema converter.

[[Category:XMLDB]]
[[Category:DB]]

Using XMLDB

2023-09-10T14:24:03Z

Stronk7: MDL-76459 - expand database identifiers

Note: This page is a work in progress. It is intended to help developers of third-party modules, and other plugins, to help them switch to XMLDB.

==What is XMLDB and how can it help you==

XMLDB stores the database definition in an XML format that can be used to install Moodle on any database. Everywhere in Moodle now uses XMLDB.

In every module (or other plugin) folder, there is a ''db/'' folder where the database structure is stored. In the past, this used to contain separate files ''mysql.php'', ''mysql.sql'', etc. for different databases. It meant that you had to create different files for each database system. If there were more databases you wanted your module to be compatible with, you had to create more files. Switching to XMLDB means that you only have to create one file, and there is an editor to help you, so it saves you time.

==Getting started==

The XMLDB database definition is stored in the file ''db/install.xml''. You can use a built-in XMLDB editor to create or edit any ''install.xml'' files. If you're using MySQL as your default database schemes. XMLDB editor's powerful tools allowing retrofit MySQL table to XMLDB format.

The XMLDB editor is located in administration block, go to ''Miscellaneous > XMLDB editor''. Find your module name. Initially you won't be able to click on ''Create'' link and also can't edit your module (If the ''Create'' link is clickable you can skip this step). Since you must make your module folder has write permission first (And if you haven't created ''db/'' folder in your module folder yet, create it now). In Linux operating system, ''chmod'' your ''/db'' folder to 777 solves this. Now you're ready to create your module's XMLDB files.

Note that XMLDB editor is not a tool for creating your module, though it can help you with the database. It is a tool to manage XMLDB database file (think about phpmyadmin manages SQL database). You can create tables/fields/keys/indexes or export your existing MySQL tables to XMLDB.

Another XMLDB's advantage is you can create table comments as you want. To describe it to other developer.

XMLDB editor is really easy to work with. We strongly recommend you to play with it for a while and read [[XMLDB editor]] and about XMLDB structure [[XMLDB defining an XML structure]].

===Create ''install.xml''===

If you never create ''install.xml'' before (your ''db/'' doesn't have ''install.xml''), click ''Create'' first. install.xml will store your database info for this module.

===Start editing===

To start editing ''install.xml'', click ''Load'' and then ''Edit''. You need to do this every time before editing any XMLDB file. If this is your first time, there is a default table named like your module stored.

===Create new table===

# Go to ''New Table''.
# Enter table name and comment, click ''change''.

===Add field in table===

# Click ''Edit'' on your desired table.
# Click ''New Field'', You can now edit field information like name, comment, type, length, etc. See [[XMLDB column types]] for XMLDB column type comparing with other database system.
# When you're done, click ''Change''.

===Retrofit MySQL table to XMLDB===

XMLDB editor can retrofit MySQL table to XMLDB. In other word, it can create XMLDB table from existing SQL. This is useful if your module database already using MySQL.
First, your module has to be installed. Then follow these steps:

# Click ''New Table from MySQL''
# In ''Create Table'' box, choose your table from MySQL database. In ''After Table'' choose where would you like to add this table to (It doesn't matter, just for arrangement). Click ''Create''.
# Do it again until every table added, you are done!

Note: Table name must contains only lowercase character, number, underscore and length must not exceed 53 characters (28 before Moodle 4.3). More info here: [[XMLDB defining an XML structure]]

===Other operation===

It's intuitive once you use it. There are visible links for editing, moving up or down and deleting.

==See also==

*[[XMLDB editor]]
*[[XMLDB introduction]]
*[[XMLDB defining an XML structure]]
*[[XMLDB column types]]

[[Category:XMLDB]]

Database

2023-09-10T12:37:20Z

Stronk7: MDL-76459 - expand database identifiers

==Database structures==

To help you create tables that meet these guidelines, we recommend you use the built in [[XMLDB_defining_an_XML_structure#The_XMLDB_editor|database definition (XMLDB) editor]].

There are [[Moodle_versions#How_to_increment_version_numbers_in_core|rules for how what numbers to use in version.php files in Moodle core]].

# Every table must have an auto-incrementing id field (INT10) as primary key. (see [[IdColumnReasons]])
# The main table containing instances of each module must have the same name as the module (eg widget) and contain the following minimum fields:
#* id - as described above
#* course - the id of the course that each instance belongs to
#* name - the full name of each instance of the module
# Other tables associated with a module that contain information about 'things' should be named widget_things (note the plural).
# Core tables in general should have single word names non-pluralised, and double word names pluralised only for the last word e.g. 'course', 'course_categories'. The only exceptions should be for reserved words e.g. 'files'. Some tables don't fit this pattern right now for historical reasons, but this will eventually be changed.
# Table and column names should avoid using [[XMLDB_reserved_words|reserved words in any database]]. Please check them before creation. Table names may be up to 53 characters long (only 28 before Moodle 4.3), and Column names up to 63 characters long (only 30 before Moodle 4.3).
# Column names should be always lowercase, simple and short, following the same rules as for variable names.
# Where possible, columns that contain a reference to the id field of another table (eg widget) should be called widgetid. (Note that this convention is newish and not followed in some older tables)
# Boolean fields should be implemented as small integer fields (eg INT4) containing 0 or 1, to allow for later expansion of values if necessary.
# Most tables should have a timemodified field (INT10) which is updated with a current timestamp obtained with the PHP time() function.
# Always define a default value for each field (and make it sensible)
# Each table name should start with the database prefix ($CFG->prefix). In a lot of cases, this is taken care of for you automatically. Also, under Postgres, the name of every index must start with the prefix too. Note that, since Moodle 4.3 the max allowed prefix length is 10 characters.
# <span id="as_keyword"></span>In order to guarantee [[XMLDB problems#Table and column aliases - the AS keyword|cross-db compatibility]] follow these simple rules about the use of the '''AS''' keyword (only if you need table/column aliases, of course):
#* '''Don't use''' the '''AS''' keyword for '''table aliases'''.
#* '''Don't use''' '''table aliases''' at all for DELETE statments (Mysql doesn't like it).
#* '''Do use''' the '''AS''' keyword for '''column aliases'''.
# '''Never''' create UNIQUE KEYs (constraints) at all. Instead use UNIQUE INDEXes. In the future, if we decide to add referential integrity to Moodle and we need UNIQUE KEYs they will be used, but not now. Please note that the XMLDB editor allows you to specify both XMLDB-only UNIQUE and FOREIGN constraints (and that's good, in order to have the XML well defined) but only underlying INDEXes will be generated.
# Those XMLDB-only UNIQUE KEYs (read previous point) only must be defined if such field/fields '''are going to be the target''' for some (XMLDB-only too) FOREIGN KEY. Else, create them as simple UNIQUE INDEXes.
# Tables associated '''with one block''' must follow this convention with their names: '''$CFG->prefix + "block_" + name_of_the_block + anything_else'''. For example, assuming that $CFG->prefix is 'mdl_', all the tables for the block "rss_client" must start by 'mdl_block_rss_client' (being possible to add more words at the end, i.e. 'mdl_block_rss_client_anothertable'...). This rule will be 100% enforced with Moodle 2.0, giving time to developers until then. See [http://tracker.moodle.org/browse/MDL-6786 Task 6786] for more info about this.
# '''Never''' make database changes in the STABLE branches. If we did, then users upgrading from one stable version to the next would have duplicate changes occurring, which may cause serious errors.
# When refering to integer variable in SQL queries, do not surround the value in quotes. For example, get_records_select('question', "category=$catid") is right. get_records_select('question', "category='$catid'") is wrong. It hides bugs where $catid is undefined. ([http://moodle.org/mod/forum/discuss.php?d=80629 This thread explains].)
# Never use double quotes for variable values in SQL queries (e.g. <strike>'SELECT * FROM {user} WHERE username = "someuser"'</strike>). While this is OK for MySQL, which does not respect ANSI standard for databases, Postgresql is treating double quoted variable this as system identifier (e.g. field name).
# Moodle does not support database "views", don't use them. See Petr's comment on [http://tracker.moodle.org/browse/MDL-25407 Task 25407] for more info about this.

[[Category:Coding guidelines|Database]]
[[Category:DB|Database]]
[[Category:XMLDB|Database]]

[[es:dev/BasedeDatos]]

Release process

2023-03-24T11:04:13Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:Migrated|newDocId=/general/development/process/release}}
== 8 weeks prior ==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Recurring release epics review:
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous deprecation epics are going] and share about them.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Ensure we are running latest/good behat, phpunit and nodejs (npm) versions.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm external testers daily availability from -6w to release (internally with dev manager and then, externally, with contractors). They start in just 2 weeks!
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| - Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249.
- Remind devs:
* To label issues qa_test_required when a new feature/improvement is landing without automated tests. Also add a comment advising exactly what should be covered in the QA test e.g. steps 6-10 in testing instructions.
* The best possible lang strings land at first attempt. Given the proximity of the major release and to facilitate the work of translators and others... the sooner, the better, instead of relying on (late) en_fixes too much.
| Testing Maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| - Create a "Must fix for X.Y" version in the Tracker and adjust the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Set%20integration%20priority%20to%20one/ "TR - Set integration priority to one"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20reopened%20out%20from%20current/ "TR - Move reopened out from current"] jobs in '''all CI servers''' to point to it.
- Apply the following changes to filters and dashboards:
* Edit the [https://tracker.moodle.org/issues/?filter=21363 All "must fix" issues] filter used both in the release dashboard and to detect wrong uses of must-fix issues. Note that, since 3.7, this filter is fully automated and does not need edition (uses regexp to catch all must fix versions).
* Comment about its creation within HQ, to get people applying for it.
* Verify that these filters ([https://tracker.moodle.org/issues/?filter=18596 1], [https://tracker.moodle.org/issues/?filter=18594 2] and [https://tracker.moodle.org/issues/?filter=18861 3]), used in the [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard], are working ok (they should be, automatically based in the filter edited in the previous point).
* Rename [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard] to point to incoming release (QA part of the dashboard will not work yet)
| Integration Team
|}
==7 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze.
| Head of LMS
|-
| 2.
| style="text-align:center" | ✓
|
| Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20qa_test_required%20AND%20status%20%3D%20Closed closed qa_test_required-labelled issues] and create new QA tests as required.
| Testing Maintainer
|-
|}
==6 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| The [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period Continuous Integration] period begins. Warn about it everywhere (telegram, exposed posts...).
Rolling (on demand, beta, rc... all them together with stable weeklies) happens often (Tuesday & Friday are the usual days). All the team is on integration 100% since this week and until the end of continuous.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Create the next "X.Y+1" (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Warn external developers about the impending code freeze in a post to the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Let the community know [[QA testing]] starts in two weeks and how they can participate.
| Community Manager
|}
==5 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Confirm the code freeze by replying to the previous warning in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum].
| Development manager
|-
| 2.
| style="text-align:center" | ✓
|
| This week, once the freeze has happened at 11:00 UTC:
* The [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job has to be disabled.
* Immediately after that, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration] job must be enabled and executed, only once, and all the candidate issues already @ integration will come to the current queue. All them did the freeze.
* Once run, disable the job again to avoid executing it by mistake.
* Once the previous job has ended, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job, in charge of managing the integration queues after freeze, will be enabled (until the end of on-sync). It performs some tasks like moving important (must fix, qa, security...) issues to the current integration queue and also keep if fed by priority when there are few issues remaining. '''Don't forget''' to configure the "releasedate" date to get it automatically holding issues the last week (instead of moving them to current integration) and also processing issues over the on-sync (after release) period.
Irrespectively from any automation, issues can, also, be manually picked for integration until the post-release "On Sync" period ends, usually 2 weeks after release.

Review all the new features and improvements so, everything "unrelated" with the release, is given the "integration_held" label. That means that will be ignored unless there is an [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period unhold request process] started on them.

Dev leaders promptly vote on held issues labelled with unhold_requested label and decide whether they can be allowed to break the freeze.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Prepare a fresh installation of the [http://qa.moodle.net QA site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.
| QA Master Site Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Begin reviewing [https://lang.moodle.org/mod/forum/view.php?id=7 new and changed English language strings] ready for en_fix to be merged 2 weeks prior.
| English fixes lang pack maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| Review standards certifications (Open Badges, LTI, etc) and schedule in recertification to be performed.
| Development Manager
|}
==4 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Start reviewing fixed issues and add the release_notes label to all issues to be listed in the release notes.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Review requirements for adding user tours for new features in the upcoming release (clone of MDL-72783). Review existing tours and remove very old ones (clone of MDL-72781)
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
|
| Beta release (The Moodle release tool - mdlrelease - manages it): Release normal weeklies but with these changes in the master branch being considered all the time, until we are feature complete (can happen @ -4w - ideally - but also later):
* version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Once the beta is available create the "[https://docs.google.com/spreadsheets/d/1TcMJT3o2Cnyq006lmLWrXJeNQQzyNXz2E_Vbc8ff5EE/edit?usp=sharing|Release testing matrix for X.Y.0]" and share it @ HQ & Dev. chat.
* (Optionally) Announce Beta release in forums (ideally once packages are available).
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Clone MDL-72815 for the X.Y release, adding there all the debugging / PHP notices happening in the web server logs while running tests.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
|
| Release candidates release (The Moodle release tool - mdlrelease - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:
* version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-rcZ" (and MOODLE_XY_RCZ as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).
* Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.
* These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&id=1532512
| Plugins Liaison
|-
| 7.
| style="text-align:center" | ✓
|
| Push any plugins to the plugins database which were previously a part of core.
| Plugins Liaison
|-
| 8.
| style="text-align:center" | ✓
|
| Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [[New docs version process]].
| Community Manager
|-
| 9.
| style="text-align:center" | ✓
|
| Create new QA test cycle and post in moodle.org front page news forum about [[QA testing]].
| Testing Maintainer
|-
| 10.
| style="text-align:center" | ✓
|
| Invite community volunteers to start [[QA testing]].
| Community Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Modify [https://tracker.moodle.org/issues/?filter=11824 Current QA cycle filter] to link to the new QA test cycle
| Testing Maintainer
|-
| 12.
| style="text-align:center" | ✓
|
| Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.
| Testing Maintainer
|-
| 13.
| style="text-align:center" | ✓
|
| Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately.
| Development Manager
|-
| 14.
| style="text-align:center" | ✓
|
| Review the [https://tracker.moodle.org/issues/?filter=17705&jql=filter%20%3D%2011701%20AND%20type%20!%3D%20Bug list of features and improvements submitted before code freeze] which are awaiting integration review and decide on related QA tests to be put on hold.
| Development Manager
|}
==3 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Ask developers to begin QA tests marked [https://tracker.moodle.org/issues/?filter=22055 external_skipped] then [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20test_server_required%20 test_server_required tests] and [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20credentials_required credentials_required tests].
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Create new en and de Moodle Docs version wikis.
| Moodle Docs Maintainer
|-
| 3.
| style="text-align:center" | ✓
|
| Go through all points listed under 3 weeks prior in [[New docs version process]].
| Community Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Review issues with labelled with [https://tracker.moodle.org/issues/?filter=11824&jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC dev_docs_required], prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated.
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify how everything is going and, before the end of the week, decide (dev leaders & integrators) if there are real reasons for delaying any release. Whenever a delay is agreed, run the ''"Release delaying process"'' (doc) actions ASAP.

'''Important note:''' ASAP stands for as soon as possible ;-), the delay needs to happen before the last week before release begins (there are flows changing that week requiring the decision and actions to be taken and applied earlier).
| Development Manager
|}
==2 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
|
Check the number of open QA tests. Depending on the amount of work involved, encourage HQ developers to assist from the start of the week or later in the week in order to achieve the target of 100% pass rate by the end of the week.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
|
Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Merge [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc fixes from en_fix] pack and then integrate them.
| AMOS Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Give Partners complete brandable Marketing pack for release including list and description of major new features.
| Marketing Manager
|-
| 5.
| style="text-align:center" | ✓
|
| Label (ui_change) in the Tracker all pending issues having '''noticeable UI modifications''' and track them in the "[https://docs.google.com/spreadsheets/d/18xZf9OgKrndi7CwSTwjwjF_rzGYCWFuGjNNaaDVZDM4/edit?usp=sharing Late landing UI changes]" sheet, in order to have all the associated docs, screenshots, videos under control. The Integration and Documentation people will try to '''keep the sheet updated until release'''.
|Integration Team
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
|
For major releases, use (clone if needed) MDL-72836 to keep the security.txt files in all supported branches updated. For minor releases, also check the security.txt expiry dates in all security supported branches in case known release delays will result in any security.txt expiring before the next release - in that case relevant branches should also be updated.
| Security Officer
|-
|7.
| style="text-align:center" |✓
| style="text-align:center" |✓
|
Identify issues that may block the release (e.g. security, must-fix issues, etc.) and confirm with team leads. This is to ensure that these issues are prioritised and allow us to be able to land them as early as possible and ensure a timely release schedule.
|Integration Lead
|}
==1 week prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" |#
! style="width:20px" |Major
! style="width:20px" |Minor
!Task
! style="width:12%" |Responsibility
|-
|1.
| style="text-align:center" |✓
|
|Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).
|Integration Team
|-
|2.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
|Integration Team
|-
|3.
| style="text-align:center" |✓
|
|Clone MDL-71583 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates.
|Integration Team
|-
|4.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Post a "Heads-up" message on the [http://moodle.org/mod/forum/view.php?id=55 General Developer forum] and [https://moodleassociation.org/ MUA website].
|Development Manager
|-
|5.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Post a "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
|6.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Post a "Heads-up" message on Twitter and other outlets.
|Marketing Officer
|-
|7.
| style="text-align:center" |✓
| style="text-align:center" |
✓
|Identify security issues that need to be integrated using the [https://tracker.moodle.org/issues/?filter=21712 security issues under integration filter] (includes held, being integrated and ready issues).
*Integrate from provided patches into supported branches (including branches supported only for security issues).
* Ensure security issues are given priority in weekly integration and testing. Note that the --weekly releases to be performed this week are 100% normal and cover the standard (supported) branches. security branches will come as part of the release process later in the week.
|Integration Team
|-
|8.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Collect security issues into a clone of the [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20level%20is%20not%20EMPTY%20AND%20summary%20~%20%22security%20advisories%22%20ORDER%20BY%20updated%20DESC last advisory in the list] to prepare for release of Security Advisories.
*Determine which security issues will be integrated.
* Request CVE Identifiers by emailing issue descriptions to [mailto:secalert@redhat.com secalert@redhat.com] with a message like... <tt> The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC.</tt> The email subject should include the characters <tt>[vs]</tt>. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available (since 2015 we request identifiers from redhat and not from distros).
* Post security issues as a reply to the "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
|9.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Release notes tasks:
* Review and complete the [[Releases|release notes]], making sure that issues have easily understandable summaries. Aim to have the release notes mostly complete on the Wednesday before release, and fully complete on the Friday, to give translators time to translate them.
*Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
|Development Manager
|-
|10.
| style="text-align:center" |✓
|
| Review the following issues:
* Check on the [https://tracker.moodle.org/issues/?filter=21363 "Must fix for X.Y version"]. Filter out unrealistic issues.
*Check on the [https://tracker.moodle.org/issues/?filter=22350 "Bug issues held last week before release"]. Consider to request the unholding of release related/blocker ones.
|Development Manager
|-
|11.
| style="text-align:center" |✓
|
|Upgrade moodle.org to beta release
|
|-
|12.
| style="text-align:center" |✓
|
|Prepare pull requests for CI Repositories:
*MR1: Create a new version, with unit tests, in Jobs repository ([https://git.in.moodle.com/integration/nightlyjobs/merge_requests/24 see example from 3.11 release])
* MR2: Create a new symlink for the version in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/41 see example from 3.11 release])
* MR3: Configure CIs to skip language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/35 see example from 3.10 release])
*MR4: Configure CIs to stop skipping language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository for after on-sync ([https://github.com/moodlehq/moodle-ci-runner/pull/40 see example from 3.10 release]) -- Note: This change should be based on the previous and only applied when the lang packs corresponding to the version being released are available.
|Integration Team
|-
|13.
| style="text-align:center" |✓
|
|Go through all points listed under 1 week prior in [[New docs version process]].
| Community Manager
|-
|}
==Releasing ==
===Packaging===
This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).
{| class="table table-striped table-bordered"
|-
! style="width:20px" |#
! style="width:20px" |Major
! style="width:20px" |Minor
!Task
! style="width:12%" |Responsibility
|-
|1.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Check list:
*Make sure there are no real blockers introduced in the last weekly (install / upgrade ...).
* Confirm that the latest [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc en_fix changes]have been generated and integrated.
* Verify that [https://tracker.moodle.org/issues/?jql=text%20~%20%22%2BPrepare%20%2Bsecurity%20%2Badvisories%20%2Bfriends%22%20ORDER%20BY%20updated%20DESC all security issues] have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).
|Integration Team
|-
|2.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Verify all unit tests and integration tests have passed (check all current CI servers in use).
|Integration Team
|-
|3.
| style="text-align:center" |✓
|
|Verify QA tests have passed.
|Integration Team
|-
|4.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Timing prerequisites (don't continue with the process if not within the time window!):
#Latest weeklies before the minor/major releases must be done (moodle-package-extract-and-postprocess email should confirm this has happened around 09:00 Australia/Perth).
#Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).
(in practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). Breaking any of these rules will require manual operation in the server, forcing repackaging and releasing.

Follow the "mdlrelease" steps:
*Run the '''prerelease.sh''' script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg... changes (only for majors)... Triple verify all changes are correct! (can use the --show option to inspect them). Follow the on-screen instructions.
*Push changes to integration.git (but tags).
For major releases, only when a new STABLE branch has been created:
*Run the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
*Push changes to integration.git - note this will lead to the "versions checker" failing for master, no problem, it will be fixed by the 1st cloned issue at #12 below).
*Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY stable branch.
*Update the old CI server(s) by cloning all the "master" jobs to a new "MXY" view (trick: do it down-top, way easier). Don't forget to re-chain the jobs properly.
**Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE.
**Configure the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
**Run all them.
*Update the new CI infrastructure:
**MR1: Merge pull request for new version in [https://git.in.moodle.com/integration/nightlyjobs CI Jobs Repository]
**MR2: Merge pull request for symlink in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
**MR3: Merge pull request for skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
**Clone all the "B - master" jobs to a new "B - XY" view (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20view/ maintenance job] to perform the operation).
Both with minors and majors, continue with the "mdlrelease" steps:
*Once CI servers have ended and all jobs have passed, '''push tags''' and run the '''release.sh''' script to apply the changes to moodle.git.
*If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
*Don't forget the "[https://github.com/moodlehq/mdlrelease/#after-the-release After the release]" tasks.
|Integration Team
|-
|5.
| style="text-align:center" |✓
| style="text-align:center" | ✓
|Post a "git repos updated & tagged" message on the [https://partners.moodle.com/mod/forum/view.php?id=810 Partner forum]
|Integration Team
|-
|6.
| style="text-align:center" |✓
|
|In the [https://github.com/moodlehq/moodle-performance-comparison performance comparison repository], set the new release commit hash as $basecommit in the master branch and create a new MOODLE_XY_STABLE branch from it. ([https://github.com/moodlehq/moodle-performance-comparison/commit/7c875f03e52641f69674235a8947131d77691299 example]). Also, apply it to the current performance testing infrastructure.
|Integration Team
|-
|7.
| style="text-align:center" | ✓
| style="text-align:center" |✓
|Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email).
| Integration Team
|-
|8.
| style="text-align:center" |✓
|
|
*Create new windows packager script (cloning the current master one and configuring it).
*Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Push it. Next time the plugin is deployed (normally 1 week after release, aprox.) the stats will start showing the new branch statistics.
|Integration Team
|-
|9.
| style="text-align:center" |✓
| style="text-align:center" |✓
|In the Tracker...
* Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Plugins project].
*Archive all versions but the ones being released, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
*Remove from all screens the custom fields belonging to 100% unsupported branches.
For major releases only:
*Release and archive the [https://tracker.moodle.org/issues/?jql=affectedVersion%20~%20%22must%20fix%20for*%22%20OR%20fixVersion%20~%20%22must%20fix%20for*%22 "Must fix for X.Y" versions], it must be empty to do so.
|Integration Team
|-
|10.
| style="text-align:center" |✓
|
|
* Create the new "Pull X.Y Branch" and "Pull X.Y Diff URL" custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Re-index Tracker.
*In the CI server edit the [http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ "Bulk precheck issues"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(awaiting_integration)/ "Pre-launch DEV jobs (awaiting_integration)"], [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(list_of_mdls)/ "Pre-launch DEV jobs (list_of_mdsl)"] and [https://ci.moodle.org/view/Tracker/job/STR%20-%20Bulk%20pre-launch%20SDEV%20jobs%20(list_of_mdls)/ "Pre-launch SDEV jobs (list_of_mdsl)"] jobs to make them meet the new "Pull X.Y Branch" field created. At the same time, remove from those jobs any branch belonging to 100% unsupported branches.
*Edit the "Tracker - CI - Check marked as integrated" job ([https://ci.moodle.org/view/Tracker/job/TR%20-%20Check%20marked%20as%20integrated/ link]) to configure the development branches (devbranches) (39, 310, 311, 400...) actually active. Normally only the branch corresponding to master, but also accepts a comma separated list when under parallel development ("310,400" or "311,400" for example). Ordered by planned release date.
*Check/configure (again, this may be has been already executed few steps above) the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
|Integration Team
|-
|11.
| style="text-align:center" |✓
| style="text-align:center" |✓
|In the Tracker...
For major releases only:
*Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.
*Adjust the [https://tracker.moodle.org/issues/?filter=17528 Latest regressions] filter (requires login).
For all releases:
*Verify how the "X.Y regressions" versions [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(versionMatches(%22.*regressions%22)) are going] (requires login) and ping Development Managers about. Package and archive them once empty.
|Integration Team
|-
|12.
| style="text-align:center" |✓
|
|Clone MDL-74509 and MDL-74510, to be resolved ASAP.
|Integration Team
|-
|13.
| style="text-align:center" | ✓
|
|
*Create the new MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security repo (branching from the just created upstream MOODLE_XY_STABLE branch).
*Cherry pick any security commit present in the security repository's master branch to the new MOODLE_XY_STABLE branch (note that normally there should not be any, see point #1 check list above).
*Verify the new security jobs exist for the new branch and check it's working in all servers, keeping only enabled the public one.
|Integration Team
|-
|14.
| style="text-align:center" |✓
|
|Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 )
|Integration Team
|}
===Release day===
Usually on Monday
{| class="table table-striped table-bordered"
|-
! style="width:20px" |#
! style="width:20px" |Major
! style="width:20px" |Minor
!Task
! style="width:12%" |Responsibility
|-
|1.
| style="text-align:center" |✓
| style="text-align:center" |✓
|The execution of "moodle-package-extract-and-postprocess X" script may be needed if the releases '''are not going to be published on Monday''' but another weekday (X is the weekday, (1-7) starting in Monday).
By default it happens automatically around 09:00 AM Perth/Australia time (check emails then).
| Integration Team
|-
|2.
| style="text-align:center" | ✓
| style="text-align:center" |✓
|Verify release status, download pages and windows packages.
|Integration Team
|-
|3.
| style="text-align:center" |✓
| style="text-align:center" |✓
| If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes.
|Integration Team
|-
|4.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.
|Integration Team
|-
|5.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Notify all registered sys admins, including security notes with CVE identifiers, using the [http://lists.moodle.org/ mailing list server].
|Security Officer
|-
|6.
| style="text-align:center" |✓
|
|Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]
|Head of LMS
|-
|7.
|
| style="text-align:center" |✓
| Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]
|Development Manager
|-
|8.
| style="text-align:center" | ✓
|
|New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period.
|AMOS Maintainer
|-
|9.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Verify, 24h after tagging, that https://moodle.org/dev/contributions.php has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!
|Integration Team
|-
|10.
| style="text-align:center" |✓
|
| For en and de Moodle Docs, update default redirects and enable email notifications.
|Moodle Docs Maintainer
|-
|11.
| style="text-align:center" |✓
|
|Go through all points listed under Day of release in [[New docs version process]].
|Community Manager
|-
|12.
| style="text-align:center" |✓
|
|
*Decide the "Full demo", "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar]. They will be -7w, -5w and -4w before release date respectively.
*Update the "Full demo", "Code freeze", "QA begins" and Release dates on the [[Roadmap]] page.
*Add events to the HQ calendar for next Major release 6-months cycle according to [[Process#Sprints|the cycle plan]]: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
*Notify the Community Manager of new dates to be added to the moodle.org calendar.
|Development Manager
|-
|13.
| style="text-align:center" |✓
| style="text-align:center" |
|Add calendar events in the [https://moodle.org/calendar moodle.org calendar] for coming Major and Minor releases up to the next Major release.
|Community Manager
|-
|14.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Update release schedule image on [[Releases#Version_support|Releases page]]
|Development Manager
|-
|15.
| style="text-align:center" |✓
|
|Important: This must be done '''once it's already release day @ UTC''' (aka, after Australia/Perth 08:00) or the '''queues manage with hold them again''' because it's still "last week before release".
The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed '''only''' [https://tracker.moodle.org/issues/?jql=filter%3D13669%20AND%20type%20in%20(bug%2C%20task%2C%20Sub-task) from '''bug issues''' awaiting integration]; they correspond to last-week bugs that were held because of them being unrelated with the release. Now they can be processed, under on-sync rules. Standard message will be used to explain the un-hold.
| Integration Team
|}
==1 week after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" |Major
! style="width:20px" |Minor
!Task
! style="width:12%" |Responsibility
|-
|1.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).
For major releases, within the on-sync period, master packages will be generated using the prerelease.sh script (--type on-sync). That guarantees XY_STABLE and master versions are kept the same. The last week, when leaving the on-sync period, master package will be generated normally (implicit --type weekly), so versions will diverge and dev can continue separately from that point.
|Integration Team
|-
|2.
| style="text-align:center" |✓
| style="text-align:center" | ✓
|Update the version.php in git to be X.Y.Z+ during the next weekly integration process
|Integration Team
|-
| 3.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].) Add note to top of relevant version page about security support.
| Development Manager
|-
|4.
| style="text-align:center" |✓
| style="text-align:center" |✓
|Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
||Security Officer
|-
| 5.
| style="text-align:center" |✓
| style="text-align:center" | ✓
|Notify about publications of CVE using form: https://cveform.mitre.org/
|Security Officer
|-
|6.
| style="text-align:center" |✓
|
|Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
|
|-
|7.
| style="text-align:center" |✓
|
|'''Deprecations:'''
*Create the next deprecation epic (for X.Y+1+2y) similar to MDL-74579 and add standard issues to it:
**Final deprecation of lib/deprecatedlib.php (like MDL-74580)
**Removal of deprecated Behat steps (like MDL-74581)
**Removal of strings (like MDL-74582) and
**Removal of renamed classes (MDL-74583).
The issue can be based/cloned on the previous one and linked ("has to be done after") with it.
*Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous deprecation epics are going] and share about them.

'''Libraries:'''
*Create the next third party libraries epic for X.Y+1, similar to MDL-73715. The issue should refer to the list of [[Moodle libraries credits]]. The issue can be based/cloned on the previous one and linked ("has to be done after") with it. '''Drag/link opened issues from the previous one''', avoiding leaving unfinished stuff.
*Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20(summary%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20OR%20summary%20~%20%22Review%20third-party%20libraries%20for%20upgrade%22)%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous library review epics are going] and share about them.
|Integration Team
|}
== 2 weeks after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" |#
! style="width:20px" |Major
! style="width:20px" |Minor
!Task
! style="width:12%" |Responsibility
|-
|1.
| style="text-align:center" |✓
|
|Once the "On Sync" period ends:
*Confirm that versions (XY_STABLE and master) diverged properly the last on-sync week. If not, proceed to it by manually bumping master the version to the current date @ integration.git.
* Disable the "[https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous"] job. It has served us well.
*The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed from all issues awaiting integration, so they will be, automatically (see next point), be moved to the current integration queue. Send an "unholding + rebase" message to all those issues.
*Enable the "[https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal"] job. It will control the queues over the coming months, until the next freeze.
*In the [https://ci.moodle.org/ Jenkins CI server] enable all the jobs corresponding to the new branch (B-XYZ view) that were created on packaging day.
|Integration Team
|-
| 2.
| style="text-align:center" |✓
|
| The discussion about environmental requirements for next X.Y+1 major release (MDL-71747) will end and the issue will be resolved '''immediately'''. A new issue, about the requirements for nextthe -next X.Y+2 major release wil,l be created at the same time by cloning the previous one and dragging any non-resolved detail (due date = 3w after release).
| Integration Team
|-
|3.
| style="text-align:center" |
✓
|
|Ensure [https://download.moodle.org/langpack/X.Y+1/ Language pack for master (X.Y+1)] is available and merge the pull request MR4 for stop skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
|Integration Team
|-
|4.
| style="text-align:center" |✓
|
|Ensure release retrospectives are held for each of the LMS teams and results are actioned.
|Development Manager / Head of LMS
|}
==1 month after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" |#
! style="width:20px" |Major
! style="width:20px" |Minor
!Task
! style="width:12%" |Responsibility
|-
| 1.
| style="text-align:center" |✓
|
|Remove, in CI servers, all the jobs and views corresponding to branches which support has ended completely. (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Remove%20all%20jobs%20from%20view/ maintenance job] to perform the operation).
|Integration Team
|-
|2.
| style="text-align:center" |✓
|
| Upgrade all the Moodle CI sites to recent major release by configuring the "Moodle CI Auto Upgrade" job in all them.
|Integration Team
|-
|3.
| style="text-align:center" |✓
|
|Confirm that there isn't any remaining [https://tracker.moodle.org/issues/?filter=13669 integration_held] issue from latest release, proceeding to uhhold them immediately. Note that there may exist [https://tracker.moodle.org/issues/?filter=13669&jql=project%20%3D%20MDL%20AND%20labels%20in%20(integration_held)%20ORDER%20BY%20%22Integration%20priority%22%20DESC%2C%20priority%20DESC%2C%20votes%20DESC%2C%20%22Last%20comment%20date%22%20ASC other "held" issues], unrelated with latest release. This process step does not affect them.
|Integration Team
|}
==See also==
*[[Deprecation|Deprecation process]]
[[Category:Processes|Release process]]
[[Category:Release notes|Release process]]

Writing PHPUnit tests

2023-03-24T11:03:30Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Moodle 2.3}}

Moodle PHPUnit integration is designed to allow easy adding of new tests. At the start of each test the state is automatically reset to fresh new installation (unless explicitly told not to reset).
=Namespaces=
All the stuff under **/tests directories is [[Coding style#Namespaces_within_.2A.2A.2Ftests_directories|subject to some simple rules]] when using namespaces. They apply to test cases, fixtures, generators and, in general, any class within those directories. Take a look to them! (grand summary = 100% the same rules that are applied to **/classes directories).
=Testcase classes=
There are three basic test class that are supposed to used in all Moodle unit tests - basic_testcase, advanced_testcase and provider_testcase. '''Please note it is strongly recommended to put only one testcase into each class file.'''
;basic_testcase : Very simple tests that do not modify database, dataroot or any PHP globals. It can be used for example when trying examples from the official PHPUnit tutorial.
;advanced_testcase : Enhanced testcase class enhanced for easy testing of Moodle code.
;provider_testcase: Enhanced testcase class, enhanced for easy testing of [[Privacy API|Privacy Providers]].
There is a fourth testcase class that is specially designed for testing of our Moodle database layer, it should not be used for other purposes.
== Assertions ==
The complete list of assertions can be found in the links below.
{| class="wikitable" border="1"
|-
! Moodle version
! PHPUnit version
!Links
|-
| Moodle 3.11
| PHPUnit 9.5
|[https://phpunit.readthedocs.io/en/9.5/assertions.html Documentation]
|-
| Moodle 3.10
| PHPUnit 8.5
|[https://phpunit.readthedocs.io/en/8.5/assertions.html Documentation]
|-
| Moodle 3.7 - 3.9
| PHPUnit 7.5
|[https://phpunit.readthedocs.io/en/7.5/assertions.html Documentation]
|-
| Moodle 3.4 - 3.6
| PHPUnit 6.5
|[https://phpunit.de/manual/6.5/en/assertions.html Documentation]
|}
==Sample plugin testcase==
PHPUnit tests are located in <tt>tests/*_test.php</tt> files in your plugin, for example <tt>mod/myplugin/tests/sample_test.php</tt>, the file should contain only one class that extends <tt>advanced_testcase</tt>:
<syntaxhighlight lang="php">
namespace mod_myplugin;

class sample_test extends \advanced_testcase {
public function test_adding() {
$this->assertEquals(2, 1+2);
}
}
</syntaxhighlight>
See [[PHPUnit integration#Class and file naming rules]] for more information.
==Inclusion of Moodle library files==
If you want to include some Moodle library files you should always declare '''global $CFG'''. The reason is that testcase files may be included from non-moodle code which does not make the global $CFG available automatically.
==Automatic state reset==
By default after each test Moodle database and dataroot is automatically reset to the original state which was present right after installation. make sure to use $this->resetAfterTest() to indicate that the database or changes of standard global variables are expected.

If you received the error "Warning: unexpected database modification, resetting DB state" it is because the test is not using <tt>$this->resetAfterTest()</tt>.
<syntaxhighlight lang="php">
namespace mod_myplugin;

class test_something extends \advanced_testcase {
public function test_deleting() {
global $DB;
$this->resetAfterTest(true);
$DB->delete_records('user');
$this->assertEmpty($DB->get_records('user'));
}
public function test_user_table_was_reset() {
global $DB;
$this->assertEquals(2, $DB->count_records('user', array()));
}
}
</syntaxhighlight>
=Generators=
Tests that need to modify default installation may use generators to create new courses, users, etc. All examples on this page should be used from test methods of a test class derived from advanced_testcase.

Note if you are using PHPUnit [https://phpunit.de/manual/current/en/writing-tests-for-phpunit.html#writing-tests-for-phpunit.data-providers @dataProvider] functions to provide parameters to unit tests, you can not use the data generator or change the user etc in the data provider function. Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation.
==Creating users==
At the start of each test there are only two users present - guest and administrator. If you need to add more test accounts use:
<syntaxhighlight lang="php">
$user = $this->getDataGenerator()->create_user();
</syntaxhighlight>
You may also specify properties of the user account, for example:
<syntaxhighlight lang="php">
$user1 = $this->getDataGenerator()->create_user(array('email'=>'user1@example.com', 'username'=>'user1'));
</syntaxhighlight>
By default no user is logged-in, use setUser() method to change current $USER value:
<syntaxhighlight lang="php">
$this->setUser($user1);
</syntaxhighlight>
Guest and admin accounts have a shortcut methods:
<syntaxhighlight lang="php">
$this->setGuestUser();
$this->setAdminUser();
</syntaxhighlight>
Null can be used to set current user back to not-logged-in:
<syntaxhighlight lang="php">
$this->setUser(null);
</syntaxhighlight>
==Creating course categories==
<syntaxhighlight lang="php">
$category1 = $this->getDataGenerator()->create_category();
$category2 = $this->getDataGenerator()->create_category(array('name'=>'Some subcategory', 'parent'=>$category1->id));
</syntaxhighlight>
==Creating courses==
<syntaxhighlight lang="php">
$course1 = $this->getDataGenerator()->create_course();

$category = $this->getDataGenerator()->create_category();
$course2 = $this->getDataGenerator()->create_course(array('name'=>'Some course', 'category'=>$category->id));
</syntaxhighlight>
==Creating activities==
Some activity plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php.

Example of creation of new course with one page resource:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$generator = $this->getDataGenerator()->get_plugin_generator('mod_page');
$generator->create_instance(array('course'=>$course->id));
</syntaxhighlight>
The following is functionally the same, but a bit shorter:
<syntaxhighlight lang="php">
$course = $this->getDataGenerator()->create_course();
$page = $this->getDataGenerator()->create_module('page', array('course' => $course->id));
</syntaxhighlight>
==Creating cohorts==
{{Moodle 2.4}}
Since 2.4 there the data generator supports creation of new cohorts.
<syntaxhighlight lang="php">
$cohort = $this->getDataGenerator()->create_cohort();
</syntaxhighlight>
==Simplified user enrolments==
{{Moodle 2.4}}
Instead of standard enrolment API it is possible to use simplified method in data generator. It is intended to be used with self and manual enrolment plugins.
<syntaxhighlight lang="php">
$this->getDataGenerator()->enrol_user($userid, $courseid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid);
$this->getDataGenerator()->enrol_user($userid, $courseid, $teacherroleid, 'manual');
</syntaxhighlight>
==Creating scales==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_scale();
$this->getDataGenerator()->create_scale(array('name' => $name, 'scale' => $scale, 'courseid' => $courseid, 'userid' => $userid, 'description' => description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
==Creating roles==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_role();
$this->getDataGenerator()->create_role(array('shortname' => $shortname, 'name' => $name, 'description' => description, 'archetype' => $archetype));
</syntaxhighlight>
==Creating tags==
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_tag();
$this->getDataGenerator()->create_tag(array(
'userid' => $userid,
'rawname' => $rawname,
'name' => $name,
'description' => $description,
'descriptionformat' => $descriptionformat,
'flag' => $flag
));
</syntaxhighlight>
==Groups==
===Creating groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group(array('courseid' => $courseid));
$this->getDataGenerator()->create_group(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding users to groups===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid));
$this->getDataGenerator()->create_group_member(array('userid' => $userid, 'groupid' => $groupid, 'component' => $component, 'itemid' => $itemid));
</syntaxhighlight>
===Creating groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid));
$this->getDataGenerator()->create_grouping(array('courseid' => $courseid, 'name' => $name, 'description' => $description, 'descriptionformat' => $descriptionformat));
</syntaxhighlight>
===Adding groups to groupings===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grouping_group(array('groupingid' => $groupingid, 'groupid' => $groupid));
</syntaxhighlight>
==Repositories==
===Creating repository instances===
{{Moodle 2.5}}
Some respository plugins include instance generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository($type, $record, $options);
</syntaxhighlight>
===Creating repository types===
{{Moodle 2.5}}
Some respository plugins include type generators. The generator class are defined in plugindirectory/tests/generator/lib.php..
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_repository_type($type, $record, $options);
</syntaxhighlight>
==Creating grades==
===Grade categories===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid));
$this->getDataGenerator()->create_grade_category(array('courseid' => $courseid, 'fullname' => $fullname));
</syntaxhighlight>
===Grade items===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_item();
$this->getDataGenerator()->create_grade_item(array('itemtype' => $itemtype, 'itemname' => $itemname, 'outcomeid' => $outcomeid, 'scaleid' => $scaleid, 'gradetype' => $gradetype));
</syntaxhighlight>
===Outcomes===
<syntaxhighlight lang="php">
$this->getDataGenerator()->create_grade_outcome();
$this->getDataGenerator()->create_grade_item(array('fullname' => $fullname));
</syntaxhighlight>
==Other types of plugin==
{{Moodle 2.5}}
Any other type of plugin can have a generator. The generator class should extend component_generator_base, and then you can get an instance using $mygenerator = $this->getDataGenerator()->get_plugin_generator($frankenstylecomponentname);

For some types of plugin, like mod documented above, there may be a more specific class than component_generator_base to extend, like testing_module_generator. That will give a consistent set of method names to use. Otherwise, you can create whatever methods you like on your generator, to create the different things you need to work whith.
=Long tests=
All standard test should execute as fast as possible. Tests that take a loner time to execute (>10s) or are otherwise expensive (such as querying external servers that might be flooded by all dev machines) should be execute only when PHPUNIT_LONGTEST is true. This constant can be set in phpunit.xml or directly in config.php.
=Large test data=
See advanced_testcase::createXMLDataSet() and advanced_testcase::createCsvDataSet() and related functions there for easier ways to manage large test data sets within files rather than arrays in code. See [[PHPUnit_integration#Extra_methods]]
=Testing sending of messages=
{{Moodle 2.4}}
You can temporarily redirect all messages sent via message_send() to a message sink object. This allows developers to verify that the tested code is sending expected messages.

To test code using messaging first disable the use of transactions and then redirect the messaging into a new message sink, you can inspect the results later.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
$sink = $this->redirectMessages();
//... code that is sending messages
$messages = $sink->get_messages();
$this->assertEquals(3, count($messages));
//.. test messages were generated in correct order with appropriate content
</syntaxhighlight>
=Testing sending of emails=
{{Moodle 2.6}}
You can temporarily redirect emails sent via email_to_user() to a email message sink object. This allows developers to verify that the tested code is sending expected emails.

To test code using messaging first unset 'noemailever' setting and then redirect the emails into a new message sink where you can inspect the results later.
<syntaxhighlight lang="php">
unset_config('noemailever');
$sink = $this->redirectEmails();
//... code that is sending email
$messages = $sink->get_messages();
$this->assertEquals(1, count($messages));
</syntaxhighlight>
=Logstores=
You can test events which were written to a logstore, but you must disable transactions, enable at least one valid logstore, and disable logstore buffering to ensure that the events are written to the database before the tests execute.
<syntaxhighlight lang="php">
$this->preventResetByRollback();
set_config('enabled_stores', 'logstore_standard', 'tool_log');
set_config('buffersize', 0, 'logstore_standard');
get_log_manager(true);
</syntaxhighlight>
=Check your coverage=
{{Moodle 3.7}}
PHPUnit has the ability to generate code coverage information for your unit tests.

Prior to Moodle 3.7, this coverage would load all files and generate coverage for everything regardless of whether that file could be covered at all, or whether it was intentionally covered.

Since Moodle 3.7 the '''phpunit.xml''' configuration contains generated coverage include and exclude information for each component.
==Generating include and exclude configuration==
{{Moodle 3.11}}
You can programatically describe which files will be checked for coverage by creating a <tt>coverage.php</tt> file alongside the tests that you are writing.

Since Moodle 4.0, a default configuration is applied for all plugins and it is not necessary to supply a coverage.php unless you wish to cover additional files.

The <tt>coverage.php</tt> file allows you to list include and exclude files and folders within the component being
tested. All paths specified are relative to the component being tested. For example, when working with '''mod_forum''' your
code will be in '''mod/forum''', and its unit tests will be in '''mod/forum/tests/example_test.php'''. The coverage file
for this would be in '''mod/forum/tests/coverage.php''' and all paths specified would be relative to '''mod/forum'''.

It is possible to specify a combination of included files, included folders, excluded files, and excluded folders. This would allow you, for example, to include the entire '''classes''' directory, but exclude.a specific file or folder within it.

The following is an example <tt>coverage.php</tt> file from '''mod_forum''':

Note: For Moodle versions 3.7 to 3.10, the [https://docs.moodle.org/dev/index.php?title=Writing_PHPUnit_tests&oldid=58177#Check_your_coverage syntax used] was slightly different.
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'externallib.php',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
Also, note that you can better define which class or function each test is effectively covering by using the <tt>@covers</tt> annotation as [https://phpunit.readthedocs.io/en/9.5/code-coverage-analysis.html#specifying-covered-code-parts described in the documention].

Since Moodle 4.0, the following default configuration is applied:{{Moodle 4.0}}
<syntaxhighlight lang="php">
return new class extends phpunit_coverage_info {
/** @var array The list of folders relative to the plugin root to include in coverage generation. */
protected $includelistfolders = [
'classes',
'tests/generator',
];

/** @var array The list of files relative to the plugin root to include in coverage generation. */
protected $includelistfiles = [
'externallib.php',
'lib.php',
'locallib.php',
'renderer.php',
'rsslib.php',
];

/** @var array The list of folders relative to the plugin root to exclude from coverage generation. */
protected $excludelistfolders = [];

/** @var array The list of files relative to the plugin root to exclude from coverage generation. */
protected $excludelistfiles = [];
};
</syntaxhighlight>
If a coverage.php file already exists, then the defaults will be added to the values already defined.
=Best practice=
There are several best practices, suggestions, and things to avoid which you should consider when writing unit tests. Some of these are described below.
==Code coverage==
PHPUnit has the ability to generate code coverage information for your unit tests and this is well supported since.Moodle 3.7. We recommend that you consider checking the coverage of your plugins when you write your code.

We recommend that you explicitly set the @covers annotation as described in the [https://phpunit.readthedocs.io/en/9.5/annotations.html#appendixes-annotations-covers-tables-annotations PHPUnit documentation].
==Keep use of resetAfterTest to a minimum==
Although many of the examples described above use the <syntaxhighlight lang="php">resetAfterTest</syntaxhighlight> nomenclature to reset the database and filesystem after your test completes, you should ideally not use this unless you have to.
Generally speaking you should aim to write code which is mockable, and does not require real fixtures.
Use of resetAfterTest will also slow your tests down.
==Be careful with shared setUp and instance variables==
You should be careful of how you create and use instance variables in PHPUnit tests for two main reasons:
# If you create any fixtures in the setUp, or call the resetAfterTest function, these fixtures and conditions will apply for _all_ tests in the testsuite. You will not be able to add another test to the suite which does not require these conditions without those conditions being fulfilled anyway. This can lead to slow tests.
# PHPUnit creates an instance of each testcase during its bootstrap phase, and does not dispose of it for the lifetime of the test run. Anything which causes data to be stored as instance data within the testcase will be stored in memory until the _entire suite_ completes. This means that any fixture which is setup and not actively discarded will not be garbage collected and lead to memory bloat. In severe cases this can lead to memory exhaustion.

Existing testcases which contain setUp which either generate data, or set resetAfterTest should be phased out, and no new cases should be introduced.
==Make use of the dataProvider functionality==
The dataProvider functionality of PHPUnit is an extremely powerful and useful feature which allows you to verify a function quickly and easily with a range of different conditions.
However, the following rules should be followed when using dataProviders:
* Keep addition of resettable data requring resetAfterTest to a minimum - this will lead to many slow tests
* Data providers '''must not instantiate/create data'''. Just define it. And then, the test body can proceed with the instantiation/creation. The dataProvider is called after the testSuite is instantiated, but before any tests are run. Each test will run a full setUp and tearDown, which will destroy any data which was created.
<syntaxhighlight lang="php">
/**
* Test function accepts parameters passed from the specified data provider.
*
* @dataProvider foobar_provider
* @param int $foor
* @param int $bar
*/
public function test_foobar(int $foo, int $bar) {
// Perform the tests here.
}

/**
* Data provider for {@see self::test_foobar()}.
*
* @return array List of data sets - (string) data set name => (array) data
*/
public function foobar_provider(): array {
return [
'Same numbers' => [
'foo' => 42,
'bar' => 42,
],
'Different numbers' => [
'foo' => 21,
'bar' => 84,
],
];
}
</syntaxhighlight>
=Extra test settings=
Usually the test should not interact with any external systems and it should work the same on all systems. But sometimes you need to specify some option for connection to external systems or system configuration. It is intentionally not possible to use $CFG settings from config.php.

There are several ways how to inject your custom settings:
* define test setting constants in your phpunit.xml file
* define test setting constants in your config.php
These constants may be then used in your test or plugin code.
=Upgrading unit tests to work with Moodle 3.11 and up (PHPUnit 9.5)=
{{Moodle 3.11}}

With Moodle 3.11, '''PHPUnit was upgraded to 9.5''' (from 8.5 being used in previous versions). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.11 (7.3, 7.4 and [[Moodle and PHP|8.0]]) (see MDL-71036 and linked issues for more details).

While a lot of existing tests will work without modification with PHPUnit 9.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 9.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2020/02/migrating-to-phpunit-9 A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-9.html PHPUnit 9 release Announcement].
* These multiple detailed changelogs (because all them have included modifications requiring changes): [https://github.com/sebastianbergmann/phpunit/blob/9.0.0/ChangeLog-9.0.md 9.0], [https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md 9.1], [https://github.com/sebastianbergmann/phpunit/blob/9.3.0/ChangeLog-9.3.md 9.3], [https://github.com/sebastianbergmann/phpunit/blob/9.5.0/ChangeLog-9.5.md 9.5]
* [https://phpunit.readthedocs.io/en/9.5/ Official PHPUnit manual].
A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/e3a46964dc6d8ca1558c6e1e8dfdf3c1745eeaed/lib/upgrade.txt#L5-L65 lib/upgrade.txt] file. With main points being:
* All the changes that were deprecated with PHPUnit 8.5 (see the section below) are now removed and will lead to errors.
* <tt>assertContains()</tt> now performs stricter comparison (like <tt>assertSame()</tt> does). New <tt>assertContainsEquals()</tt> has been created to provide the old behavior.
* Changes to the <tt>phpunit.xml</tt> schema, mostly internal. These only will impact if you are using custom <tt>phpunit.xml</tt> files:
** The previous <tt><filter></tt> section is now (better) called <tt><coverage></tt>. And, within it:
*** <tt><whitelist></tt> has been replaced by <tt><include></tt>.
*** <tt><exclude></tt> is not a child of <tt><whitelist></tt> anymore, but of <tt><coverage></tt>.
** But with implications when defining the [[#Check your coverage|coverage information]] because <tt>$whitelistxxx</tt> properties used by the <tt>coverage.php</tt> files have been deprecated, instead use <tt>includelistfolders</tt> and <tt>includelistfiles</tt> (to better map the elements in the xml).
* Warning: It's not possible to run individual test files any more. Use any of the alternative execution methods (filter, suite, config) to specify which tests you want to run. This will be hopefully fixed in MDL-71049 once it has been agreed which the best way to proceed is.
* Deprecations, deprecations, deprecations. Lots of them in often used assertions: file assertions, regexp assertions, exception expectations... again, note that all them will become errors with the next PHPUnit update, so '''the recommendation is to update them ASAP'''.
Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/fc335f5...713722c browse the changes associated with the issue], hopefully with useful explanations in the commit messages.
=Upgrading unit tests to work with Moodle 3.10 and up (PHPUnit 8.5)=
{{Moodle 3.10}}

With Moodle 3.10, '''PHPUnit was upgraded to 8.5''' (from 7.5 being used in older version). This was done to '''better align''' the testing environment with PHP versions supported by Moodle 3.10 (7.2, 7.3 and 7.4) and also to provide an '''easier jump to PHPUnit 9.x''' that will be needed for Moodle 3.11 (php versions 7.3, 7.4 and 8.0), removing a lot of deprecated stuff in advance. (see MDL-67673 and MDL-64600 for more details).

While 99% of existing tests will work without modification with PHPUnit 8.5, you will get a '''good number of deprecation warnings''' ("W" in the tests output) that '''should be replaced by their new counterparts as soon as possible''', because all those warnings will become errors with next PHPUnit upgrade.

To find more information about the changes coming with PHPUnit 8.5, it's recommended to read the following resources:
* [https://thephp.cc/news/2019/02/help-my-tests-stopped-working A good article] explaining all the main changes in the release.
* [https://phpunit.de/announcements/phpunit-8.html PHPUnit 8 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/130104cf796a88dd1547dc5beb8bd555c2deb55e/ChangeLog-8.0.md Detailed changelog of the release].
* [https://phpunit.readthedocs.io/en/8.5/ Official PHPUnit manual].
* A good summary of all the '''changes and replacements to perform''' is available in the [https://github.com/moodle/moodle/blob/6594c54b2eef62499d304bfa0939999e3a14246e/lib/upgrade.txt#L5-L37 lib/upgrade.txt] file. With main points being:
** Support for PHP 7.0 dropped (because all template methods (<tt>setUp()</tt>, <tt>tearDown()</tt>..) now require to return void. This will mostly impact 3rd-part plugins that were still running the same tests against old branches of Moodle with PHP 7.0 support.
** <tt>PHPUnit/DBUnit</tt> has been removed are replaced by a lightweight alternative.
** Deprecations, deprecations, deprecations. Lots of them in often used assertions (<tt>assertContains()</tt>, <tt>assertEquals()</tt>...) and also <tt>@expectedExceptionXXX</tt> annotations. Again, note that all them will become errors with PHPUnit 9.
* Finally, it's also a good idea to [https://github.com/moodle/moodle/compare/5903054...b13ec3c browse the changes associated with the issue], hopefully with useful enough explanations in the commit messages.
=Upgrading unit tests to work with Moodle 3.7 and up (PHPUnit 7.5)=
{{Moodle 3.7}}

With Moodle 3.7, '''PHPUnit was upgraded to 7.5''' (from 6.x being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.7 (7.1, 7.2 and 7.3). (see MDL-65204 and linked issues for more details). While internally [https://phpunit.de/announcements/phpunit-7.html a lot of things changed with PHPUnit 7] (PHP 7.1-isms, typed signatures, void returns, assertEquals() changes), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

To find more information about the changes coming with PHPUnit 7, it's recommended to read the following resources:
* [https://phpunit.de/announcements/phpunit-7.html PHPUnit 7 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/520723129e2b3fc1dc4c0953e43c9d40e1ecb352/ChangeLog-7.5.md Detailed changelog of the release], paying special attention to the added, deprecated, changed and deleted sections.
* [https://phpunit.readthedocs.io/en/7.5/ Official PHPUnit manual].
* Changes performed into core, mainly: new, stricter, signatures ([https://github.com/moodle/moodle/commit/26218b7 26218b7]) and assertEquals() changes, specially important when comparing strings, now performed using strict (===) equals ([https://github.com/moodle/moodle/commit/85f47ba 85f47ba]).
=Upgrading unit tests to work with Moodle 3.4 and up (PHPUnit 6)=
{{Moodle 3.4}}

With Moodle 3.4, '''PHPUnit was upgraded to 6.4''' (from 5.5 being used in older version). This was done to better align the testing environment with PHP versions supported by Moodle 3.4 (7.0, 7.1 and 7.2). (see MDL-60611 and linked issues for more details). While internally [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues a lot of things changed with PHPUnit 6] (namespaced classes being the more noticeable), thanks to our '''wrapping layer''' (basic and advanced testcases...) impact expected into old existing unit tests is expected to be reduced and upgrades, easy to achieve.

Still, in '''some cases, it will impossible to maintain compatibility''' of tests between old (pre 3.4) tests and new ones, especially '''when direct use of any phpunit class is performed'''. Luckily, both GitHub Actions and CI tests will detect this situation and it shouldn't be hard to keep all supported branches in core passing ok. Plugins may be trickier, if the same branch is attempting to work against multiple core branches and they are using some phpunit class directly.

To find more information about the changes coming with PHPUnit 6, it's recommended to read the following resources:
* [https://thephp.cc/news/2017/02/migrating-to-phpunit-6 A very good mini-guide] showing all the important changes.
* [https://github.com/sebastianbergmann/phpunit/wiki/Release-Announcement-for-PHPUnit-6.0.0#backwards-compatibility-issues PHPUnit 6 release Announcement].
* [https://github.com/sebastianbergmann/phpunit/blob/9d0c024d2099531442d862b66b0ad7cf35ed8e78/ChangeLog-6.0.md Detailed changelog of the release], paying special attention to the changed and deleted sections.
* Changes performed into core, mainly: namespace class renaming ([https://github.com/moodle/moodle/commit/801a372dadb6e11c8781547603e3f0a59ce5638f 801a372]) and deprecated stuff ([https://github.com/moodle/moodle/commit/796e48a58bf18533bdca423fff7949ab119101c4 796e48a])
=See also=
* [[PHPUnit integration]]
* [[PHPUnit]]
[[Category:Unit testing]]

Process

2023-03-24T11:02:54Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:Migrated|newDocId=/general/development/process}}
This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.
==Integration workflow in the tracker==
The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:
===Users===
Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.
===Developers===
Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].
===CiBoT===
CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.
===Component leads===
[https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components. Note that, apart from that, every component also has some [[Component Leads|HQ Component leads]] that will specifically work on associated issues, triaging, monitoring, reviewing, fixing them.

===Component leads reviewers===
Component Lead Reviewers are Component Leads who have the added responsibility of performing a second and final review of a selection of issues within their component.
After reviewing the code, it is sent to the integration team to be pulled without further review.

===Integrators===
From Monday to Thursday, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===
During each week the testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions in the web version and the Moodle mobile app.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===
On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.
==Stable maintenance cycles==
Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===
After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.
See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===
[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).

===Scrum===
At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted to the standard integration workflow process described above.

==Major release cycles==
Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.
===Define roadmap===
The roadmap is prioritised based on user research, stakeholder inputs, community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.
===Planning and development===
The product teams together with UX, employed at Moodle HQ, work on specifications of major new features throughout the cycle, specifying projects ahead of development time.

The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints, where designs and implementation are iterated as required, and goes through the standard weekly integration workflow described above.
===Testing===
During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and volunteer testers from the Moodle community perform manual QA testing of Moodle features. The current set of functional tests is listed in MDLQA-1. The list of tests is extended as new features are added, though we're also trying to reduce the number as more automated [[Acceptance_testing|acceptance tests]] are developed.

There is also a set of tests for manually testing any major theme changes - MDLQA-11592.

For more details, see [[Testing]].
===Sprints===
At Moodle HQ, development takes place in sprints. The sprints are two or three-week periods during which developers to focus on a fixed list of issues. For example, sprints can be arranged within each release cycle as shown in the diagram below.
===Events during cycle===
During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]
; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.
==New feature development==
Major new features in Moodle usually should go through the following process.
===Specification===
The User Experience (UX) team members create detailed wireframes and features and goals for the new feature, based on iterative user research, design sprints, user testing and co-design as part of the product team.

For bigger features there should be a clear overall vision for the outcomes that are to achieved. During implementation design may continue to iterate based on new findings.

Developers create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.
===Community consultation===
Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.
===Develop the code using Git===
Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

Coverage with automated tests ([[PHPUnit]] or [[Behat|Behat_integration]]) is mandatory for new features.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].
===Submit your code for peer review===
Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions (read the [[Testing instructions guide|instructions guide]]) for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.
===Peer review===
The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===
The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. In some cases the Component Lead may perform a Component Lead Review instead of the integration team. See [[Integration Review]] and the information about the integration workflow above.

==Fixing a bug==
Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)
===Make sure there is a tracker issue===
Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].
===Decide which branches the fix is required on===
Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.
===Develop your change using git===
Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like MDL-12345-31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

Consider setting up [https://moodledev.io/general/development/tools/gha GitHub Actions integration] with your repository so tests will be automatically run for you whenever you push work on your fix.

===Submit your code for peer review===
Once your fix is done, it should be submitted for a peer review.

The following information is necessary for this:
* Information about your public git repository
** repository URL
** branch name(s)
** diff URL
* [[Testing instructions guide|Testing instructions]] for how to verify your fix is correct.
If you have never contributed to Moodle and don't see a button "Request peer review", just comment on the issue with the above information. The component lead or another user with sufficient privileges will then send the issue up for peer review for you.

After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.

If you've set up [https://moodledev.io/general/development/tools/gha GitHub Actions integration], the issue will automatically show the GitHub Actions build status for the branch(es) you've submitted for peer review.

===Peer review===
The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].
===Submit your code for integration===
It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release. For details see [[Integration Review]].
==Security issues==
Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].
* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.
Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.
====How to remove a branch from Github====
To remove a branch from Github, you can use the following command.
git push github :remote_branch
Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.
==Policy issues==
Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.
Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.
==See also==
* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]
Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU and https://youtu.be/Hu8ne0NCRAg?t=11659
[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Integration Review

2023-03-24T11:02:06Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:Migrated|newDocId=/general/development/process/integration}}
==Purpose==

The purpose of the integration review is to:
* Ensure consistent quality across the codebase
* Ensure that pedagogical aims of Moodle are at the forefront of any change
* Take into consideration the holistic view of moodle, looking at the impact beyond where the original developer was focused
* Provide guidance and feedback to developers, helping them learn and improve
* Consider '''other perspectives''' of other users perhaps not considered by original developers e.g.
** Teachers
** Students
** Administrators
** The Moodle mobile app
**Third-party developers

== Integration Principles ==

Integration (non-technical but philosophical) principles (4-5 words determining if something has to be integrated/backported or no):

# safety: if something does not look safe, stable, it won't land. Be conservative.
# security: all security issues, if not breaking principle (1) will be integrated/backported to all security-supported versions.
# community: Anything not useful for the community (or against it) won't be integrated/backported. We can measure the community as 10%HQ, 10%Partners, 10%Core developers, 20%Admins, 20%Teachers, 30%Students - not exact science, just one approximation, you know). Question yourself how the change will affect those groups and ensure positives are bigger always (only affected groups count). All community issues, if not breaking principles (1) and (2) will be integrated.
# typology: bug fixes will be always integrated/backported to all the supported braches if none of the principles (1), (2) and (3) are violated. Also, partially-unsupported branches can receive some if they are important enough. Improvements and new features go, exclusively, to master only, that's the main reason for short release periods. We *must* not make exceptions to this.
# priority: issues will be "ordered down" by priority down (where priority is a [https://tracker.moodle.org/issues/?filter=14000 mix of various factors], dynamic). And will be integrated in that order. If something has to be delayed, better if it is low priority. Once again, nothing here can break any of the previous principles.
# tests: unit tests and acceptance tests will backported as much as possible without breaking (1) and (2). New features required to implement tests will be backported if the API is 100% backwards compatible.
If all the principles are fulfilled, the answer for "should I integrate this?" is, "yes, please!"
(apart from technical findings, of course, that can lead to the issue being not integrated/reopened at last, these principles are 100% philosophical)

==Component Lead Review Process==

Please see the [[Component_Lead_Review|Component Lead Review documentation]] for further information on the CLR process.

==Integration Review Process==

# Run automated pre-checks against the continuous integration server. (In future this can be automated and also moved into a publicly accessible domain.)
# Final code review, much like the peer review, except that this is the final check. To include
## Takes place in-situ (integrated) to examine the impact to other integrated issues
## Checking against the coding guidelines - syntax/whitespace
## Moodleisms - using the built-in API functions where appropriate
## Cross-DB compatibility
## Security
# Check purpose - the patch needs to fix the issue reported.
# Verify target branches are appropriated. They must match 100% the rules defined for [[#Backporting|backporting issues]].
# Ensure backwards compatibility is maintained. As a starting point backwards compatibility must always be maintained. Where backwards compatibility is affected it should be:
## Well discussed with evidence of justification
## Documented and communicated to the community
# Ensure backwards compatibility with the Moodle mobile app. Especially in areas where the Moodle app uses pre-rendered content from the site (like Quiz or Lesson)
# Verify that components are correct and check the right people have been involved (e.g. component maintainers)
# For fundamental changes, check that a thread has been started in an appropriate forum, and other Moodlers, given enough time to comment.
# Tests - must be written to guide tester to verify the fix is working.
## Unit test - very much preferred if applicable
## at end of Wednesday, ensure testing is going to complete as expected. else take other actions (speak to test manager)
# Performance - we have to look at maintaining optimum code here, as far as simple patches that can affect performance. (simple optimisations)
# Scalability - if master only - we're looking far future, stable branches may not be lucky to get such improvements.
# git authorship is correct vs committer + credits due are mentioned + email addresses
# Documentation / PHP Doc / readability
# [[Tracker issue labels]] which might need adding. Particularly:
## docs_required / dev_docs_required / release_notes: About which type of documentation is required for the issue.
## ui_change / api_change: About the implications of the change.
## unit_test_required / acceptance_test_required / qa_test_required: About the need to cover the issue with some test.
## affects_mobileapp / affects_workplace / affects_moodlecloud: About issues that may affect other Moodle products and services
# [[Tracker issue versions]] review. Particularly:
## Fixed Version after integration - is the versions that the issue is patched for. (A rule here: [[Tracker issue versions#Some general and simple rules|"or stables or master"]]).
## Remove any "Must fix for X.Y" version once the issue is integrated.
# Whenever any of the points above or any other detail require extra information or action to be done by the assignee, and the integrator considers that they can be fixed without needing to discard/reopen, the issue will be sent to "Waiting for feedback" with all the details to complete. Once everything has been fulfilled, always within a reasonable amount of time (still to decide), the issue will be sent back to integration by the assignee.
# Assign the tester.
## Don't forget to update the weight in the testers sheet

==Schedule==
===In normal periods ===
The integrators adhere to the following schedule: (links here should convert the times into your local timezone)

All the flow of issues to current integration is automatically controlled by the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job that keeps the current queue fed with issues, moves important ones and priotitises long awaiting issues. Issues are picked in strict integration order.

* Monday to Thursday until [http://time.unitarium.com/utc/4 12:00 (UTC+8)]: Integration and [[Testing of integrated issues#The testing process|Testing]] happen. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction.
* Thursday after 12:00 (UTC+8): Integrators duties during this time are to monitor, facilitate and 'problem solve' the testing process.
* Friday: Testing should be completed before (the sooner the better) 12:00 (UTC+8) at which time remaining testing failures will be reverted/rewritten and reopened. The release process follows.
* Friday after 12:00 (UTC+8):: Should be kept free from integration. Integration systems are maintained during this time.

Note that under the strict schedule above, it is specially important '''to be as responsive as possible''', both when the issue is being integrated and when [[Testing_of_integrated_issues#Expectation_from_tester|testing]]. Any significant delay by any of the actors involved will result in the issue being moved out from current integration.

=== During continuous integration/Freeze/QA period ===
During the continuous integration period (last 6 weeks before release) the integration team are continuously focused on producing regular builds of master to facilitate QA and fast fixes to issues identified.

* Throughout:
** Issues are picked on a one by one basis, prioritising [https://docs.moodle.org/dev/QA_testing#Resetting_tests QA blockers] and master regressions (MUST FIX) issues.
** After freeze (usually 5 weeks before release) any non bug fix issues are given the ''integration_held'' label and are explicitly not picked for integration. Still, anybody is able to add a reasoned ''unhold_requested'' label to those issues in order to get them unblocked by the development managers. Note this does not guarantee the issue to land before release, but just gives it a chance to be integrated like any other issue.
** Also, coming together with freeze, all the flow of issues to current integration is automatically controlled by the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job that keeps the current queue fed with issues, moves important ones, holds new features and other niceties. Issues are picked in strict integration order.
** Our goal is to achieve 'releaseability' throughout, so we stop integrating to ensure a release happens

So, basically, once under continuous integration, we do organize work as follows:
* Continuous officially begins. Everybody is on integration. Until end of on-sync period.
* Monday: Integration and [[Testing of integrated issues#Differences in test process during continuous integration periods|testing]] happens.
* Tuesday: Integration happens until [http://time.unitarium.com/utc/4 12:00 (UTC+8)], [[Testing of integrated issues#Differences in test process during continuous integration periods|afterwards we try to achieve 100% 'Test Passed']] and stop integrating any untested changes until a master release is produced.
* Wednesday: [Assuming a master release has been rolled] Integration and testing continues
* Thursday: Integration and testing continues
* Friday: Integration happens until 12:00 (UTC+8), afterwards we try to achieve 100% 'Test Passed' and stop integrating any untested changes until a master release is produced. Note that 24h before the cutoff it's possible to pick issues out of order towards queues reduction.

Note: along this period we always release as many stable weeklies, both supported (always) and security only (when there are changes), as master rolls (on-demand, beta, rc) happen (see MDLSITE-3470). Note that those tags are not simply tags but they come with some important implications, aiming to stability, safety and clarity. Integrators will try to remain loyal to them, be warned:

* Once beta is released... new features or improvements "unrelated" with the release will be really harder to be accepted. A +4 from developer managers (normally +3 is enough) will be needed to proceed with the issue. Integrators vote will be, always, -1.
* Once rc are released... new features or improvements "unrelated" with the release are forbidden. No unhold voting, no managers. Simply forbidden.
* Last week before release, only "related" issues will be picked for integration. Everything else (bug fixes included) are kept out (given the "integration_held" label) if unrelated, at very least until after release. No distractions.
Definition: "related": said to be a followup of required/planned to release OR a direct (and recent) regression caused by a bug fix OR a security issue.

=== On-sync period ===
Immediately after a major release and for a short period (right now, 2 weeks, matching 1st HQ sprint duration), the integration team is under the named on-sync period.

At all effects, it's a normal period (see above), and weeklies are produced for supported stable branches and also for master. But with one important rule/goal:

* We must keep the latest stable branch and master 100% on-sync, specifically about versions and upgrade steps. Some well-known exceptions to this are: ''backup.class.php'', ''config.php'' (''$release'', ''$branch'', ''$maturity'' and comments only, never ''$version'' !), ''install/lang/xx'' files (the new stable branch for install lang files is created 2w after the release).

This simple, but important constraint, is there to facilitate the integration of impeding bugs, needing urgent resolution, and by keeping them the same, we guarantee that any stable or master fix will apply without problems to both branches. Of course, in order to achieve the rule, these must be also observed along the period:

* We continuously perform diffs between the latest stable and master, controlling that we are on-sync. Any non-authorised difference is cleaned (rewritten). Whenever a latest stable branch is missing in the issue (it's optional over the period), we automatically cherry pick the changes straight from master.
* Both improvements and new features (and, in general, everything leading to divergence) are held until the on-sync period ends.

Last, but not less important, a second goal for this on-sync period is:

* The environmental requirements '''for next major version''' [[Release process#2_weeks_after|must be agreed and resolved so they can land to master]] early in the process, remaining defined and stable over the next, 6 months of, development cycle.

As part of the standard [https://docs.moodle.org/dev/Release_process Moodle release process], at the beginning of the on-sync period, we "unhold" all bugs that were held during the last week before the release because they were unrelated to the release. At the end of the onsync period we "unhold" all new features that were submitted after the code freeze for the the release.

== Backporting ==

Whilst we'd all like all Moodle users to be using our latest and greatest code, there is a balance to strike between improving our software and maintaining stability (both in terms of regressions, but also training and documentation materials). Large amounts of change on the stable branches make the lives difficult for institutions to manage upgrades between point releases.

==== General policy ====
Our general policy is as follows:

* Bug fixes will be backported to all (and only to) supported stable branches.
** When fixing a bug, please provide a fix for all supported stable branches.
** If a fix doesn't make sense to be backported to every branch, please make it clear in the issue.
* Improvements or new features will only land in master.

==== Process for requesting a non bug-fix backport ====
Improvements or new features can be requested to be backported to the stable branches. We urge developers to consider this request carefully. In recent years, Moodle has moved to a short and predicatable time based release schedule and we use a very effective distributed source control system. Both of these process changes should ensure that a change not being backported to the stable branches is not as problematic as it may have used to be.

Should you feel that a new feature or improvement needs backporting, please follow this process:

# File a new issue.
# Set the issue title using our backport template guide. (i.e. "Fix forum alignment (backport of MDL-99999)") - see [https://docs.moodle.org/dev/Tracker_guide#Tracker_fields Tracker_guide]
# Link the original issue using link type "Will help resolve".
# You should include clear rationale for the request to backport

The integration team will process backport requests, with the following guidelines:
# The integration team will together consider each request individually considering the needs of the community (influenced by forum posts, moodle partners, nagging developers etc).
# Backports will happen not earlier than 3 weeks and not later than 2 months after the request was performed.
# Rationale will be given for rejection

If the backport request is approved, please follow the usual development process to submit the feature or improvement on earlier branches. Just to be clear, this means using the new bug number. So, even if the fix you are back-porting cherry-picks cleanly, you will need to amend the commit comment to use the new MDL-XXXXX number. It would be good practice to also add a line like "This is a backport of MDL-YYYYY." in the amended commit comment. You can probably copy the testing instructions from the original issue. If so, make it clear you done this by saying something like "Copied from MDL-66327:". Of course, if you can improve the instructions, feel free to edit. MDL-66614 and MDL-66327 are probably a reasonably good example fo what should be done.

==== Polite note about bug classification ====
Many issues can be appropiately classified as borderline bugfix/improvements. We politely request that developers do not try and 'game the system' by clasifying their improvements as bugs intentionally. If your fix is in a grey area, please state your case for it being a bug fix clearly. The integration team will use their discretion where necessary.

==== Backport fixes to unsupported branches ====
* Given the [[#General policy|general policy]] above, only supported stable branches are candidates normally.
* Also security, privacy, dataloss and regressions caused by any of the previous issue types are accepted to be fixed into security-only supported branches. Note this doesn't include [[Tracker issue labels|"security_benefit" labelled issues]].
* Apart from the previous, issues required to keep the testing infrastructure working and passing (gha, behat, phpunit, random failures, new steps availability...) will also be accepted when possible into security-only branches.
* Finally, backport to unsupported branches only will happen when the issue is a '''direct regression caused by a bug fix''' introduced by the very latest releases. This applies to both security-only and out-of-support branches.

A new weekly release will be performed including all the cases above, but [[Process#Security issues|security issues that follow its own special process]] and are released bi-monthly.

== Fixing issues identified during integration review/ testing ==

When a branch has been merged by an integrator, it is important that you do not modify the existing history of your branch (e.g. by amending or squashing your commits) and instead add new commits on top. If you modify the history of your branch, it makes it extremely difficult for the integrator to merge your changes (and see the differences).

As a general rule, this means that if your issue has entered the 'in integration review' stage of the development process, please only add new commits on top of your existing commits. There are circumstances when your issue will be 'in integration review' but not merged (and thus possible to squash changes) but if in any doubt, please add new commits and ask the integrator to squash your changes for you.

== Commit squashing ==

The Integration team will sometimes recommend squashing commits when things do not look natural (and may offer to do this for you), especially when there are "fix-commits" in the history happening before integration. But [https://moodle.org/local/chatlogs/index.php?conversationid=13987#c489485 our policy] is "if you want your history of commits to look like bad, it's your history". You will not be forced to squash your changes. You should pay close attention to https://docs.moodle.org/dev/Coding_style#Git_commits and intend to "Tell a perfect, cleaned up version of the history. As if the code was written perfectly first time.".

[[Category: Processes]]

Behat integration

2023-03-24T11:01:08Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:Migrated|newDocId=/general/development/tools/behat/}}
== Introduction ==
This page describes the internals of Behat and the integration with Moodle. For the functional description, how to install it, run the suite and add more features, see [[Acceptance_testing]].

Behat is a framework for behavior driven development (BDD) which allows us to specify Moodle functionalities (aka features) as a human-readable list of steps. It parses these steps to executable actions to simulate user interaction against headless browsers (without java script support, only curl-kind requests) or user simulation tools like Selenium, which interacts with browsers and allows JavaScript events simulation.
== Objective ==
The aim of this integration is to allow Moodle components to have its own set of features and step definitions. This allows us to periodically execute sets of tests to detect regressions and Moodle features in different environments (browsers, DBs engines, web servers...). The Moodle QA tests will be progressively rewritten according to this format to run automatically.
== How Behat works ==
This section aims to explain the basics about BDD and Behat and a quick view of how Behat internally works from the CLI command execution to the results output.

'''Note that all those examples are not necessarily real nor part of the suite, they are meant to help understand the concepts, see [[Acceptance_testing]] for real examples'''

Some terms used:
* '''Features''': Human-readable list of scenarios that describes a feature
@auth
'''Feature''': Login
In order to login
As a moodle user
I need to be able to validate the username and password against moodle

'''Scenario''': Login as an existing user
Given I am on "login/index.php"
When I fill in "username" with "admin"
And I fill in "password" with "admin"
And I press "loginbtn"
Then I should see "Moodle 101: Course Name"

'''Scenario''': Login as an non-existing user
Given I am on "login/index.php"
When I fill in "username" with "admin"
And I fill in "password" with "admin"
And I press "loginbtn"
Then I should see "Invalid login"
* '''Scenario''': Human-readable list of steps to describe an expected behaviour
'''Scenario''': Login as an existing user
Given I am on "login/index.php"
When I fill in "username" with "admin"
And I fill in "password" with "admin"
And I press "loginbtn"
Then I should see "Moodle 101: Course Name"
* '''Steps''': Human-readable sentences that describes an action. There are 3 types of steps, "Given" describing the initial context, "When" the event that provokes a change and "Then" where the outcomes should be asserted.
I click on the "Add user" button
* '''Steps definitions''': PHP methods referenced by steps when matching it's regular expression. The @Given, @When and @Then tags are descriptive and they are not taken into account when matching steps with steps definitions. The regular expressions placeholders are returned to the PHP method as arguments so methods can use them to tell the browser which button (for example) they want to click.
/**
* @When /^I click on the "(.*)" button$/
*/
public function i_click_on_the_button($button) {
// Simulates the user interaction (see Mink description below for more info)
$this->getSession()->getPage()->pressButton($button);
}

* '''Behat''': PHP framework and CLI application that wraps the whole process of features files loading + features files parsing + execution of actions in the browser + results output (http://behat.org/)
* '''Gherkin''': Human-readable language used to define features that can be parsed and translated into PHP methods. For more info, it's the same language used by Cucumber, the BDD Ruby framework (https://github.com/cucumber/cucumber/wiki/Gherkin)
* '''Context''': In Behat scope a context is a PHP class that groups steps definitions (as methods)
* '''Mink''': Is the component which interacts with browsers, simulating a real user interaction. It allows us to write PHP code (or use the available PHP methods) to send requests to the different browsers APIs through a common interface or extend it to allow browser-specific actions. The supported browsers includes Selenium, Selenium2, Sahi... http://mink.behat.org/
* '''Selenium 2''': Web browser automation tool, applications like Mink can communicate with it through a RESTful API (http://code.google.com/p/selenium/wiki/JsonWireProtocol) to execute actions simulating user interaction.
* '''Selector type''': Related with '''locator''', is a way to select a node inside the page DOM, more info in https://docs.moodle.org/dev/Acceptance_testing#Providing_values_to_steps
* '''Locator''': Is what we are looking for inside the page DOM, it completely depends on the associated selector type, a few examples of it:
** Selector type = "link", Locator = "Link text"
** Selector type = "field", Locator = "Field legend text"
** Selector type = "css", Locator = ".css-class #id"
** Selector type = "xpath", Locator = "//input[@id='id-value']"
All this components are written in PHP, open sourced and packaged in a single and extensible framework.
=== Quick view of the whole process ===
# Behat CLI execution
#* Behat application initialization and loading of arguments (features files to execute, output format...)
#* Reads the Behat config file (browser servers are specified here)
#* Extensions overrides management
#* Gherkin initialization
# Features files selection
#* According to the arguments Gherkin looks for .features files
#** It can use different features loaders (single file, a directory, the default directory...)
#** The framework can be extended to allow multiple folders loading
# Features parsing (Gherkin)
#* Loops through the loaded features files looking for scenarios
#* Gets the list of steps of each scenario
#* There are hooks at different levels (https://docs.behat.org/en/latest/user_guide/context/hooks.html)
# Steps parsing (Gherkin)
#* Gherkin looks in the available steps definitions for a regular expression that matches the step text
# Step definition execution
#* The step definition code is executed
#* Steps definitions most of the time uses the Mink component to communicate with the browser API sending requests like "click on that button" or "go to XXX page"
# Scenario outcomes
#* The scenario counts as failed if an exception is thrown when executing a step definition (for example trying to click a non-existing button)
#* The scenario counts as passed if no exception is thrown during it's steps execution
# Finishing CLI execution
#* A summary with all the scenario results is displayed
#* It accepts different output formats (like JUnitXML) to it's execution in continuous integration systems (http://docs.behat.org/guides/6.cli.html#format-options)
== Moodle integration ==
It follows the approach chosen with PHPUnit:
* It comes disabled by default, Behat is not included within Moodle and it has to be installed separately with the composer installer
* Moodle components (subsystems and plugins) can have a tests/behat/ folder
* The scenarios are executed in a test environment, the production database and dataroot are not affected by the tests modifications
* The scenarios specifies their own fixtures and it's execution is isolated from other scenarios and features, resetting the test database and the test dataroot before each scenario
* Moodle lists the features files and steps definitions of it's components in a behat.yml file, similar to the phpunit.xml manifest
* A basic behat.yml.dist config file has been included
=== Alternative environment ===
Acceptance testing implies interaction with the browser like real users does, so it requires the site to be accessible via URL. The Moodle integration creates a new moodle site installation in parallel to the production one to run the tests in a sandbox without affecting the production environment, switching the regular $CFG->wwwroot, $CFG->dataroot and $CFG->prefix to alternatives, which should be only accessible from localhost or internal networks. Info about how to run the tests in https://docs.moodle.org/dev/Acceptance_testing#Running_tests.

This default configuration is useful when developing in a local host, but to run the tests automatically with Jenkins, GHA, other CI systems or with saucelabs we provide a few extra settings. More info in https://docs.moodle.org/dev/Acceptance_testing#Advanced_usage

All the behat CLI utilities we provide within the Moodle codebase (admin/tool/behat/cli/*) are using $CFG->behat_wwwroot, $CFG->behat_prefix and $CFG->behat_dataroot instead of $CFG->wwwroot, $CFG->prefix and $CFG->dataroot, this scripts are self-contained, but as we are accessing through a browser, we also need to switch the whole Moodle instance to test mode. For this there are two requirements:
* Test mode is enabled if
** '''php admin/tool/behat/cli/init.php''' or '''php admin/tool/behat/cli/util.php --enable''' has been executed
* Test mode is requested if
** The vendor/bin/behat command is running, we know it because we hook the Behat process before the tests begins to run and we require moodle config.php after it
** We set $CFG->behat_wwwroot in config.php and we are accessing the moodle instance through it
The unique $CFG->behat_wwwroot prevents unintended execution of acceptance tests on production sites.

=== Javascript ===
There are two types of tests depending on if their scenario needs a real browser capable of execute Javascript or if they can run in a headless browser.
* Tests with Javascript requires interaction with a browser through a user simulation tool like Selenium or ZombieJS to be executed; see http://mink.behat.org/#different-browsers-drivers for all available drivers
* Test that does not requires Javascript are faster to run but can not test rich applications like Moodle
In most of the cases a Javascript test would be more appropriate because most of the users uses Javascript-capable browsers, non-Javascript tests can be useful to ensure that Moodle maintains its functionality without Javascript enabled and to ensure there are no big issues, regressions or exceptions in general.
=== Admin tool "Acceptance testing" ===
There is an admin tool to run and ease the creation of acceptance tests.
* Web interface: The web interface allows you to list and filter the available steps definitions, a non-technical user can use this interface to write new features (admin/tool/behat/index.php)
* CLI: Command to enable and disable the test environment and to update the behat.yml file with the system tests and steps definitions (admin/tool/behat/cli/util.php and admin/tool/behat/cli/init.php for a quick start)
[[File:Acceptance_testing_UI_2.5.png]]
=== Available steps to create tests ===
There are behat libraries with tons of steps definitions to run all sort of processes and interactions with the browser, some of them overlaps Moodle-specific libraries and tests writers can be confused not only by this also by the amount of steps and vague or too technical steps descriptions. Moodle provides a set of steps definitions written in a common format to make tests writers life easier. New steps definitions must follow this guidelines: https://docs.moodle.org/dev/Acceptance_testing#Adding_steps_definitions
=== Behat extension ===
A new Behat extension (https://github.com/moodlehq/moodle-behat-extension) has been created to maintain Behat and its dependencies as they comes from upstream.

The aim of this extension is:
* Load features from multiple folders (Moodle subsystems and plugins)
* Load steps definitions from multiple folders and add them as subcontexts (Moodle subsystems and plugins)
* Return the available steps definitions in a more human-readable format without regexps
* Look for exceptions, debugging() calls, PHP error messages and other backtraces in Moodle's output
* Extend the Selenium2 behat driver to allow extra Selenium capabilities
* Add a new formatter method based on progress (the moodle default one) to display info about the moodle site being tested
All the other particularities of this integration can managed playing with different Behat config parameters.
[[Category:Behat]]
[[es:Behat]]

Git for developers

2023-03-24T10:59:34Z

Stronk7: Part of MDLSITE-7135 - document the removal

This document is for helping you get started on Moodle development with Git. For further details of Git, see [[:Category:Git]].

== General workflow ==

'''A reasonable knowledge of the Git basics is a good idea before you start to use it for development. If you are new to Git, you are encouraged to go to 'See also' for some more general reading.'''

[[image:git-pushpull-model.png|right|thumb|400px|Moodle development workflow with Git]]
Detailed explanation of the workflow can be found in the [[Process]] page. In short, the Moodle development with Git looks like this:

* You as the contributor commit changes into your personal repository at your computer
* You push the changes into your public repository and publish links to your changes in the Moodle Tracker
* You request a peer review of your code from another developer
* When peer reviewer is happy they submit issue for integration
* Moodle integrators pull the changes from your public repository and if they like them, they put them into Moodle integration repository
* The integrated change is tested and finally pushed into Moodle production repository
* You update your local repository with all changes from the production repository and the next cycle may start again

This workflow runs in roughly weekly cycles. The integration happens on Monday and Tuesday and the testing on Wednesday. On Thursday (or Friday if testing takes too long), the production repository moodle.git is usually updated with changes from the last development week.

Most Moodle developers have their public repositories hosted at [http://github.com/ Github]. Alternatively you may want to try [http://gitorious.org Gitorious] or the legendary [http://repo.or.cz repo.or.cz]. In the examples in this guide we assume you'll set up your public repository at Github.

When you first register on tracker you can not assign issues to yourself or send them for peer review. You will be added to the developers group after your first bug fix is integrated. Before that just comment on the issue with a link to your branch and component lead or another developer will send issue for peer review for you.

== Installing Git on your computer ==

Install Git on your computer. Most Linux distributions have Git available as a package to install. On Debian/Ubuntu, type ''''sudo apt-get install git'''' on the terminal. If you are on Mac, [http://code.google.com/p/git-osx-installer/ git-osx-installer] installs it in a few clicks.

Immediately after the installation, set your name and contact e-mail. The name and e-mail will become part of your commits and they can't be changed later once your commits are accepted into the Moodle code. Therefore we ask contributors to use their real names written in capital letters, eg "John Smith" and not "john smith" or even "john5677".

git config --global user.name "Your Name"
git config --global user.email yourmail@domain.tld

Unless you are the repository maintainer, it is wise to set your Git to not push changes in file permissions:

git config --global core.filemode false

Also, it's recommended to verify that the your git installation is not performing any transformation between LFs and CRLFs. All Moodle '''uses only LFs''' and you should '''fetch/edit and push''' it that way (may need to configure your editor/IDE too). Note that having any "magic" enabled is known to cause [[Common unit test problems#The_test_file_.22evolution.test.22_should_not_contain_section_named_.22.5Blots_of_content.5D.22|problems with unit tests]] execution. So we recommend you to set:

git config --global core.autocrlf false

== Setting-up the public repository ==

1. Go to [http://github.com/ Github] and create an account.

2. Go to the [http://github.com/moodle/moodle official Moodle Github repository] and click on the Fork button. You now have your own Github Moodle repository.

3. Now you need to set up your SSH public key, so you can push to your Github Moodle repository from your local Moodle repository. On Mac you can go on this [http://help.github.com/mac-key-setup/ Github help page]. If you are on another system, go to your Github administration page, to the section SSH Public Keys, and you should see a link to a help page. Done? Good! That was the most difficult part!

4. If you want, you can set up [https://moodledev.io/general/development/tools/gha GitHub Actions integration] with your GitHub repository so that when you push your code, and it will automatically run a suite of tests for you against your changes. This way you can quickly catch issues without having to set up a testing environment locally (and before you share your code with other Moodle developers!).

== Setting-up the local repository at your computer ==

Create a local clone repository of your Github repository. In a terminal:

git clone git://github.com/YOUR_GITHUB_USERNAME/moodle.git LOCALDIR

(or: git clone git@github.com:YOUR_GITHUB_USERNAME/moodle.git LOCALDIR)

This command does several jobs for you. It creates a new folder, initializes an empty Git repository in it, sets your Github repository as the remote repository called 'origin' and makes a local checkout of the branch 'master' from it. The important point to remember now is that your Github repository is aliased as 'origin' for your local clone.

Note that the format of the URL here is important. In the first example, the URL starts "git://github.com" and this will give read-only access to the repository at github.com. If you use this URL, the "git push origin" command that appears later in this document will not work. Therefore, if you want to be able to update the "origin" repository, you should use the URL that starts "git@github.com", i.e. the second of the two "git clone" commands given above. This will give you read and write access to the repository on github.com.

== Keeping your public repository up-to-date ==

[[image:git-sync-github.png|right|thumb|400px|Fetching changes from upstream and pushing them to github]]
Your fork at Github is not updated automatically. To keep it synced with the upstream Moodle repository, you have to fetch the recent changes from the official moodle.git and push them to your public repository. To avoid problems with this it is strongly recommended that you never modify the standard Moodle branches. ''Remember: never commit directly into master and MOODLE_xx_STABLE branches.'' In other words, always create topic branches to work on. In Gitspeak, the master branch and MOODLE_xx_STABLE branches should be always fast-forwardable.

To keep your public repository up-to-date, we will register remote repository git://git.moodle.org/moodle.git under 'upstream' alias. Then we create a script to be run regularly that fetches changes from the upstream repository and pushes them to your public repository. Note that this procedure will not affect your local working directory.

To register the upstream remote:

cd moodle
git remote add upstream git://git.moodle.org/moodle.git

The following commands can be used to keep the standard Moodle branches at your Github repository synced with the upstream repository. You may wish to store them in a script so that you can run it every week after the upstream repository is updated.

#!/bin/bash
git fetch upstream
for BRANCH in MOODLE_{19..39}_STABLE MOODLE_{310..311}_STABLE MOODLE_{400..401}_STABLE master; do
git push origin refs/remotes/upstream/$BRANCH:refs/heads/$BRANCH
done

=== How it works ===

The git-fetch command does not modify your current working dir (your checkout). It just downloads all recent changes from a remote repository and stores them into so called remote-tracking branches. The git-push command takes these remote-tracking branches from upstream and pushes them to Github under the same name. Understanding this fully requires a bit knowledge of Git internals - see gitrevisions(7) man page.

Note there is no need to switch the local branch during this. You can even execute this via cron at your machine. Just note that the upstream repository updates typically just once a week.

=== New branches ===

Occasionally, moodle.org will create a new branch that does not exist in your public (e.g. Github.com) repository. If you try to push this new branch, you will see an error such as the following:

error: unable to push to unqualified destination: MOODLE_99_STABLE
The destination refspec neither matches an existing ref on the remote
nor begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@github.com:YOUR_GITHUB_USERNAME/moodle.git'

In the above example, "MOODLE_99_STABLE", is the name of the new branch that does not exist in your public repository. To fix the error, you need to create the new branch on your public repository, using the following commands, replacing "MOODLE_99_STABLE" with the name of the new branch you wish to create:

git checkout MOODLE_99_STABLE
git push origin MOODLE_99_STABLE:MOODLE_99_STABLE

The above code will create a new copy of the "MOODLE_99_STABLE" branch in your local repository. If you do not need to keep a local copy of the new branch - and probably you do not need it, you then can remove it from your local repository as follows:

git checkout master
git branch -D MOODLE_99_STABLE

== Preparing a patch ==

As said earlier at this page, you never work on standard Moodle branches directly. Every time you are going to edit something, switch to a local branch. Fork the local branch off the standard branch you think it should be merged to. So if you are working on a patch for 1.9 or 2.0, fork the branch off MOODLE_19_STABLE or MOODLE_20_STABLE, respectively. Patches for the next [[Moodle versions|major version]] should be based on the master branch.

git checkout -b MDL-xxxxx-master_brief_name origin/master

Note that if you forget to specify the starting point, the branch is based on the currently checked-out branch. It may not be what you want. It is recommended to always specify the starting point.

To check the current branch, run

git branch

The current branch is highlighted.

Now go and fix the issue with your favorite IDE. Check the status of the files, view the change to be committed and finally commit the change:

vim filename.php
git status
git diff
git commit -a

For the commit message, please do respect the guidelines given on in the article [[Coding style#Git_commits|Coding_style]].

Note that this is safe as the commit is recorded just locally, nothing is sent to any server yet (as it would in CVS). To see history of the commits, use

git log

Once your local branch contains the change (note that it may consists of several patches) and you are happy with it, publish the branch at your public repository:

git push origin MDL-xxxxx-master_brief_name

Now as your branch is published, you can ask Moodle core developers to review it and eventually integrate it into the standard Moodle repository.

=== Changing commit message, reordering and squashing commits ===

It often happens that you made a mistake in your patch or in the commit message and helpful CiBot pointed it out for you. You can "rewrite the history" and change the existing commits.

Option 1. Reset all the changes in the branch and commit again.

git reset --mixed origin/master

Now all your changes are still present but all commits on top of "master" branch are gone. You can create a new commit

Option 2. Discover '''git rebase --interactive''' - this is a powerful tool to change the sequence of commit, change the commit messages, squash commits, etc. We will not cover it here, there are many articles in the Internet about it, for example: https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History.

Whatever option you chose, you have "rewritten the history" and you can not simply push the changes to github again because they would need to overwrite the commits that were already pushed. If you try "git push MDL-xxxxx-master_brief_name" you will get an error message suggesting you to force push.
To force push the changed commits use:

git push -f origin MDL-xxxxx-master_brief_name

If an error occurs because you are still using the git protocol (read only), use this command :

git remote set-url origin https://github.com/<user.name>/moodle.git

A prompt will ask for your credentials, if you previously setup your SSH public key you can also use this one :

git remote set-url origin git@github.com:<user.name>/moodle.git

=== Checking if a branch has already been merged ===

After some time contributing to Moodle you would have a lot of branches both in your local repository and in your public repository. To prune their list and delete those that were accepted by upstream, use the following

git fetch upstream (1)
git branch --merged upstream/master (2)
git branch --merged upstream/MOODLE_20_STABLE (3)

The command (1) fetches the changes from your upstream repository at git.moodle.org (remember that git-fetch does not modify your working dir so it is safe to run it whenever). Command (2) and (3) print all branches that are merged into the upstream master branch and MOODLE_20_STABLE branch, respectively. To delete these local branches, use

git branch -d MDL-xxxxx-master_accepted_branch

The similar approach can be used to check the branches published at your origin repository at github.com

git fetch origin (1)
git fetch upstream
git branch -r --merged upstream/master (2)
git branch -r --merged upstream/MOODLE_20_STABLE (3)

The command (1) makes sure that you have all your branches from github.com recorded as the remote tracking branch locally. Commands (2) and (3) work the same as in the previous example but they list remote tracking branches only ([http://www.kernel.org/pub/software/scm/git/docs/git-branch.html see -r param]). To delete a branch at github.com, use

git push origin :MDL-xxxxx-master_branch_to_delete

This syntax may look weird to you. However it is pretty logical. The general syntax of the git-push command is

git push <repository> <source ref>:<target ref>

so deleting a remote branch can be understood as pushing an "empty (null) reference" to it.

== Peer-reviewing someone else's code ==

To review a branch that someone else pushed into their public repository, you do not need to register a new remote (unless you work with such repository frequently, of course). Let us imagine your friend Alice pushed a work-in-progress branch called 'wip-feature' into her Github repository and asked you to review it. You need to know the read-only address of the repository and the name of the branch.

git fetch git://github.com/alice/moodle.git wip-feature

This will download all required data and will keep the pointer to the tip of the wip-feature branch in a local symbolic reference FETCH_HEAD. To see what's there on that branch, use

git log -p FETCH_HEAD

To see how a particular file looks at Alice's branch

git show FETCH_HEAD:admin/blocks.php

To create a new local branch called 'alice-wip-feature' containing the work by Alice, use

git checkout -b alice-wip-feature FETCH_HEAD

To merge Alice's work into your current branch:

git merge FETCH_HEAD

To see what would be merged into the current branch without actually modifying anything:

git diff ...FETCH_HEAD

Once you are all set and reviewing code, this [[Peer_reviewing_checklist|checklist]] should prove to be useful.

== Rebasing a branch ==

Rebasing is a process when you cut off the branch from its current start point and transplant it to another point. Let us assume the following history exists:

A---B---C topic
/
D---E---F---G master

From this point, the result of the command:

git rebase master topic

would be:

A'--B'--C' topic
/
D---E---F---G master

and would end with 'topic' being your current branch.

You may be asked to rebase your branch submitted for the integration if the submitted branch was based on an outdated commit. The typical case is if you create a new branch as a fork off the upstream master branch on Tuesday. Then on Wednesday, the upstream master branch grows as all changes from the last integration cycle are merged to it. To make diff easy on Github for next weekly pull request review, you want to rebase your branch against the updated master.

git rebase master MDL-xxxxx-master_topic_branch

Note that rebasing effectively rewrites the history of the branch. '''Do not rebase the branch if there is a chance that somebody has already forked it and based their own branch on it.''' For this reason, many Git tutorials discourage from rebasing any branch that has been published. However in Moodle, all branches submitted for integration are potential subject of rebase (even though we try to not to do it often) and you should not base your own branches on them.

=== Conflicts during rebase ===

During the rebase procedure, conflicts may appear. git-status commands reports the conflicted files. Explore them carefully and fix them in your editor (like you would do with CVS). Then add the files with 'git add' command and continue.

vim conflicted.php
git add conflicted.php
git rebase --continue

== Applying changes from one branch to another ==

Most bugs are fixed at a stable branch (like MOODLE_20_STABLE) and the fix must be prepared for other branches, too (like MOODLE_21_STABLE and the main development branch - master). In Moodle, we do not merge stable branches into the master one. So usually the contributor prepares at least two branches - with the fix for the stable branch(es) and with the fix for the master branch.

If you have a patch prepared on a local branch (let us say MDL-xxxxx-20_brief_name), it is possible to re-apply it to another branch.

=== Cherry-picking a single commit ===

Let us have two local Git repositories ~/public_html/moodle21 containing local installation of Moodle 2.1 and ~/public_html/moodledev with the local installation of most recent development version of Moodle. They both use your public repository at github.com as the origin. You have a branch in moodle21 called MDL-xxxxx-21_topic that was forked off MOODLE_21_STABLE. It contains one commit. Now you want to re-apply this commit to a branch MDL-xxxxx-master_topic in moodledev.

cd ~/public_html/moodledev
git checkout -b MDL-xxxxx-master_topic origin/master (1)
git fetch ../moodle21 MDL-xxxxx-21_topic (2)
git cherry-pick FETCH_HEAD (3)

The command (1) creates new local branch forked off the master. The command (2) fetches all data needed to re-apply the topic branch and stores the pointer to the tip of that branch to FETCH_HEAD symbolic reference. The command (3) picks the tip of the branch (the top-most commit on it) and tries to apply it on the current branch.
There is also a variant of the cherry-pick command that supports multiple commits, shortly (see its man page for details): <syntaxhighlight lang="bash">$ git cherry-pick A^..B</syntaxhighlight> if you want to include from A - see '''^''' - to B, A should be older than B. We will use another approach for cherry-picking multiple commits.

=== Applying a set of patches ===

If the branch MDL-xxxxx-21_topic from the previous example consists of several commits, it may be easier to use git-format-patch and git-am combo to re-apply the whole set of patches (aka patchset). Firstly you will export all commits from the topic branch to files.

cd ~/public_html/moodle21
mkdir .patches
git format-patch -o .patches MOODLE_21_STABLE..MDL-xxxxx-21_topic (1)

The command (1) takes all commits from the topic branch that are not in MOODLE_21_STABLE and exports them one by one to the output directory .patches. Look at the generated files. They contain the patch itself (in diff format) and additional information about the commit. You could eg send these files by email to a friend of yours for peer-review. We will use them in another repository.

cd ~/public_html/moodledev
git checkout -b MDL-xxxxx-master_topic origin/master
git am -3 ../moodle21/.patches/* (1)

The command (1) applies all the files from the .patches directory. When a patch does not apply cleanly, the command tries fall back on 3-way merge (see the -3 parameter). If conflicts occur during the procedure, you can either deal with them and then use `git am --continue` or abort the whole procedure with `git am --abort`.

== See also ==

* [[Git tips]]

; Moodle forum discussions
* [http://moodle.org/mod/forum/discuss.php?d=168094 GIT help needed]
* [http://moodle.org/mod/forum/discuss.php?d=165236 Best way to manage CONTRIB code with GIT]
* [http://moodle.org/mod/forum/discuss.php?d=167063 Handy Git tip for tracking 3rd-party modules and plugins]
* [http://moodle.org/mod/forum/discuss.php?d=167730 Moodle Git repositories]
* [http://moodle.org/mod/forum/discuss.php?d=183409 Git help!! I don't understand rebase enough...]
* [http://moodle.org/mod/forum/discuss.php?d=217617 add MOODLE_24_STABLE to github.com repository]

; External resources
* [https://mirrors.edge.kernel.org/pub/software/scm/git/docs/giteveryday.html Everyday GIT With 20 Commands Or So]
* [https://git-scm.com/book/en/v2 'Pro Git' complete book]
* [http://vimeo.com/14629850 Getting git by Scott Chacon] - an recording of an excellent 1-hour presentation that introducing git, including a simple introduction to what is going on under the hood.
* [http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html Tim Hunt's blog: Fixing a bug in Moodle core: the mechanics]
* [https://github.com/k88hudson/git-flight-rules/blob/master/README.md#flight-rules-for-git Flight rules for Git]

[[Category:Git]]

[[ja:開発者用Git]]

Process

2023-03-24T10:58:19Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:Migrated|newDocId=/general/development/process}}
This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.
==Integration workflow in the tracker==
The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:
===Users===
Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.
===Developers===
Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].
===CiBoT===
CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.
===Component leads===
[https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components. Note that, apart from that, every component also has some [[Component Leads|HQ Component leads]] that will specifically work on associated issues, triaging, monitoring, reviewing, fixing them.

===Component leads reviewers===
Component Lead Reviewers are Component Leads who have the added responsibility of performing a second and final review of a selection of issues within their component.
After reviewing the code, it is sent to the integration team to be pulled without further review.

===Integrators===
From Monday to Thursday, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===
During each week the testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions in the web version and the Moodle mobile app.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===
On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.
==Stable maintenance cycles==
Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===
After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.
See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===
[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).

===Scrum===
At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted to the standard integration workflow process described above.

==Major release cycles==
Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.
===Define roadmap===
The roadmap is prioritised based on user research, stakeholder inputs, community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.
===Planning and development===
The product teams together with UX, employed at Moodle HQ, work on specifications of major new features throughout the cycle, specifying projects ahead of development time.

The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints, where designs and implementation are iterated as required, and goes through the standard weekly integration workflow described above.
===Testing===
During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and volunteer testers from the Moodle community perform manual QA testing of Moodle features. The current set of functional tests is listed in MDLQA-1. The list of tests is extended as new features are added, though we're also trying to reduce the number as more automated [[Acceptance_testing|acceptance tests]] are developed.

There is also a set of tests for manually testing any major theme changes - MDLQA-11592.

For more details, see [[Testing]].
===Sprints===
At Moodle HQ, development takes place in sprints. The sprints are two or three-week periods during which developers to focus on a fixed list of issues. For example, sprints can be arranged within each release cycle as shown in the diagram below.
===Events during cycle===
During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]
; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.
==New feature development==
Major new features in Moodle usually should go through the following process.
===Specification===
The User Experience (UX) team members create detailed wireframes and features and goals for the new feature, based on iterative user research, design sprints, user testing and co-design as part of the product team.

For bigger features there should be a clear overall vision for the outcomes that are to achieved. During implementation design may continue to iterate based on new findings.

Developers create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.
===Community consultation===
Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.
===Develop the code using Git===
Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

Coverage with automated tests ([[PHPUnit]] or [[Behat|Behat_integration]]) is mandatory for new features.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].
===Submit your code for peer review===
Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions (read the [[Testing instructions guide|instructions guide]]) for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.
===Peer review===
The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===
The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. In some cases the Component Lead may perform a Component Lead Review instead of the integration team. See [[Integration Review]] and the information about the integration workflow above.

==Fixing a bug==
Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)
===Make sure there is a tracker issue===
Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].
===Decide which branches the fix is required on===
Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.
===Develop your change using git===
Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like MDL-12345-31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

Consider setting up [https://moodledev.io/general/development/tools/gha GitHub Actions integration] with your repository so tests will be automatically run for you whenever you push work on your fix.

===Submit your code for peer review===
Once your fix is done, it should be submitted for a peer review.

The following information is necessary for this:
* Information about your public git repository
** repository URL
** branch name(s)
** diff URL
* [[Testing instructions guide|Testing instructions]] for how to verify your fix is correct.
If you have never contributed to Moodle and don't see a button "Request peer review", just comment on the issue with the above information. The component lead or another user with sufficient privileges will then send the issue up for peer review for you.

After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.

If you've set up [https://moodledev.io/general/development/tools/gha GitHub Actions integration], the issue will automatically show the Travis build status for the branch(es) you've submitted for peer review.

===Peer review===
The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].
===Submit your code for integration===
It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release. For details see [[Integration Review]].
==Security issues==
Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].
* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.
Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.
====How to remove a branch from Github====
To remove a branch from Github, you can use the following command.
git push github :remote_branch
Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.
==Policy issues==
Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.
Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.
==See also==
* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]
Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU and https://youtu.be/Hu8ne0NCRAg?t=11659
[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Process

2023-03-24T10:57:16Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:Migrated|newDocId=/general/development/process}}
This document summarises the various development processes used in developing Moodle. There are four main processes that overlap.
==Integration workflow in the tracker==
The Moodle tracker keeps track of the status of all bug fixes and new features.

We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.

[[Image:Workflow.jpg]]

A number of roles make this work:
===Users===
Users report bugs and make feature requests directly in the tracker, by creating new issues with a summary and a description.
===Developers===
Developers work on the issues in the tracker to specify solutions and write code that implements these solutions. They will often ask other developers to "peer review" their code in the early stages to avoid problems later on.

While many of the developers work for Moodle.com, a large number are part of the global development community around Moodle. If you're interested in becoming a recognised developer, see [[Tracker_guide#Tracker_groups_and_permissions|Tracker groups and permissions]].
===CiBoT===
CiBoT is not a person but a bot who monitors the tracker and performs the [[Automated code review]] when issue is submitted for Peer review or when developer added ''cime'' label.
===Component leads===
[https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page Component leads] are developers with some responsibility for particular components (plugins or modules) in Moodle. They have authority to decide that a particular fix is suitable and complete enough to be considered for integration in Moodle core and should be called upon to complete peer reviews for code in their components. Note that, apart from that, every component also has some [[Component Leads|HQ Component leads]] that will specifically work on associated issues, triaging, monitoring, reviewing, fixing them.

===Component leads reviewers===
Component Lead Reviewers are Component Leads who have the added responsibility of performing a second and final review of a selection of issues within their component.
After reviewing the code, it is sent to the integration team to be pulled without further review.

===Integrators===
From Monday to Thursday, the integration team (a small team of senior developers employed by Moodle HQ) conducts a code-level review of all issues in the integration queue. This is often called the "pull" process. If the fix is judged appropriate they will integrate the code into our git integration repository for further testing and it gets added to the testing queue.

If they find problems they reject the issue and send it back to the developer for further work.

===Testers===
During each week the testers look at all the issues in the testing queue, trying each fix and feature to make sure that it does actually fix the problem it was supposed to, and that there are no regressions in the web version and the Moodle mobile app.

If they find problems they reject the issue and integrators may remove it from the integration repository and push it back to the developer for further work.

See [[Testing of integrated issues]] for more details.

===Production maintainers===
On Thursday each week, production maintainers merge all the issues that passed testing into the git production repository, and it becomes available for use on production systems via git and download packages.
==Stable maintenance cycles==
Moodle releases regular updates of the stable version of the software to fix bugs and other issues. Releases like 2.2.1, 2.2.2, 2.2.3 etc only include fixes based on the latest major release (2.2) and never any significant new features or database changes.

At Moodle HQ there are teams of developers using the [http://www.scrum.org/ Scrum framework] to work on these issues (as well as new features for [[#Major_release_cycles|major releases]]).

===Minor release (point release) timing===
After [[#Major_release_cycles|major releases]] there will be minor releases.
* x.x.1 will occur approximately two months after each major release (eg. 2.x).
* There will then be another point release every two months after that.
See the [[Releases#General_release_calendar|General release calendar]] for details.

===Issue triage===
[[Bug_triage|Issue triage]] involves evaluating new issues, making sure that they are recorded correctly. One of the most important jobs triagers do is to identify issues that should be fixed in the stable branch. These are set with a priority ranging from "Trivial" up to "Blocker" and other features are checked.

At Moodle HQ there are currently teams working on stable issues (mostly bugs reported by users) and improvements and new features (Partners, Moodle Association, user suggestions and Martin Dougiamas).

===Scrum===
At Moodle HQ, every three weeks, the stable team takes a number of the most urgent issues from the backlog to work on during a period known as a ''sprint''.

At the start of a sprint there is a period of planning and estimation. All issues on the backlog are given a relative rank that is based on issue features including priority, security, Partner interest, patches and votes. Issues are given a relative size in Story Points and these points are summed to allow the teams to determine how many issues they can work on in the sprint.

During the sprint, the team meets daily to discuss solutions and progress, as well as to organise testing and peer reviews of code. The team has a ''Scrum master'' to help everyone stay organised, to "unblock" any barriers to progress and to protect the team from distracting influences (mostly people attempting to add to the developers' workloads) during the sprint. The teams' work is documented publicly in the tracker.

Whenever a solution for an issue is finished, it is submitted to the standard integration workflow process described above.

==Major release cycles==
Since Moodle 2.0, we have a policy of release major versions (eg 2.1, 2.2) every six months in May and November. See the [[Releases#General_release_calendar|General release calendar]] for more details.

Each release can be different, but generally the cycles work as follows.
===Define roadmap===
The roadmap is prioritised based on user research, stakeholder inputs, community wishes, third-party developments and important issues within the existing code.

Sometimes new features might be based on earlier features, sometimes they may be something developed by a third party that needs to be evaluated and sometimes it might be something completely new.
===Planning and development===
The product teams together with UX, employed at Moodle HQ, work on specifications of major new features throughout the cycle, specifying projects ahead of development time.

The process of [[#New_feature_development|new feature development]] is described below. When specifications are in place, new code is developed during sprints, where designs and implementation are iterated as required, and goes through the standard weekly integration workflow described above.
===Testing===
During development, as new code is integrated, automated testing conducted at the [[PHPUnit|code]] and [[Acceptance_testing|interface]] levels, to make sure there are no regressions caused by new features.

In the last month before the release, a feature freeze is called (no new features can be added) and volunteer testers from the Moodle community perform manual QA testing of Moodle features. The current set of functional tests is listed in MDLQA-1. The list of tests is extended as new features are added, though we're also trying to reduce the number as more automated [[Acceptance_testing|acceptance tests]] are developed.

There is also a set of tests for manually testing any major theme changes - MDLQA-11592.

For more details, see [[Testing]].
===Sprints===
At Moodle HQ, development takes place in sprints. The sprints are two or three-week periods during which developers to focus on a fixed list of issues. For example, sprints can be arranged within each release cycle as shown in the diagram below.
===Events during cycle===
During each cycle there are a periods and events that occur between and around sprints.

[[Image:Dev sprint calendar.png|800px]]
; '''Planning and bug fixing'''
: A period during which the Roadmap is explored, specs are written and prototypes are created. Regressions in the recent release are fixed as they arise.
; '''End sync period'''
: During the [[Integration Review#On-sync period|on-sync period]], the recent release and master versions are kept synchronised. No new code is added during this period, which ensures regressions are fixed rapidly. This also allows for planning and provides relief for developers after a release.
; '''Personal projects'''
: Affecting full-time HQ developers only, this period allows for individual creations to be explored and provides a break from sprints.
; '''Code freeze'''
: A point after which no new code (only fixes to existing code) is accepted until beyond the release. This stabilisation allows for QA testing.
; '''QA, bug fixing, continuous integration'''
: A period after the code freeze where quality assurance testing takes place. No new code is added, which means developers are able to respond rapidly to bugs found. Integration becomes [[Integration Review#During continuous integration/Freeze/QA period|continuous]], meaning that failed QA tests can be re-run within days rather than having to wait for the weekly release.
; '''Release candidate'''
: A point prior to the full release where a candidate is made public for wider testing.
==New feature development==
Major new features in Moodle usually should go through the following process.
===Specification===
The User Experience (UX) team members create detailed wireframes and features and goals for the new feature, based on iterative user research, design sprints, user testing and co-design as part of the product team.

For bigger features there should be a clear overall vision for the outcomes that are to achieved. During implementation design may continue to iterate based on new findings.

Developers create a detailed spec (here in the developer docs) outlining their goals for the development and their design for meeting those goals.

Developers should also create an issue in the tracker (linking to your docs) to keep track of the project status.
===Community consultation===
Get the community involved in looking at the spec to see if it meets their needs and to get further feedback. Please post in the [http://moodle.org/mod/forum/view.php?id=8052 Future major features forum] on moodle.org. You could also blog/tweet about it etc.

Community developers proposing a new feature will want to talk with HQ core developers to make sure the ideas make sense, and possibly get some review on database design, architecture and so on.
===Develop the code using Git===
Develop your code on an open Git repository, like github.com. That enables people to see your code and to help you as it develops. Testers and early adopters also have the opportunity to try it early in the process and give you more valuable feedback.

Coverage with automated tests ([[PHPUnit]] or [[Behat|Behat_integration]]) is mandatory for new features.

It is essential that your code follows the [[Coding|Moodle Coding Guide]].
===Submit your code for peer review===
Click on "Request peer review" button in the tracker.

You need to fill in the information about your public git repository and which branches the fixes are on. Make sure you are listed as Assignee.

This would be a good time to fill in the testing instructions (read the [[Testing instructions guide|instructions guide]]) for how to verify your fix is correct. You may also wish to add a comment in the bug.

Component leads should put issues, which affect code in their components, up for peer review to allow interested parties to provide feedback. However, if it is not reviewed in a week, a component lead may send the issue to integration. If integrators consider that the issue has not been given proper chance for peer review (e.g. is extremely large or complex...) it can be decided to move the issue back in the process.

All other developers, including people who are component leads but working outside their component, should have their issues peer reviewed before they are sent to integration.
===Peer review===
The [http://tracker.moodle.org/browse/MDL#selectedTab=com.atlassian.jira.plugin.system.project%3Acomponents-panel component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].

===Submit the code for integration===
The developer is responsible for acting on the feedback from the peer reviewer. If changes have been made and the developer is satisfied that this has accommodated the feedback from the peer reviewer, then the developer can submit the issue for integration. If there have been significant changes after the peer review, or if the peer reviewer has raised concerns about the approach taken, then the developer should offer the issue up for peer review again, most often to the same peer reviewer, but not necessarily.

Submitting an issue to integration is much the same as for any Moodle code. In some cases the Component Lead may perform a Component Lead Review instead of the integration team. See [[Integration Review]] and the information about the integration workflow above.

==Fixing a bug==
Bug fixes, and minor features or enhancements should go through the following process. (The only exception is English language string typo fixes or suggested improvements, which may be contributed to the en_fix language pack on the [http://lang.moodle.org/ Moodle translation site].)
===Make sure there is a tracker issue===
Every change must have an issue in the tracker. If you are fixing a bug, there is probably one there already, but if not, create one. [[Tracker tips|Tips for searching tracker]].
===Decide which branches the fix is required on===
Bugs should normally be fixed on all the supported stable branches that are affected. New features should just go into master, but sometimes minor enhancements are made on the most recent stable branch.
===Develop your change using git===
Develop your fix and push the change to an open git repository, for example on github.com. See also [[Git for developers]]

It is essential that your code follows the [[Coding|Moodle Coding Guide]].

You will need to push one commit for each branch the fix needs to be applied to. Often people use branch names like MDL-12345-31_brief_name so it is clear what each branch is. [http://kernel.org/pub/software/scm/git/docs/git-cherry-pick.html git cherry-pick] can help with replicating the fix onto different branches.

Consider setting up [https://moodledev.io/general/development/tools/gha GitHub Actions integration] with your repository so tests will be automatically run for you whenever you push work on your fix.

===Submit your code for peer review===
Once your fix is done, it should be submitted for a peer review.

The following information is necessary for this:
* Information about your public git repository
** repository URL
** branch name(s)
** diff URL
* [[Testing instructions guide|Testing instructions]] for how to verify your fix is correct.
If you have never contributed to Moodle and don't see a button "Request peer review", just comment on the issue with the above information. The component lead or another user with sufficient privileges will then send the issue up for peer review for you.

After your first fix is integrated you will be added to developers group and will be able to send issues for peer review yourself. In this case make sure you are listed as Assignee and click on "Request peer review" button in the tracker.

If you've set up [[Travis integration]], the issue will automatically show the Travis build status for the branch(es) you've submitted for peer review.
===Peer review===
The [https://tracker.moodle.org/projects/MDL?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page component lead] should peer-review the change. If there is no component lead for an affected component, any other recognised developer may complete the peer review. The peer reviewer will either give you comments on the code and if it needs more work.

Process and the list of things to check are described in [[Peer reviewing]].
===Submit your code for integration===
It will then be reviewed the following week by one of the integration team and either integrated or rejected. Once integrated, the fix will be tested, and then included in the next weekly release. For details see [[Integration Review]].
==Security issues==
Issues identified as [[Security|security issues]] are resolved in a slightly different way, in order to achieve responsible disclosure as described in [[Moodle security procedures]].
* Security issues should be labelled as "Minor" or "Serious" in order control visibility of the issue.
** An issue reported with a security level of "Could be a security issue" should be evaluated as soon as possible and either set as "Minor" or "Serious" or the security level should be set to "None".
* Solutions to security issues should not:
** be made available in public repositories.
*** If a developer has shared a solution as Git branches via Github, they should be asked to provide the solutions as [[How_to_create_a_patch|stand-alone patches]] attached to the issue and to [[#How to remove a branch from Github|remove the solution from Github]].
** contain details about the security problem in the commit message.
*** Instead use generic terms like, "improve", "better handling of" ..
* The solution will not be integrated until the week before a [[Process#Stable_maintenance_cycles|minor release]] following the normal [[Release process|Release process]]. In short, the issue will be incorporated into the integration version, rebased, tested and made ready for release as a normal issue would, but not until as late as possible.
* Details of security issues will be shared with registered admins with the minor release.
* Details of security issues will not be publicly announced until one week after a minor release to allow admins to update.
Note that not all the labelled (minor) security issues are always handled following the procedure above. It's possible that, after discussion, it's decided a given issue is not a real Moodle security problem (say external disclosures/potential attacks using Moodle as vector, not as target, discussions revealing some private details...). Those issues will be processed as normal issues, generating the needed user documentation if necessary and will be part of the habitual weekly releases.
====How to remove a branch from Github====
To remove a branch from Github, you can use the following command.
git push github :remote_branch
Where ''remote_branch'' is the name of your remote branch, for example 'wip-mdl-1234'. This effectively replaces the remote branch with nothing, removing the remote branch, but leaving the branch intact in your local Git repository. Please note that its likely that your commit will still exist on github due to the nature of git, so its best to avoid doing this in the first place.
==Policy issues==
Occasionally within Moodle we run into policy issues where a high-level decision needs to be made about how things are to be done.

In these cases the process is as follows:
* Create an issue in the tracker with a [https://tracker.moodle.org/browse/MDL/component/12733 Policy component] and put "POLICY:" as a prefix on the summary.
* In the description describe the problem clearly as well as all the options. If it's long then make a page here in Moodle Dev Docs and link to it.
* Do not use this issue for code. If there are issues that depend on this policy decision, then add tracker links to them as dependencies.
* Feel free to encourage people to come and talk about the policy to support various points of view. The more evidence we have (from everyone in the community) the better.
Some time has been scheduled in the weekly Moodle HQ meeting to look at Policy issues and try to make decisions on them. We discuss all the evidence and try to achieve a high amount of consensus. Deadlocked issues can be resolved by a decision from Martin Dougiamas (this is rarely needed).

Decisions will be posted on the issue and that issue will be closed, allowing any dependent issues to continue to integration (or not). Decisions are final and bribes hardly ever work.
==See also==
* [[Release process]]
* [[Deprecation]]
* [http://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11350 Integration dashboard]
Walks-though of the process for contributors:
* By Dan Poltawski, Integrator: http://www.slideshare.net/poltawski/how-to-guarantee-your-change-is-integrated-to-moodle-core, https://www.youtube.com/watch?v=836WtnM2YpM
* By Tim Hunt, contributor: http://tjhunt.blogspot.co.uk/2012/03/fixing-bug-in-moodle-core-mechanics.html and https://www.youtube.com/watch?v=gPPA3h7OGQU and https://youtu.be/Hu8ne0NCRAg?t=11659
[[Category:Processes]]
[[Category:Quality Assurance]]
[[Category:Git]]
[[Category:Core development]]

Travis integration

2023-03-24T10:50:00Z

Stronk7: Part of MDLSITE-7135 - document the removal

{{Template:WillNotMigrate}}

Given the two notes below, you probably don't want to read this page. [[Github actions integration]] is much more likely to be what you want.

<div class="errorbox">Since March 24th 2023, for Moodle 4.2dev and up, support for Travis CI in core has been completely removed. It's recommended to use the (enabled by default) [https://moodledev.io/general/development/tools/gha GitHub Actions integration] instead. More information can be found at:
* Policy issue with the agreement: MDLSITE-7135
* Moodle issue with the removal: MDL-77714</div>

<div class="errorbox">Travis [https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom has announced] that '''travis-ci.org will be closed down completely on December 31st 2020''', with travis-ci.com becoming the unified place for all projects. More information can be found at:
* [https://docs.travis-ci.com/user/migrate/open-source-repository-migration Migrating repositories to travis-ci.com]
* Moodle Tracker: MDLSITE-6246</div>
<div class="errorbox">Travis [https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing has announced], November 2, 2020, that '''travis-ci.com won't be (unlimitedly) free anymore''', with everybody getting some credits (processing time) once and, after using them, you must change to some of their (paid) plans. Few weeks later, November 24, 2020, [https://blog.travis-ci.com/oss-announcement they have published an update] specifically for Open Source. There, they recommend to contact them ''"for anything relating with your open source account"''. Up to you!
More information can be found at:
* Moodle Tracker: MDL-70265</div>

== Moodle core ==

=== Background ===

Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.

There are many Continuous Integration tools available to developers, and Travis-CI is just one of those available to the Open Source community.

Since version 3.0, Moodle includes a Travis configuration file in its repository. This configuration file configures and controls a Travis build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.

Note: Moodle HQ uses the Jenkins CI platform and this should be seen as the [https://ci.moodle.org/ canonical CI server for Moodle]. The Travis integration aims is to provide early warning to developers of any issues with their code.

=== Usage ===

Travis-CI is available and is usually configured to run automatically when pushing code, but it must be configured before first use.

For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the service available from Travis is only available to public repositories.

=== Setup ===

# [https://travis-ci.com/auth Sign in to Travis CI] using your GitHub account
# Once you’re signed in, and the initial synchronisation of your GitHub repositories has completed, go to your [https://travis-ci.com/profile profile page]
# Enable Travis CI for your clone of the Moodle repository [[File:moodle-travis-enable.png]]
# Click on the cog icon to configure the Integration
# Ensure that "Build pushed branches" is enabled [[File:moodle-travis-settings-2020.png]]
# Email notifications will be sent by default to the committer and the commit author. If you want to turn off email notifications for this repository, you can define an environment variable with name MOODLE_EMAIL and "no" as value.
# By default, the following jobs will be executed for each branch sent to github:
## GRUNT: 1 job that will check that all your javascript and scss has been properly built (see [[Grunt]]) and is part of the patch.
## CITESTS: 1 job that will perform a lightweight linting of your branch.
## PHPUNIT: 1 job that will run all the unit tests on your branch (using the lowest PHP version supported by the branch and PostgreSQL as database).
# If you want to change those defaults, you can use the following environment variables:
## MOODLE_DATABASE: With value "mysqli" to switch your runs to that database. With value "all" to run both PostgreSQL and MySQL unit tests.
## MOODLE_PHP: With value "all", to run the unit tests both with the lowest and the highest PHP versions supported by the branch.
Note that adding more jobs will increase the time needed (and the credits consumed) for processing each branch, so be careful picking your fav configuration.
[[File:environment_variables.png|Define an environment variable]]

=== How do I start a build? ===

It won't build immediately after setup. Builds start automatically when you push a change.

== Moodle plugins ==

See [https://moodlehq.github.io/moodle-plugin-ci/ Moodle Plugin CI repository] for setup instructions.

Related discussions:
* [https://moodle.org/mod/forum/discuss.php?d=323384 Adding Travis CI support into your plugin]
* [https://moodle.org/mod/forum/discuss.php?d=389744 Recent Travis-CI issues with plugins]

=== Ignoring files and folders ===

For some of the code analysis tools, it is important to ignore some files within the plugin because they might not be fixable, like a third party library. The all code analysis commands in this project ignore files and directories listed in the thirdpartylibs.xml plugin file. See https://docs.moodle.org/dev/Plugin_files#thirdpartylibs.xml for more info.

==== Ignoring files ====

Specifically for the codechecker command, you can ignore a single line, a section of a file or the whole file by using specific PHP comments. For details see this [[CodeSniffer]] wiki page.
In addition, you can ignore additional files by defining IGNORE_PATHS and/or IGNORE_NAMES environment variables in your .travis.yml file. These environment variables wont work for Grunt tasks, but will for everything else. Example:
<syntaxhighlight lang="php">
env:
global:
- MOODLE_BRANCH=MOODLE_35_STABLE
- IGNORE_PATHS=vendor/widget,javascript/min-lib.js
- IGNORE_NAMES=*-m.js,bad_lib.php
matrix:
- DB=pgsql
- DB=mysqli
</syntaxhighlight>
Both environment variables take a CSV value. For IGNORE_PATHS, it takes relative file paths to ignore. File paths can be a simple string like foo/bar or a regular expression like /^foo\/bar/. For IGNORE_NAMES, it takes file names to ignore. File names can be a simple string like foo.php, a glob like *.php or a regular expression like /\.php$/.

If you need to specify ignore paths for a specific command, then you can define additional environment variables. The variable names are the same as above, but prefixed with COMMANDNAME_. Example:

<syntaxhighlight lang="php">
env:
global:
- MOODLE_BRANCH=MOODLE_35_STABLE
- IGNORE_PATHS=vendor/widget,javascript/min-lib.js
- IGNORE_NAMES=*-m.js,bad_lib.php
- PHPUNIT_IGNORE_PATHS=$IGNORE_PATHS,cli
matrix:
- DB=pgsql
- DB=mysqli
</syntaxhighlight>
In the above example, we are adding the cli path to our ignore paths for the PHPUnit command (this is also how you can ignore files for code coverage). Please note that this is a complete override and there is no merging with IGNORE_PATHS and IGNORE_NAMES. So, in the above, the PHPUnit command would not ignore the file names defined in IGNORE_NAMES.

== See also ==

* [[Github actions integration]]: For information about the, also supported, integration with GitHub Actions.

[[Category:Developer tools]]

Template:XMLRPC Note Moodle 4.1

2023-01-02T10:35:46Z

Stronk7: Template note to be added to various user docs pages about the move of webservice_xmlrpc out from core in Moodle 4.1

{{Note|The installation of the '''XMLRPC PHP extension''' is not needed for Moodle 4.1 core anymore. All [[MNet]] features continue working exactly the same, but using a PHP library instead (see MDL-76055 for details).
If you were using the '''webservice_xmlrpc''' plugin for integrations with other systems, be warned that it has been removed from core for Moodle 4.1 (see MDL-76052 for details). It's now available @ https://github.com/moodlehq/moodle-webservice_xmlrpc and has been also published in the [https://moodle.org/plugins/webservice_xmlrpc Plugins directory]. Note that, if you want to continue using this plugin, then you will need, '''before starting the upgrade process''', to:
# Install the '''XMLRPC PHP extension''', the webservice requires it.
# Install the '''webservice_xmlrpc plugin''', from the links in the previous paragraph, into the <tt>webservice/xmlrpc</tt> directory.
# Then, and only then, start the upgrade process.}}

Web service API functions

2023-01-02T10:34:50Z

Stronk7: Note about Moodle 4.1 and XMLRPC extension/webservice added

{{Moodle_3.11}}

{| class = "wikitable"
|+Color meaning
|-
| style="background:#D4FFDF;" | Implemented
|-
| style="background:#ffdead;" | Must be implemented
|-
| style="background:#ffdfcd;" | Suggested
|}

==Web service protocols==

{| class="wikitable sortable"
! Name !! Moodle Ver. !! class="unsortable" |Description !! class="unsortable" |CORS !! |Issue
|-
| style="background:#D4FFDF;" | REST (returning XML) || style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | XML data accessed through a REST API (not restful) || Supported (3.0 and onwards) ||
|-
| style="background:#D4FFDF;" | REST (returning JSON) || style="background:#D4FFDF;" | 2.2 || style="background:#D4FFDF;" | JSON data accessed through a REST API (not restful) || Supported (3.0 and onwards)|| MDL-29242
|-
| style="background:#ffdfcd;" | REST (returning JSONP) || style="background:#ffdfcd;" | 2.X || style="background:#ffdfcd;" | Would be very useful for client-side JavaScript || Not supported || MDL-29913
|-
| style="background:#ffdfcd;" | JSON || style="background:#ffdfcd;" | 2.X || style="background:#ffdfcd;" | JSON server receives a JSON encoded params and return JSON encoded values. || Not supported || MDL-21341
|-
| style="background:#ffdead;" | SOAP|| style="background:#ffdead;" | 2.0 || style="background:#ffdead;" | Very important for interoperating with Java and .Net applications. There was a partial implementation JAVA/.Net in Moodle 2.0, but it does not work for anything but the most trivial functions. It is fully working with PHP clients.|| Not supported || MDL-20804, MDL-28988, MDL-28989
|-
| style="background:#D4FFDF;" | XMLRPC|| style="background:#D4FFDF;" | 2.0 || style="background:#D4FFDF;" | XML remote-procedure call. {{Template:XMLRPC Note Moodle 4.1}} || Not supported ||
|}

==Web service functions==

=== Naming convention ===

All functions should be named as

<tt>{fullcomponent}_{methodname}</tt> - example: <tt>core_user_get_user_preferences</tt>

where

* <tt>{fullcomponent}</tt> is the full [[Frankenstyle|frankenstyle]] name or the component such as <tt>core_user</tt> here
* <tt>{methodname}</tt> is the name of the method in the form of <tt>{verb}_{noun}</tt> such as <tt>get_user_preferences</tt> here
** <tt>{verb}</tt> - preferably one of <tt>get, create, delete, update</tt> or eventually other that well describes the action
** <tt>{noun}</tt> - moodle objects, usually plural such as <tt>user_preferences</tt> here, or e.g. <tt>posts, discussions, users, courses</tt> etc.

This naming convention has been in place since Moodle 2.2. See MDL-29106 for more details.

=== Core web service functions ===

{| class="wikitable sortable"
!Area!! Name !! Introduced in !! class="unsortable" |Description !! Available AJAX !! Login required !! Services
|-
| \core_user\search_identity || core_user_search_identity || 3.11 || Return list of users identities matching the given criteria in their name or other identity fields. || Yes || Yes ||
|-
| auth_email || auth_email_get_signup_settings || 3.2 || Get the signup required settings and profile fields. || Yes || No ||
|-
| auth_email || auth_email_signup_user || 3.2 || Adds a new user (pendingto be confirmed) in the site. || Yes || No ||
|-
| block_recentlyaccesseditems || block_recentlyaccesseditems_get_recent_items || 3.6 || List of items a user has accessed most recently. || Yes || Yes || moodle_mobile_app
|-
| block_starredcourses || block_starredcourses_get_starred_courses || 3.6 || Get users starred courses. || Yes || Yes || moodle_mobile_app
|-
| core\record_userfeedback_action || core_create_userfeedback_action_record || 3.9 || Record the action that the user takes in the user feedback notification for future use. || Yes || Yes ||
|-
| core_auth || core_auth_confirm_user || 3.2 || Confirm a user account. || Yes || No ||
|-
| core_auth || core_auth_is_age_digital_consent_verification_enabled || 3.5 || Checks if age digital consent verification is enabled. || Yes || No ||
|-
| core_auth || core_auth_is_minor || 3.5 || Requests a check if a user is a digital minor. || Yes || No ||
|-
| core_auth || core_auth_request_password_reset || 3.4 || Requests a password reset. || Yes || No ||
|-
| core_auth || core_auth_request_password_reset || 3.4 || Requests a password reset. || Yes || No ||
|-
| core_auth || core_auth_resend_confirmation_email || 3.6 || Resend confirmation email. || Yes || No ||
|-
| core_auth || core_auth_resend_confirmation_email || 3.6 || Resend confirmation email. || Yes || No ||
|-
| core_backup || core_backup_get_async_backup_links_backup || 3.7 || Gets the data to use when updating the status table row in the UI for when an async backup completes. || Yes || Yes ||
|-
| core_backup || core_backup_get_async_backup_links_restore || 3.7 || Gets the data to use when updating the status table row in the UI for when an async restore completes. || Yes || Yes ||
|-
| core_backup || core_backup_get_async_backup_progress || 3.7 || Get the progress of an Asyncronhous backup. || Yes || Yes ||
|-
| core_backup || core_backup_get_copy_progress || 3.9 || Gets the progress of course copy operations. || Yes || Yes ||
|-
| core_backup || core_backup_submit_copy_form || 3.9 || Handles ajax submission of course copy form. || Yes || Yes ||
|-
| core_badges || core_badges_get_user_badges || 3.1 || Returns the list of badges awarded to a user. || No || Yes || moodle_mobile_app
|-
| core_block || core_block_get_course_blocks || 3.3 || Returns blocks information for a course. || No || Yes || moodle_mobile_app
|-
| core_block || core_block_get_dashboard_blocks || 3.6 || Returns blocks information for the given user dashboard. || No || Yes || moodle_mobile_app
|-
| core_block\fetch_addable_blocks || core_block_fetch_addable_blocks || 3.11 || Returns all addable blocks in a given page. || Yes || Yes || moodle_mobile_app
|-
| core_blog || core_blog_get_entries || 3.6 || Returns blog entries. || Yes || No || moodle_mobile_app
|-
| core_blog || core_blog_view_entries || 3.6 || Trigger the blog_entries_viewed event. || Yes || No || moodle_mobile_app
|-
| core_calendar || core_calendar_create_calendar_events || 2.5 || Create calendar events || No || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_delete_calendar_events || 2.5 || Delete calendar events || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_action_events_by_course || 3.3 || Get calendar action events by course || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_action_events_by_courses || 3.3 || Get calendar action events by courses || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_action_events_by_timesort || 3.3 || Get calendar action events by tiemsort || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_allowed_event_types || 3.7 || Get the type of events a user can create in the given course. || No || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_calendar_access_information || 3.7 || Convenience function to retrieve some permissions/access information for the given course calendar. || No || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_calendar_day_view || 3.4 || Fetch the day view data for a calendar || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_calendar_event_by_id || 3.4 || Get calendar event by id || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_calendar_events || 2.5 || Get calendar events || No || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_calendar_monthly_view || 3.4 || Fetch the monthly view data for a calendar || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_calendar_upcoming_view || 3.4 || Fetch the upcoming view data for a calendar || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_get_timestamps || 3.8 || Fetch unix timestamps for given date times. || Yes || Yes ||
|-
| core_calendar || core_calendar_submit_create_update_form || 3.4 || Submit form data for event form || Yes || Yes || moodle_mobile_app
|-
| core_calendar || core_calendar_update_event_start_day || 3.4 || Update the start day (but not time) for an event. || Yes || Yes || moodle_mobile_app
|-
| core_calendar\export\token || core_calendar_get_calendar_export_token || 3.10 || Return the auth token required for exporting a calendar. || No || No || moodle_mobile_app
|-
| core_cohort || core_cohort_add_cohort_members || 2.4 || Add members to cohort || No || Yes ||
|-
| core_cohort || core_cohort_create_cohorts || 2.4 || Create cohorts || No || Yes ||
|-
| core_cohort || core_cohort_delete_cohort_members || 2.4 || Delete members from cohort || No || Yes ||
|-
| core_cohort || core_cohort_delete_cohorts || 2.4 || Delete cohorts || No || Yes ||
|-
| core_cohort || core_cohort_get_cohort_members || 2.4 || Get cohort members || No || Yes ||
|-
| core_cohort || core_cohort_get_cohorts || 2.4 || Get cohorts || No || Yes ||
|-
| core_cohort || core_cohort_search_cohorts || 3.4 || Search for cohorts. || Yes || Yes ||
|-
| core_cohort || core_cohort_update_cohorts || 2.4 || Update cohorts || No || Yes ||
|-
| core_comment || core_comment_add_comments || 3.8 || Adds a comment or comments. || No || Yes || moodle_mobile_app
|-
| core_comment || core_comment_delete_comments || 3.8 || Deletes a comment or comments. || No || Yes || moodle_mobile_app
|-
| core_comment || core_comment_get_comments || 2.9 || Return all the comments for an specific component, context. || No || Yes || moodle_mobile_app
|-
| core_competency || core_competency_add_competency_to_course || 3.1 || Add competency to a course || Yes || Yes ||
|-
| core_competency || core_competency_add_competency_to_plan || 3.1 || Add a competency to a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_add_competency_to_template || 3.1 || Add competency to a template || Yes || Yes ||
|-
| core_competency || core_competency_add_related_competency || 3.1 || Create a relationship between competencies || Yes || Yes ||
|-
| core_competency || core_competency_approve_plan || 3.1 || Approve a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_competency_framework_viewed || 3.1 || Notify a competency framework as being viewed || Yes || Yes ||
|-
| core_competency || core_competency_competency_viewed || 3.1 || Report a competency as being viewed || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_complete_plan || 3.1 || Complete a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_count_competencies || 3.1 || Count the competencies || Yes || Yes ||
|-
| core_competency || core_competency_count_competencies_in_course || 3.1 || Count competencies in a course || Yes || Yes ||
|-
| core_competency || core_competency_count_competencies_in_template || 3.1 || Count the competencies in a template || Yes || Yes ||
|-
| core_competency || core_competency_count_competency_frameworks || 3.1 || Count the competency frameworks || Yes || Yes ||
|-
| core_competency || core_competency_count_course_module_competencies || 3.8 || Count the competencies in a course module || Yes || Yes ||
|-
| core_competency || core_competency_count_courses_using_competency || 3.1 || Count courses using a competency || Yes || Yes ||
|-
| core_competency || core_competency_count_templates || 3.1 || Count templates || Yes || Yes ||
|-
| core_competency || core_competency_count_templates_using_competency || 3.1 || Count templates using a competency || Yes || Yes ||
|-
| core_competency || core_competency_create_competency || 3.1 || Create a competency || Yes || Yes ||
|-
| core_competency || core_competency_create_competency_framework || 3.1 || Create a competency framework || Yes || Yes ||
|-
| core_competency || core_competency_create_plan || 3.1 || Create a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_create_template || 3.1 || Create a template || Yes || Yes ||
|-
| core_competency || core_competency_create_user_evidence_competency || 3.1 || Link an evidence of prior learning with a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_delete_competency || 3.1 || Delete a competency || Yes || Yes ||
|-
| core_competency || core_competency_delete_competency_framework || 3.1 || Delete a competency framework || Yes || Yes ||
|-
| core_competency || core_competency_delete_evidence || 3.1 || Delete an evidence || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_delete_plan || 3.1 || Delete a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_delete_template || 3.1 || Delete a template || Yes || Yes ||
|-
| core_competency || core_competency_delete_user_evidence || 3.1 || Delete an evidence of prior learning || Yes || Yes ||
|-
| core_competency || core_competency_delete_user_evidence_competency || 3.1 || Remove a link between an evidence of prior learning and a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_duplicate_competency_framework || 3.1 || Duplicate a competency framework || Yes || Yes ||
|-
| core_competency || core_competency_duplicate_template || 3.1 || Duplicate a template || Yes || Yes ||
|-
| core_competency || core_competency_get_scale_values || 3.1 || Get the values for a scale || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_grade_competency || 3.1 || Rate a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_grade_competency_in_course || 3.1 || Rate a user's competency in a course || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_grade_competency_in_plan || 3.1 || Rate a user's competency in a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_list_competencies || 3.1 || List competencies || Yes || Yes ||
|-
| core_competency || core_competency_list_competencies_in_template || 3.1 || List the competencies of a template || Yes || Yes ||
|-
| core_competency || core_competency_list_competency_frameworks || 3.1 || List the competency frameworks || Yes || Yes ||
|-
| core_competency || core_competency_list_course_competencies || 3.1 || List the competencies in a course || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_list_course_module_competencies || 3.8 || List the competencies in a course module || Yes || Yes ||
|-
| core_competency || core_competency_list_plan_competencies || 3.1 || List a learning plan's competencies || Yes || Yes ||
|-
| core_competency || core_competency_list_templates || 3.1 || List templates || Yes || Yes ||
|-
| core_competency || core_competency_list_templates_using_competency || 3.1 || List templates using a competency || Yes || Yes ||
|-
| core_competency || core_competency_list_user_plans || 3.1 || List a user's learning plans || Yes || Yes ||
|-
| core_competency || core_competency_move_down_competency || 3.1 || Move a competency down in its branch || Yes || Yes ||
|-
| core_competency || core_competency_move_up_competency || 3.1 || Move a competency up in its branch || Yes || Yes ||
|-
| core_competency || core_competency_plan_cancel_review_request || 3.1 || Cancel the review request of a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_plan_request_review || 3.1 || Request the review of a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_plan_start_review || 3.1 || Start the review of a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_plan_stop_review || 3.1 || Stop the review of a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_read_competency || 3.1 || Fetch a competency || Yes || Yes ||
|-
| core_competency || core_competency_read_competency_framework || 3.1 || Fetch a competency framework || Yes || Yes ||
|-
| core_competency || core_competency_read_plan || 3.1 || Fetch a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_read_template || 3.1 || Fetch a template || Yes || Yes ||
|-
| core_competency || core_competency_read_user_evidence || 3.1 || Fetch an evidence of prior learning || Yes || Yes ||
|-
| core_competency || core_competency_remove_competency_from_course || 3.1 || Remove competency from a course || Yes || Yes ||
|-
| core_competency || core_competency_remove_competency_from_plan || 3.1 || Remove a competency from a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_remove_competency_from_template || 3.1 || Remove competency from template || Yes || Yes ||
|-
| core_competency || core_competency_remove_related_competency || 3.1 || Remove a relationship between competencies || Yes || Yes ||
|-
| core_competency || core_competency_reopen_plan || 3.1 || Reopen a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_reorder_course_competency || 3.1 || Reorder competencies in a course || Yes || Yes ||
|-
| core_competency || core_competency_reorder_plan_competency || 3.1 || Reopen a competency in a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_reorder_template_competency || 3.1 || Reorder competencies in a template || Yes || Yes ||
|-
| core_competency || core_competency_request_review_of_user_evidence_linked_competencies || 3.1 || Request the review of the user's competencies linked to an evidence of prior learning || Yes || Yes ||
|-
| core_competency || core_competency_search_competencies || 3.1 || Search for competencies || Yes || Yes ||
|-
| core_competency || core_competency_set_course_competency_ruleoutcome || 3.1 || Set the rule of course competencies || Yes || Yes ||
|-
| core_competency || core_competency_set_parent_competency || 3.1 || Relocate a competency to another parent || Yes || Yes ||
|-
| core_competency || core_competency_template_has_related_data || 3.1 || Check whether a template has related data || Yes || Yes ||
|-
| core_competency || core_competency_template_viewed || 3.1 || Report a template as being viewed || Yes || Yes ||
|-
| core_competency || core_competency_unapprove_plan || 3.1 || Unapprove a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_unlink_plan_from_template || 3.1 || Unlink a learning plan from a template || Yes || Yes ||
|-
| core_competency || core_competency_update_competency || 3.1 || Update a competency || Yes || Yes ||
|-
| core_competency || core_competency_update_competency_framework || 3.1 || Update a competency framework || Yes || Yes ||
|-
| core_competency || core_competency_update_course_competency_settings || 3.1 || Update the course competency settings || Yes || Yes ||
|-
| core_competency || core_competency_update_plan || 3.1 || Update a learning plan || Yes || Yes ||
|-
| core_competency || core_competency_update_template || 3.1 || Update a template || Yes || Yes ||
|-
| core_competency || core_competency_user_competency_cancel_review_request || 3.1 || Cancel the review request of a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_user_competency_plan_viewed || 3.1 || Report the archive of user's competency as being viewed || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_user_competency_request_review || 3.1 || Request the review of a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_user_competency_start_review || 3.1 || Start the review of a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_user_competency_stop_review || 3.1 || Stop the review of a user's competency || Yes || Yes ||
|-
| core_competency || core_competency_user_competency_viewed || 3.1 || Report a user's competency as being viewed || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_user_competency_viewed_in_course || 3.1 || Report a user's competency as being viewed from a course || Yes || Yes || moodle_mobile_app
|-
| core_competency || core_competency_user_competency_viewed_in_plan || 3.1 || Report a user's competency as being viewed from a learning plan || Yes || Yes || moodle_mobile_app
|-
| core_completion || core_completion_get_activities_completion_status || 2.9 || Return the activities completion status for a user in a course. || No || Yes || moodle_mobile_app
|-
| core_completion || core_completion_get_course_completion_status || 2.9 || Returns course completion status. || No || Yes || moodle_mobile_app
|-
| core_completion || core_completion_mark_course_self_completed || 3.0 || Update the course completion status for the current user (if course self-completion is enabled). || No || Yes || moodle_mobile_app
|-
| core_completion || core_completion_override_activity_completion_status || 3.4 || Update completion status for a user in an activity by overriding it. || Yes || Yes ||
|-
| core_completion || core_completion_update_activity_completion_status_manually || 2.9 || Update completion status for the current user in an activity, only for activities with manual tracking. || No || Yes || moodle_mobile_app
|-
| core_contentbank\delete_content || core_contentbank_delete_content || 3.9 || Delete a content from the content bank. || Yes || Yes ||
|-
| core_contentbank\rename_content || core_contentbank_rename_content || 3.9 || Rename a content in the content bank. || Yes || Yes ||
|-
| core_contentbank\set_content_visibility || core_contentbank_set_content_visibility || 3.11 || Set the visibility of a content in the content bank. || Yes || Yes ||
|-
| core_course || core_course_add_content_item_to_user_favourites || 3.9 || Adds a content item (activity, resource or their subtypes) to the favourites for the user. || Yes || Yes ||
|-
| core_course || core_course_check_updates || 3.2 || Check if there is updates affecting the user for the given course and contexts. || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_create_categories || 2.3 || create categories || No || Yes ||
|-
| core_course || core_course_create_courses || 2.0 || Create new courses || No || Yes ||
|-
| core_course || core_course_delete_categories || 2.3 || delete categories || No || Yes ||
|-
| core_course || core_course_delete_courses || 2.3 || delete courses || No || Yes ||
|-
| core_course || core_course_delete_modules || 2.5 || Deletes all specified module instances || No || Yes ||
|-
| core_course || core_course_duplicate_course || 2.3 || duplicate a course || No || Yes ||
|-
| core_course || core_course_edit_module || 3.3 || Performs an action on course module (change visibility, duplicate, delete, etc.) || Yes || Yes ||
|-
| core_course || core_course_edit_section || 3.3 || Performs an action on course section (change visibility, set marker, delete) || Yes || Yes ||
|-
| core_course || core_course_get_activities_overview || 3.2 || Return activities overview for the given courses. || No || Yes ||
|-
| core_course || core_course_get_activity_chooser_footer || 3.9 || Fetch the data for the activity chooser footer. || Yes || Yes ||
|-
| core_course || core_course_get_categories || 2.3 || get categories || No || Yes || moodle_mobile_app
|-
| core_course || core_course_get_contents || 2.2 || get course content (modules + web service file urls) || No || Yes || moodle_mobile_app
|-
| core_course || core_course_get_course_content_items || 3.9 || Fetch all the content items (activities, resources and their subtypes) for the activity picker || Yes || Yes ||
|-
| core_course || core_course_get_course_module || 3.0 || Return information about a course module. || No || Yes || moodle_mobile_app
|-
| core_course || core_course_get_course_module_by_instance || 3.0 || Return information about a given module name and instance id. || No || Yes || moodle_mobile_app
|-
| core_course || core_course_get_courses || 2.0 || Return course details || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_get_courses_by_field || 3.2 || Get courses matching a specific field (id/s, shortname, idnumber, category) || No || Yes || moodle_mobile_app
|-
| core_course || core_course_get_enrolled_courses_by_timeline_classification || 3.6 || List of enrolled courses for the given timeline classification (past, inprogress, or future). || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_get_enrolled_users_by_cmid || 3.8 || List users by course module id & filter by group id. || Yes || Yes ||
|-
| core_course || core_course_get_module || 3.3 || Returns html with one activity module on course page || Yes || Yes ||
|-
| core_course || core_course_get_recent_courses || 3.6 || List of courses a user has accessed most recently. || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_get_updates_since || 3.3 || Check if there are updates affecting the user for the given course since the given time stamp. || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_get_user_administration_options || 3.2 || Return a list of administration options in a set of courses that are avaialable or not for the current user. || No || Yes || moodle_mobile_app
|-
| core_course || core_course_get_user_navigation_options || 3.2 || Return a list of navigation options in a set of courses that are avaialable or not for the current user. || No || Yes || moodle_mobile_app
|-
| core_course || core_course_import_course || 2.4 || Import course data from a course into another course. Does not include any user data. || No || Yes ||
|-
| core_course || core_course_remove_content_item_from_user_favourites || 3.9 || Removes a content item (activity, resource or their subtypes) from the favourites for the user. || Yes || Yes ||
|-
| core_course || core_course_search_courses || 3.0 || Search courses by (name, module, block, tag). || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_set_favourite_courses || 3.6 || Add a list of courses to the list of favourite courses. || Yes || Yes || moodle_mobile_app
|-
| core_course || core_course_toggle_activity_recommendation || 3.9 || Adds or removes an activity as a recommendation in the activity chooser. || Yes || Yes ||
|-
| core_course || core_course_update_categories || 2.3 || update categories || No || Yes ||
|-
| core_course || core_course_update_courses || 2.5 || Update courses. || No || Yes ||
|-
| core_course || core_course_view_course || 2.9 || Log that the course was viewed || No || Yes || moodle_mobile_app
|-
| core_customfield || core_customfield_create_category || 3.7 || Creates a new category || Yes || Yes ||
|-
| core_customfield || core_customfield_delete_category || 3.7 || Deletes a category || Yes || Yes ||
|-
| core_customfield || core_customfield_delete_field || 3.7 || Deletes an entry || Yes || Yes ||
|-
| core_customfield || core_customfield_move_category || 3.7 || Drag and drop categories || Yes || Yes ||
|-
| core_customfield || core_customfield_move_field || 3.7 || Drag and drop || Yes || Yes ||
|-
| core_customfield || core_customfield_reload_template || 3.7 || Reloads template || Yes || Yes ||
|-
| core_enrol || core_enrol_edit_user_enrolment || 3.4 || External function that updates a given user enrolment || Yes || Yes ||
|-
| core_enrol || core_enrol_get_course_enrolment_methods || 3.0 || Get the list of course enrolment methods || No || Yes || moodle_mobile_app
|-
| core_enrol || core_enrol_get_enrolled_users || 2.1 || Get enrolled users by course id || No || Yes || moodle_mobile_app
|-
| core_enrol || core_enrol_get_enrolled_users_with_capability || 2.4 || For each course and capability specified, return a list of the users that are enrolled in the course and have that capability || No || Yes ||
|-
| core_enrol || core_enrol_get_potential_users || 3.4 || Get the list of potential users to enrol || Yes || Yes ||
|-
| core_enrol || core_enrol_get_users_courses || 2.0 || get list of course ids that a user is enrolled in (if you are allowed to see that) || No || Yes || moodle_mobile_app
|-
| core_enrol || core_enrol_search_users || 3.8 || Search within the list of course participants || Yes || Yes || moodle_mobile_app
|-
| core_enrol || core_enrol_submit_user_enrolment_form || 3.7 || Submit form data for enrolment form || Yes || Yes ||
|-
| core_enrol || core_enrol_unenrol_user_enrolment || 3.4 || External function that unenrols a given user enrolment || Yes || Yes ||
|-
| core_fetch || core_fetch_notifications || 3.1 || Return a list of notifications for the current session || Yes || No ||
|-
| core_files || core_files_get_files || 2.0 || browse moodle files || No || Yes || moodle_mobile_app
|-
| core_files || core_files_upload || 2.2 || upload a file to moodle || No || Yes ||
|-
| core_files\delete\draft || core_files_delete_draft_files || 3.10 || Delete the indicated files (or directories) from a user draft file area. || No || No || moodle_mobile_app
|-
| core_files\get\unused_draft || core_files_get_unused_draft_itemid || 3.11 || Generate a new draft itemid for the current user. || No || No || moodle_mobile_app
|-
| core_filters || core_filters_get_available_in_context || 3.4 || Returns the filters available in the given contexts. || No || Yes || moodle_mobile_app
|-
| core_form || core_form_get_filetypes_browser_data || 3.4 || Provides data for the filetypes element browser. || Yes || No ||
|-
| core_form\dynamic_form || core_form_dynamic_form || 3.11 || Process submission of a dynamic (modal) form || Yes || Yes ||
|-
| core_get || core_get_component_strings || 2.4 || Return all raw strings (with {$a->xxx}) for a specific component - similar to core get_component_strings() call || Yes || No || moodle_mobile_app
|-
| core_get || core_get_fragment || 3.1 || Return a fragment for inclusion, such as a JavaScript page. || Yes || Yes ||
|-
| core_get || core_get_string || 2.4 || Return a translated string - similar to core get_string() call || Yes || No ||
|-
| core_get || core_get_strings || 2.4 || Return some translated strings - like several core get_string() calls || Yes || No ||
|-
| core_get || core_get_user_dates || 3.3 || Return formatted timestamps || Yes || Yes ||
|-
| core_grade || core_grade_update_grades || 2.7 || Update a grade item and associated student grades. || No || Yes ||
|-
| core_grades || core_grades_create_gradecategory || 3.10 || Create a grade category inside a course gradebook. || No || No ||
|-
| core_grades || core_grades_get_grades || 2.7 || Returns student course total grade and grades for activities. This function does not return category or manual items. This function is suitable for managers or teachers not students. || No || Yes ||
|-
| core_grades || core_grades_grader_gradingpanel_point_fetch || 3.8 || Fetch the data required to display the grader grading panel for simple grading, creating the grade item if required || Yes || Yes || moodle_mobile_app
|-
| core_grades || core_grades_grader_gradingpanel_point_store || 3.8 || Store the data required to display the grader grading panel for simple grading || Yes || Yes || moodle_mobile_app
|-
| core_grades || core_grades_grader_gradingpanel_scale_fetch || 3.8 || Fetch the data required to display the grader grading panel for scale-based grading, creating the grade item if required || Yes || Yes || moodle_mobile_app
|-
| core_grades || core_grades_grader_gradingpanel_scale_store || 3.8 || Store the data required to display the grader grading panel for scale-based grading || Yes || Yes || moodle_mobile_app
|-
| core_grades\create_gradecategories || core_grades_create_gradecategories || 3.11 || Create grade categories inside a course gradebook. || No || No ||
|-
| core_grading || core_grading_get_definitions || 2.6 || Returns grading definitions for the course module ids and areaname provided as parameters. An optionall activeonly parameter can be provided so that only the active grading method is returned. || No || Yes ||
|-
| core_grading || core_grading_get_gradingform_instances || 2.6 || Returns the instances and fillings for the requested definition id. An optional since parameter allows the number of records returned to be reduced so that only those with a timemodified value >= since are returned || No || Yes ||
|-
| core_grading || core_grading_save_definitions || 2.8 || Accepts an array of areas as a parameter. The areas contain grading definitions with criteria for inserting and updating || No || Yes ||
|-
| core_group || core_group_add_group_members || 2.0 || Adds group members || No || Yes ||
|-
| core_group || core_group_assign_grouping || 2.3 || assign groups from groupings || No || Yes ||
|-
| core_group || core_group_create_groupings || 2.3 || create groupings || No || Yes ||
|-
| core_group || core_group_create_groups || 2.0 || Creates new groups || No || Yes ||
|-
| core_group || core_group_delete_group_members || 2.0 || Deletes group members || No || Yes ||
|-
| core_group || core_group_delete_groupings || 2.3 || delete groupings || No || Yes ||
|-
| core_group || core_group_delete_groups || 2.0 || Deletes all specified groups || No || Yes ||
|-
| core_group || core_group_get_activity_allowed_groups || 3.0 || Gets a list of groups that the user is allowed to access within the specified activity. || No || Yes || moodle_mobile_app
|-
| core_group || core_group_get_activity_groupmode || 3.0 || Returns effective groupmode used in a given activity. || No || Yes || moodle_mobile_app
|-
| core_group || core_group_get_course_groupings || 2.3 || get all groupings in specified course || No || Yes || moodle_mobile_app
|-
| core_group || core_group_get_course_groups || 2.0 || Returns all groups in specified course || Yes || Yes || moodle_mobile_app
|-
| core_group || core_group_get_course_user_groups || 2.9 || Returns all groups in specified course for the specified user. || No || Yes || moodle_mobile_app
|-
| core_group || core_group_get_group_members || 2.0 || Returns group members || No || Yes ||
|-
| core_group || core_group_get_groupings || 2.3 || get groupings || No || Yes ||
|-
| core_group || core_group_get_groups || 2.0 || Returns group details. || No || Yes ||
|-
| core_group || core_group_unassign_grouping || 2.3 || unassign groups from groupings || No || Yes ||
|-
| core_group || core_group_update_groupings || 2.3 || update groupings || No || Yes ||
|-
| core_group || core_group_update_groups || 3.6 || Updates existing groups. || No || Yes ||
|-
| core_h5p || core_h5p_get_trusted_h5p_file || 3.8 || Get the H5P file cleaned for Mobile App. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_block_contacts || 2.5 || Block contacts || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_block_user || 3.6 || Blocks a user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_confirm_contact_request || 3.6 || Confirms a contact request || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_create_contact_request || 3.6 || Creates a contact request || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_create_contacts || 2.5 || Add contacts to the contact list || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_data_for_messagearea_contacts || 3.2 || Retrieve the template data for the contact list || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_data_for_messagearea_conversations || 3.2 || Retrieve the template data for the conversation list || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_data_for_messagearea_get_most_recent_message || 3.2 || Retrieve the template data for the most recent message || Yes || Yes ||
|-
| core_message || core_message_data_for_messagearea_get_profile || 3.2 || Retrieve the template data for the users\'s profile || Yes || Yes ||
|-
| core_message || core_message_data_for_messagearea_messages || 3.2 || Retrieve the template data for the messages || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_data_for_messagearea_search_messages || 3.2 || Retrieve the template data for searching for messages || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_data_for_messagearea_search_users || 3.2 || Retrieve the template data for searching for people || Yes || Yes ||
|-
| core_message || core_message_data_for_messagearea_search_users_in_course || 3.2 || Retrieve the template data for searching for people in a course || Yes || Yes ||
|-
| core_message || core_message_decline_contact_request || 3.6 || Declines a contact request || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_delete_contacts || 2.5 || Remove contacts from the contact list || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_delete_conversation || 3.2 || Deletes a conversation. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_delete_conversations_by_id || 3.6 || Deletes a list of conversations. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_delete_message || 3.1 || Deletes a message. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_delete_message_for_all_users || 3.7 || Deletes a message for all users. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_blocked_users || 2.9 || Retrieve a list of users blocked || No || Yes || moodle_mobile_app
|-
| core_message || core_message_get_contact_requests || 3.6 || Returns contact requests for a user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_contacts || 2.5 || Retrieve the contact list || No || Yes || moodle_mobile_app
|-
| core_message || core_message_get_conversation || 3.6 || Retrieve a conversation for a user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_conversation_between_users || 3.6 || Retrieve a conversation for a user between another user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_conversation_counts || 3.6 || Retrieve a list of conversation counts, indexed by type. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_conversation_members || 3.6 || Retrieve a list of members in a conversation || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_conversation_messages || 3.6 || Retrieve the conversation messages and relevant member information || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_conversations || 3.6 || Retrieve a list of conversations for a user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_member_info || 3.6 || Retrieve a user message profiles || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_message_processor || 3.2 || Get a message processor || Yes || Yes ||
|-
| core_message || core_message_get_messages || 2.8 || Retrieve a list of messages sent and received by a user (conversations, notifications or both) || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_received_contact_requests_count || 3.6 || Gets the number of received contact requests || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_self_conversation || 3.7 || Retrieve a self-conversation for a user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_unread_conversations_count || 3.2 || Retrieve the count of unread conversations for a given user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_user_contacts || 3.6 || Retrieve the contact list || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_user_message_preferences || 3.2 || Get the message preferences for a given user. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_get_user_notification_preferences || 3.2 || Get the notification preferences for a given user. || No || Yes || moodle_mobile_app
|-
| core_message || core_message_mark_all_conversation_messages_as_read || 3.6 || Mark all conversation messages as read for a given user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_mark_all_messages_as_read || 3.2 || Mark all messages as read for a given user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_mark_all_notifications_as_read || 3.2 || Mark all notifications as read for a given user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_mark_message_read || 2.9 || Mark a single message as read, trigger message_viewed event. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_mark_notification_read || 3.5 || Mark a single notification as read, trigger notification_viewed event. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_message_processor_config_form || 3.2 || Process the message processor config form || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_message_search_users || 3.6 || Retrieve the data for searching for people || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_mute_conversations || 3.7 || Mutes a list of conversations || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_search_contacts || 2.5 || Search for contacts || No || Yes || moodle_mobile_app
|-
| core_message || core_message_send_instant_messages || 2.1 || Send instant messages || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_send_messages_to_conversation || 3.6 || Send messages to an existing conversation between users || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_set_favourite_conversations || 3.6 || Mark a conversation or group of conversations as favourites/starred conversations. || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_unblock_contacts || 2.5 || Unblock contacts || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_unblock_user || 3.6 || Unblocks a user || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_unmute_conversations || 3.7 || Unmutes a list of conversations || Yes || Yes || moodle_mobile_app
|-
| core_message || core_message_unset_favourite_conversations || 3.6 || Unset a conversation or group of conversations as favourites/starred conversations. || Yes || Yes || moodle_mobile_app
|-
| core_notes || core_notes_create_notes || 2.1 || Create notes || Yes || Yes || moodle_mobile_app
|-
| core_notes || core_notes_delete_notes || 2.5 || Delete Notes || No || Yes || moodle_mobile_app
|-
| core_notes || core_notes_get_course_notes || 2.9 || Returns all notes in specified course (or site) for the specified user. || No || Yes || moodle_mobile_app
|-
| core_notes || core_notes_get_notes || 2.5 || Retrieve Notes || No || Yes ||
|-
| core_notes || core_notes_update_notes || 2.5 || Update Notes || No || Yes ||
|-
| core_notes || core_notes_view_notes || 2.9 || Simulates the web interface view of notes/index.php: trigger events. || No || Yes || moodle_mobile_app
|-
| core_output || core_output_load_fontawesome_icon_map || 3.3 || Load the mapping of names to icons || Yes || No ||
|-
| core_output || core_output_load_template || 3.0 || Load a template for a renderable || Yes || No ||
|-
| core_payment\get_available_gateways || core_payment_get_available_gateways || 3.10 || Get the list of payment gateways that support the given component/area || Yes || Yes ||
|-
| core_question || core_question_get_random_question_summaries || 3.5 || Get the random question set for a criteria || Yes || Yes ||
|-
| core_question || core_question_submit_tags_form || 3.5 || Update the question tags. || Yes || Yes ||
|-
| core_question || core_question_update_flag || 3.1 || Update the flag state of a question attempt. || No || Yes || moodle_mobile_app
|-
| core_rating || core_rating_add_rating || 3.2 || Rates an item. || No || Yes || moodle_mobile_app
|-
| core_rating || core_rating_get_item_ratings || 2.9 || Retrieve all the ratings for an item. || No || Yes || moodle_mobile_app
|-
| core_role || core_role_assign_roles || 2.0 || Manual role assignments || No || Yes ||
|-
| core_role || core_role_unassign_roles || 2.0 || Manual role unassignments || No || Yes ||
|-
| core_search || core_search_get_relevant_users || 3.5 || Gets relevant users for a search request. || Yes || Yes ||
|-
| core_session || core_session_time_remaining || 3.8 || Count the seconds remaining in this session || Yes || Yes ||
|-
| core_session || core_session_touch || 3.8 || Keep the users session alive || Yes || Yes ||
|-
| core_table\dynamic\get || core_table_get_dynamic_table_content || 3.9 || Get the dynamic table content raw html || Yes || Yes || moodle_mobile_app
|-
| core_tag || core_tag_get_tag_areas || 3.7 || Retrieves existing tag areas. || No || Yes || moodle_mobile_app
|-
| core_tag || core_tag_get_tag_cloud || 3.7 || Retrieves a tag cloud for the given collection and/or query search. || No || Yes || moodle_mobile_app
|-
| core_tag || core_tag_get_tag_collections || 3.7 || Retrieves existing tag collections. || No || Yes || moodle_mobile_app
|-
| core_tag || core_tag_get_tagindex || 3.1 || Gets tag index page for one tag and one tag area || Yes || Yes || moodle_mobile_app
|-
| core_tag || core_tag_get_tagindex_per_area || 3.7 || Gets tag index page per different areas. || No || Yes || moodle_mobile_app
|-
| core_tag || core_tag_get_tags || 3.0 || Gets tags by their ids || Yes || Yes ||
|-
| core_tag || core_tag_update_tags || 3.0 || Updates tags || Yes || Yes ||
|-
| core_update || core_update_inplace_editable || 3.1 || Generic service to update title || Yes || Yes ||
|-
| core_user || core_user_add_user_device || 2.6 || Store mobile user devices information for PUSH Notifications. || No || Yes || moodle_mobile_app
|-
| core_user || core_user_add_user_private_files || 2.6 || Copy files from a draft area to users private files area. || No || Yes || moodle_mobile_app
|-
| core_user || core_user_agree_site_policy || 3.2 || Agree the site policy for the current user. || No || Yes || moodle_mobile_app
|-
| core_user || core_user_create_users || 2.0 || Create users - admin function || No || Yes ||
|-
| core_user || core_user_delete_users || 2.0 || Delete users - admin function || No || Yes ||
|-
| core_user || core_user_get_course_user_profiles || 2.1 || Get course user profiles by id || No || Yes || moodle_mobile_app
|-
| core_user || core_user_get_private_files_info || 3.4 || Returns general information about files in the user private files area. || No || Yes || moodle_mobile_app
|-
| core_user || core_user_get_user_preferences || 3.2 || Return user preferences. || Yes || Yes || moodle_mobile_app
|-
| core_user || core_user_get_users || 2.5 || Search users. - If you want to get multiple users for one specific field, use core_user_get_users_by_field(), it's designed for this purpose and it should be faster. || No || Yes ||
|-
| core_user || core_user_get_users_by_field || 2.5 || Retrieve users information for a specified unique field - If you want to do a user search, use core_user_get_users() || Yes || Yes || moodle_mobile_app
|-
| core_user || core_user_get_users_by_id || 2.0 || Get users by id || No || Yes ||
|-
| core_user || core_user_remove_user_device || 2.9 || Remove a user device from the Moodle database. || No || Yes || moodle_mobile_app
|-
| core_user || core_user_set_user_preferences || 3.2 || Set user preferences. || Yes || Yes || moodle_mobile_app
|-
| core_user || core_user_update_picture || 3.2 || Update or delete the user picture in the site || No || Yes || moodle_mobile_app
|-
| core_user || core_user_update_user_preferences || 3.2 || Update a user\'s preferences || Yes || Yes || moodle_mobile_app
|-
| core_user || core_user_update_users || 2.0 || Update users || Yes || Yes ||
|-
| core_user || core_user_view_user_list || 2.9 || Simulates the web-interface view of user/index.php (triggering events). || No || Yes || moodle_mobile_app
|-
| core_user || core_user_view_user_profile || 2.9 || Simulates the web-interface view of user/view.php and user/profile.php (triggering events). || No || Yes || moodle_mobile_app
|-
| core_webservice || core_webservice_get_site_info || 2.1 || Return some site info / user info / list web service functions || No || Yes || moodle_mobile_app
|-
| core_xapi\post_statement || core_xapi_statement_post || 3.9 || Post an xAPI statement. || Yes || Yes || moodle_mobile_app
|-
| enrol_guest || enrol_guest_get_instance_info || 3.1 || Return guest enrolment instance information. || No || Yes || moodle_mobile_app
|-
| enrol_manual || enrol_manual_enrol_users || 2.0 || Manual enrol users || No || Yes ||
|-
| enrol_manual || enrol_manual_unenrol_users || 3.0 || Manual unenrol users || No || Yes ||
|-
| enrol_self || enrol_self_enrol_user || 3.0 || Self enrol the current user in the given course. || No || Yes || moodle_mobile_app
|-
| enrol_self || enrol_self_get_instance_info || 3.0 || self enrolment instance information. || No || Yes || moodle_mobile_app
|-
| gradereport_overview || gradereport_overview_get_course_grades || 3.2 || Get the given user courses final grades || No || Yes || moodle_mobile_app
|-
| gradereport_overview || gradereport_overview_view_grade_report || 3.2 || Trigger the report view event || No || Yes || moodle_mobile_app
|-
| gradereport_user || gradereport_user_get_grade_items || 3.2 || Returns the complete list of grade items for users in a course || No || Yes || moodle_mobile_app
|-
| gradereport_user || gradereport_user_get_grades_table || 2.9 || Get the user/s report grades table for a course || No || Yes || moodle_mobile_app
|-
| gradereport_user || gradereport_user_view_grade_report || 2.9 || Trigger the grade_report_viewed event when a user view his grade report (this web service will be initially used by the mobile app so information can be logged in the Moodle side when a user see the same page in the app). || No || Yes || moodle_mobile_app
|-
| gradingform_guide || gradingform_guide_grader_gradingpanel_fetch || 3.8 || Fetch the data required to display the grader grading panel, creating the grade item if required || Yes || Yes ||
|-
| gradingform_guide || gradingform_guide_grader_gradingpanel_store || 3.8 || Store the grading data for a user from the grader grading panel. || Yes || Yes ||
|-
| gradingform_rubric || gradingform_rubric_grader_gradingpanel_fetch || 3.8 || Fetch the data required to display the grader grading panel, creating the grade item if required || Yes || Yes ||
|-
| gradingform_rubric || gradingform_rubric_grader_gradingpanel_store || 3.8 || Store the grading data for a user from the grader grading panel. || Yes || Yes ||
|-
| local_mobile || local_mobile_get_plugin_settings || 3.4 || Retrieve the plugin settings. || No || Yes ||
|-
| message_airnotifier || message_airnotifier_are_notification_preferences_configured || 2.7 || Check if the users have notification preferences configured yet || No || Yes || moodle_mobile_app
|-
| message_airnotifier || message_airnotifier_enable_device || 3.2 || Enables or disables a registered user device so it can receive Push notifications || No || Yes || moodle_mobile_app
|-
| message_airnotifier || message_airnotifier_get_user_devices || 3.2 || Return the list of mobile devices that are registered in Moodle for the given user || No || Yes || moodle_mobile_app
|-
| message_airnotifier || message_airnotifier_is_system_configured || 2.7 || Check whether the airnotifier settings have been configured || No || Yes || moodle_mobile_app
|-
| message_popup || message_popup_get_popup_notifications || 3.2 || Retrieve a list of popup notifications for a user || Yes || Yes || moodle_mobile_app
|-
| message_popup || message_popup_get_unread_popup_notification_count || 3.2 || Retrieve the count of unread popup notifications for a given user || Yes || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_copy_previous_attempt || 2.6 || Copy a students previous attempt to a new attempt. || No || Yes ||
|-
| mod_assign || mod_assign_get_assignments || 2.4 || Returns the courses and assignments for the users capability || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_get_grades || 2.4 || Returns grades from the assignment || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_get_participant || 3.1 || Get a participant for an assignment, with some summary info about their submissions. || Yes || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_get_submission_status || 3.1 || Returns information about an assignment submission status for a given user. || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_get_submissions || 2.5 || Returns the submissions for assignments || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_get_user_flags || 2.6 || Returns the user_flags for assignments || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_get_user_mappings || 2.6 || Returns the user_mappings for assignments || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_list_participants || 3.1 || List the participants for a single assignment, with some summary info about their submissions. || Yes || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_lock_submissions || 2.6 || Prevent students from making changes to a list of submissions || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_reveal_identities || 2.6 || Reveal the identities for a blind marking assignment || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_revert_submissions_to_draft || 2.6 || Reverts the list of submissions to draft status || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_save_grade || 2.6 || Save a grade update for a single student. || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_save_grades || 2.7 || Save grade updates for one or more students. || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_save_submission || 2.6 || Update the current students submission || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_save_user_extensions || 2.6 || Save a list of assignment extensions || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_set_user_flags || 2.6 || Sets the specified user_flags for an assignment || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_submit_for_grading || 2.6 || Submit the current students assignment for grading || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_submit_grading_form || 3.1 || Submit the grading form data via ajax || Yes || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_unlock_submissions || 2.6 || Allow students to make changes to a list of submissions || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_view_assign || 3.2 || Update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_view_grading_table || 3.0 || Trigger the grading_table_viewed event. || No || Yes || moodle_mobile_app
|-
| mod_assign || mod_assign_view_submission_status || 3.1 || Trigger the submission status viewed event. || No || Yes || moodle_mobile_app
|-
| mod_book || mod_book_get_books_by_courses || 3.0 || Returns a list of book instances in a provided set of courses. || No || Yes || moodle_mobile_app
|-
| mod_book || mod_book_view_book || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_get_chat_latest_messages || 3.0 || Get the latest messages from the given chat sessio. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_get_chat_users || 3.0 || Get the list of users in the given chat session. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_get_chats_by_courses || 3.0 || Returns a list of chat instances in a provided set of courses. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_get_session_messages || 3.5 || Retrieves messages of the given chat session. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_get_sessions || 3.5 || Retrieves chat sessions for a given chat. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_login_user || 3.0 || Log a user into a chat room in the given chat. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_send_chat_message || 3.0 || Send a message on the given chat session. || No || Yes || moodle_mobile_app
|-
| mod_chat || mod_chat_view_chat || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_choice || mod_choice_delete_choice_responses || 3.0 || Delete the given submitted responses in a choice. || No || Yes || moodle_mobile_app
|-
| mod_choice || mod_choice_get_choice_options || 3.0 || Retrieve options for a specific choice. || No || Yes || moodle_mobile_app
|-
| mod_choice || mod_choice_get_choice_results || 3.0 || Retrieve users results for a given choice. || No || Yes || moodle_mobile_app
|-
| mod_choice || mod_choice_get_choices_by_courses || 3.0 || Returns a list of choice instances in a provided set of courses. || No || Yes || moodle_mobile_app
|-
| mod_choice || mod_choice_submit_choice_response || 3.0 || Submit responses to a specific choice item. || No || Yes || moodle_mobile_app
|-
| mod_choice || mod_choice_view_choice || 3.0 || Trigger the course module viewed event and update the module completion status.. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_add_entry || 3.3 || Adds a new entry. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_approve_entry || 3.3 || Approves or unapproves an entry. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_delete_entry || 3.3 || Deletes an entry. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_get_data_access_information || 3.3 || Return access information for a given database. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_get_databases_by_courses || 2.9 || Returns a list of database instances in a provided set of courses, if no courses are provided then all the database instances the user has access to will be returned. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_get_entries || 3.3 || Return the complete list of entries of the given database. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_get_entry || 3.3 || Return one entry record from the database, including contents optionally. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_get_fields || 3.3 || Return the list of configured fields for the given database. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_search_entries || 3.3 || Search for entries in the given database. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_update_entry || 3.3 || Updates an existing entry. || No || Yes || moodle_mobile_app
|-
| mod_data || mod_data_view_database || 3.3 || Simulate the view.php web interface data: trigger events, completion, etc... || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_analysis || 3.3 || Retrieves the feedback analysis. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_current_completed_tmp || 3.3 || Returns the temporary completion record for the current user. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_feedback_access_information || 3.3 || Return access information for a given feedback. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_feedbacks_by_courses || 3.3 || Returns a list of feedbacks in a provided list of courses, if no list is provided all feedbacks that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_finished_responses || 3.3 || Retrieves responses from the last finished attempt. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_items || 3.3 || Returns the items (questions) in the given feedback. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_last_completed || 3.3 || Retrieves the last completion record for the current user. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_non_respondents || 3.3 || Retrieves a list of students who didn\'t submit the feedback. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_page_items || 3.3 || Get a single feedback page items. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_responses_analysis || 3.3 || Return the feedback user responses analysis. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_get_unfinished_responses || 3.3 || Retrieves responses from the current unfinished attempt. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_launch_feedback || 3.3 || Starts or continues a feedback submission. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_process_page || 3.3 || Process a jump between pages. || No || Yes || moodle_mobile_app
|-
| mod_feedback || mod_feedback_view_feedback || 3.3 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_folder || mod_folder_get_folders_by_courses || 3.3 || Returns a list of folders in a provided list of courses, if no list is provided all folders that the user can view will be returned. Please note that this WS is not returning the folder contents. || No || Yes || moodle_mobile_app
|-
| mod_folder || mod_folder_view_folder || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_add_discussion || 3.0 || Add a new discussion into an existing forum. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_add_discussion_post || 3.0 || Create new posts into an existing discussion. || Yes || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_can_add_discussion || 3.1 || Check if the current user can add discussions in the given forum (and optionally for the given group). || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_delete_post || 3.8 || Deletes a post or a discussion completely when the post is the discussion topic. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_discussion_post || 3.8 || Get a particular discussion post. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_discussion_posts || 3.7 || Returns a list of forum posts for a discussion. || Yes || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_discussion_posts_by_userid || 3.8 || Returns a list of forum posts for a discussion for a user. || Yes || Yes ||
|-
| mod_forum || mod_forum_get_forum_access_information || 3.7 || Return capabilities information for a given forum. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_forum_discussion_posts || 2.7 || Returns a list of forum posts for a discussion. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_forum_discussions || 3.7 || Returns a list of forum discussions optionally sorted and paginated. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_forum_discussions_paginated || 2.8 || Returns a list of forum discussions optionally sorted and paginated. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_get_forums_by_courses || 2.5 || Returns a list of forum instances in a provided set of courses, if no courses are provided then all the forum instances the user has access to will be returned. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_prepare_draft_area_for_post || 3.8 || Prepares a draft area for editing a post. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_set_lock_state || 3.7 || Set the lock state for the discussion || Yes || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_set_pin_state || 3.7 || Set the pin state || Yes || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_set_subscription_state || 3.7 || Set the subscription state || Yes || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_toggle_favourite_state || 3.7 || Toggle the favourite state || Yes || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_update_discussion_post || 3.8 || Updates a post or a discussion topic post. || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_view_forum || 2.9 || Trigger the course_module_viewed event when a user view a forum (this web service will be initially used by the mobile app so information can be logged in the Moodle side when a user see the same page in the app). || No || Yes || moodle_mobile_app
|-
| mod_forum || mod_forum_view_forum_discussion || 2.9 || Trigger the discussion_viewed event when a user view a forum discussion (this web service will be initially used by the mobile app so information can be logged in the Moodle side when a user see the same page in the app). || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_add_entry || 3.2 || Add a new entry to a given glossary || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_authors || 3.1 || Get the authors in a glossary || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_categories || 3.1 || Get a glossary's categories || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_author || 3.1 || Get entries using author filtering || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_author_id || 3.1 || Get entries using author ID filtering || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_category || 3.1 || Get entries using category filtering || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_date || 3.1 || Get entries using date filtering || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_letter || 3.1 || Get entries using letter filtering || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_search || 3.1 || Get entries matching a search query || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_by_term || 3.1 || Get entries using term filtering || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entries_to_approve || 3.1 || Get entries to be approved || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_entry_by_id || 3.1 || Get an entry by ID || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_get_glossaries_by_courses || 3.1 || Get the glossaries in courses || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_view_entry || 3.1 || Notify that a glossary entry was viewed || No || Yes || moodle_mobile_app
|-
| mod_glossary || mod_glossary_view_glossary || 3.1 || Notify that a glossary was viewed || No || Yes || moodle_mobile_app
|-
| mod_imscp || mod_imscp_get_imscps_by_courses || 3.0 || Returns a list of imscp instances in a provided set of courses. || No || Yes || moodle_mobile_app
|-
| mod_imscp || mod_imscp_view_imscp || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_label || mod_label_get_labels_by_courses || 3.3 || Returns a list of labels in a provided list of courses, if no list is provided all labels that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_finish_attempt || 3.3 || Finishes the current attempt. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_attempts_overview || 3.3 || Get a list of all the attempts made by users in a lesson. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_content_pages_viewed || 3.3 || Return the list of content pages viewed by a user during a lesson attempt. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_lesson || 3.3 || Return information of a given lesson. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_lesson_access_information || 3.3 || Return access information for a given lesson. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_lessons_by_courses || 3.3 || Returns a list of lessons in a provided list of courses, if no list is provided all lessons that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_page_data || 3.3 || Return information of a given page, including its contents. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_pages || 3.3 || Return the list of pages in a lesson (based on the user permissions). || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_pages_possible_jumps || 3.3 || Return all the possible jumps for the pages in a given lesson. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_questions_attempts || 3.3 || Return the list of questions attempts in a given lesson. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_user_attempt || 3.3 || Return information about the given user attempt (including answers). || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_user_attempt_grade || 3.3 || Return grade information in the attempt for a given user. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_user_grade || 3.3 || Return the final grade in the lesson for the given user. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_get_user_timers || 3.3 || Return the timers in the current lesson for the given user. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_launch_attempt || 3.3 || Starts a new attempt or continues an existing one. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_process_page || 3.3 || Processes page responses. || No || Yes || moodle_mobile_app
|-
| mod_lesson || mod_lesson_view_lesson || 3.3 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_lti || mod_lti_create_tool_proxy || 3.1 || Create a tool proxy || Yes || Yes ||
|-
| mod_lti || mod_lti_create_tool_type || 3.1 || Create a tool type || Yes || Yes ||
|-
| mod_lti || mod_lti_delete_tool_proxy || 3.1 || Delete a tool proxy || Yes || Yes ||
|-
| mod_lti || mod_lti_delete_tool_type || 3.1 || Delete a tool type || Yes || Yes ||
|-
| mod_lti || mod_lti_get_ltis_by_courses || 3.0 || Returns a list of lti instances in a provided set of courses. || No || Yes || moodle_mobile_app
|-
| mod_lti || mod_lti_get_tool_launch_data || 3.0 || Return the launch data for a given external tool. || No || Yes || moodle_mobile_app
|-
| mod_lti || mod_lti_get_tool_proxies || 3.1 || Get a list of the tool proxies || Yes || Yes ||
|-
| mod_lti || mod_lti_get_tool_proxy_registration_request || 3.1 || Get a registration request for a tool proxy || Yes || Yes ||
|-
| mod_lti || mod_lti_get_tool_types || 3.1 || Get a list of the tool types || Yes || Yes ||
|-
| mod_lti || mod_lti_is_cartridge || 3.1 || Determine if the given url is for a cartridge || Yes || Yes ||
|-
| mod_lti || mod_lti_update_tool_type || 3.1 || Update a tool type || Yes || Yes ||
|-
| mod_lti || mod_lti_view_lti || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_page || mod_page_get_pages_by_courses || 3.3 || Returns a list of pages in a provided list of courses, if no list is provided all pages that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_page || mod_page_view_page || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_attempt_access_information || 3.1 || Return access information for a given attempt in a quiz. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_attempt_data || 3.1 || Returns information for the given attempt page for a quiz attempt in progress. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_attempt_review || 3.1 || Returns review information for the given finished attempt, can be used by users or teachers. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_attempt_summary || 3.1 || Returns a summary of a quiz attempt before it is submitted. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_combined_review_options || 3.1 || Combines the review options from a number of different quiz attempts. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_quiz_access_information || 3.1 || Return access information for a given quiz. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_quiz_feedback_for_grade || 3.1 || Get the feedback text that should be show to a student who got the given grade in the given quiz. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_quiz_required_qtypes || 3.1 || Return the potential question types that would be required for a given quiz. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_quizzes_by_courses || 3.1 || Returns a list of quizzes in a provided list of courses, if no list is provided all quizzes that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_user_attempts || 3.1 || Return a list of attempts for the given quiz and user. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_get_user_best_grade || 3.1 || Get the best current grade for the given user on a quiz. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_process_attempt || 3.1 || Process responses during an attempt at a quiz and also deals with attempts finishing. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_save_attempt || 3.1 || Processes save requests during the quiz.This function is intended for the quiz auto-save feature. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_start_attempt || 3.1 || Starts a new attempt at a quiz. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_view_attempt || 3.1 || Trigger the attempt viewed event. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_view_attempt_review || 3.1 || Trigger the attempt reviewed event. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_view_attempt_summary || 3.1 || Trigger the attempt summary viewed event. || No || Yes || moodle_mobile_app
|-
| mod_quiz || mod_quiz_view_quiz || 3.1 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_resource || mod_resource_get_resources_by_courses || 3.3 || Returns a list of files in a provided list of courses, if no list is provided all files that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_resource || mod_resource_view_resource || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_get_scorm_access_information || 3.7 || Return capabilities information for a given scorm. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_get_scorm_attempt_count || 3.0 || Return the number of attempts done by a user in the given SCORM. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_get_scorm_sco_tracks || 3.0 || Retrieves SCO tracking data for the given user id and attempt number. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_get_scorm_scoes || 3.0 || Returns a list containing all the scoes data related to the given scorm id. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_get_scorm_user_data || 3.0 || Retrieves user tracking and SCO data and default SCORM values. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_get_scorms_by_courses || 3.0 || Returns a list of scorm instances in a provided set of courses. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_insert_scorm_tracks || 3.0 || Saves a scorm tracking record. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_launch_sco || 3.1 || Trigger the SCO launched event. || No || Yes || moodle_mobile_app
|-
| mod_scorm || mod_scorm_view_scorm || 3.0 || Trigger the course module viewed event and update the module completion status.. || No || Yes || moodle_mobile_app
|-
| mod_survey || mod_survey_get_questions || 3.0 || Get the complete list of questions for the survey, including subquestions. || No || Yes || moodle_mobile_app
|-
| mod_survey || mod_survey_get_surveys_by_courses || 3.0 || Returns a list of survey instances in a provided set of courses, if no courses are provided then all the survey instances the user has access to will be returned. || No || Yes || moodle_mobile_app
|-
| mod_survey || mod_survey_submit_answers || 3.0 || Submit the answers for a given survey. || No || Yes || moodle_mobile_app
|-
| mod_survey || mod_survey_view_survey || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_url || mod_url_get_urls_by_courses || 3.3 || Returns a list of urls in a provided list of courses, if no list is provided all urls that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_url || mod_url_view_url || 3.0 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_edit_page || 3.1 || Save the contents of a page. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_get_page_contents || 3.1 || Returns the contents of a page. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_get_page_for_editing || 3.1 || Locks and retrieves info of page-section to be edited. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_get_subwiki_files || 3.1 || Returns the list of files for a specific subwiki. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_get_subwiki_pages || 3.1 || Returns the list of pages for a specific subwiki. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_get_subwikis || 3.1 || Returns the list of subwikis the user can see in a specific wiki. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_get_wikis_by_courses || 3.1 || Returns a list of wiki instances in a provided set of courses, if no courses are provided then all the wiki instances the user has access to will be returned. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_new_page || 3.1 || Create a new page in a subwiki. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_view_page || 3.1 || Trigger the page viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_wiki || mod_wiki_view_wiki || 3.1 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_add_submission || 3.4 || Add a new submission to a given workshop. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_delete_submission || 3.4 || Deletes the given submission. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_evaluate_assessment || 3.4 || Evaluates an assessment (used by teachers for provide feedback to the reviewer). || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_evaluate_submission || 3.4 || Evaluates a submission (used by teachers for provide feedback or override the submission grade). || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_assessment || 3.4 || Retrieves the given assessment. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_assessment_form_definition || 3.4 || Retrieves the assessment form definition. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_grades || 3.4 || Returns the assessment and submission grade for the given user. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_grades_report || 3.4 || Retrieves the assessment grades report. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_reviewer_assessments || 3.4 || Retrieves all the assessments reviewed by the given user. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_submission || 3.4 || Retrieves the given submission. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_submission_assessments || 3.4 || Retrieves all the assessments of the given submission. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_submissions || 3.4 || Retrieves all the workshop submissions or the one done by the given user (except example submissions). || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_user_plan || 3.4 || Return the planner information for the given user. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_workshop_access_information || 3.4 || Return access information for a given workshop. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_get_workshops_by_courses || 3.4 || Returns a list of workshops in a provided list of courses, if no list is provided all workshops that the user can view will be returned. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_update_assessment || 3.4 || Add information to an allocated assessment. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_update_submission || 3.4 || Update the given submission. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_view_submission || 3.4 || Trigger the submission viewed event. || No || Yes || moodle_mobile_app
|-
| mod_workshop || mod_workshop_view_workshop || 3.4 || Trigger the course module viewed event and update the module completion status. || No || Yes || moodle_mobile_app
|-
| report_competency || report_competency_data_for_report || 3.1 || Load the data for the competency report in a course. || Yes || Yes ||
|-
| report_insights || report_insights_action_executed || 3.8 || Stores an action executed over a group of predictions. || Yes || Yes || moodle_mobile_app
|-
| report_insights || report_insights_set_fixed_prediction || 3.4 || Flags a prediction as fixed. || Yes || Yes || moodle_mobile_app
|-
| report_insights || report_insights_set_notuseful_prediction || 3.4 || Flags the prediction as not useful. || Yes || Yes || moodle_mobile_app
|-
| tool_analytics || tool_analytics_potential_contexts || 3.8 || Retrieve the list of potential contexts for a model. || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_competencies_manage_page || 3.1 || Load the data for the competencies manage page template || Yes || Yes ||
|-
| tool_lp || tool_lp_data_for_competency_frameworks_manage_page || 3.1 || Load the data for the competency frameworks manage page template || Yes || Yes ||
|-
| tool_lp || tool_lp_data_for_competency_summary || 3.1 || Load competency data for summary template. || Yes || Yes ||
|-
| tool_lp || tool_lp_data_for_course_competencies_page || 3.1 || Load the data for the course competencies page template. || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_plan_page || 3.1 || Load the data for the plan page template. || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_plans_page || 3.1 || Load the data for the plans page template || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_related_competencies_section || 3.1 || Load the data for the related competencies template. || Yes || Yes ||
|-
| tool_lp || tool_lp_data_for_template_competencies_page || 3.1 || Load the data for the template competencies page template. || Yes || Yes ||
|-
| tool_lp || tool_lp_data_for_templates_manage_page || 3.1 || Load the data for the learning plan templates manage page template || Yes || Yes ||
|-
| tool_lp || tool_lp_data_for_user_competency_summary || 3.1 || Load a summary of a user competency. || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_user_competency_summary_in_course || 3.1 || Load a summary of a user competency. || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_user_competency_summary_in_plan || 3.1 || Load a summary of a user competency. || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_user_evidence_list_page || 3.1 || Load the data for the user evidence list page template || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_data_for_user_evidence_page || 3.1 || Load the data for the user evidence page template || Yes || Yes || moodle_mobile_app
|-
| tool_lp || tool_lp_list_courses_using_competency || 3.1 || List the courses using a competency || Yes || Yes ||
|-
| tool_lp || tool_lp_search_cohorts || 3.1 || Search for cohorts. || Yes || Yes ||
|-
| tool_lp || tool_lp_search_users || 3.1 || Search for users. || Yes || Yes ||
|-
| tool_mobile || tool_mobile_call_external_functions || 3.7 || Call multiple external functions and return all responses. || No || Yes || moodle_mobile_app
|-
| tool_mobile || tool_mobile_get_autologin_key || 3.2 || Creates an auto-login key for the current user. Is created only in https sites and is restricted by time and ip address. || No || Yes || moodle_mobile_app
|-
| tool_mobile || tool_mobile_get_config || 3.2 || Returns a list of the site configurations, filtering by section. || No || Yes || moodle_mobile_app
|-
| tool_mobile || tool_mobile_get_content || 3.5 || Returns a piece of content to be displayed in the Mobile app. || No || Yes || moodle_mobile_app
|-
| tool_mobile || tool_mobile_get_plugins_supporting_mobile || 3.1 || Returns a list of Moodle plugins supporting the mobile app. || Yes || No || moodle_mobile_app
|-
| tool_mobile || tool_mobile_get_public_config || 3.2 || Returns a list of the site public settings, those not requiring authentication. || Yes || No || moodle_mobile_app
|-
| tool_templatelibrary || tool_templatelibrary_list_templates || 3.0 || List/search templates by component. || Yes || No ||
|-
| tool_templatelibrary || tool_templatelibrary_load_canonical_template || 3.0 || Load a canonical template by name (not the theme overidden one). || Yes || No ||
|-
| tool_usertours || tool_usertours_complete_tour || 3.2 || Mark the specified tour as completed for the current user || Yes || Yes ||
|-
| tool_usertours || tool_usertours_fetch_and_start_tour || 3.2 || Fetch the specified tour || Yes || Yes ||
|-
| tool_usertours || tool_usertours_reset_tour || 3.2 || Remove the specified tour || Yes || Yes ||
|-
| tool_usertours || tool_usertours_step_shown || 3.2 || Mark the specified step as completed for the current user || Yes || Yes ||
|-
| tool_xmldb || tool_xmldb_invoke_move_action || 3.6 || moves element up/down || Yes || Yes ||
|}

This is the list of the integrated core functions. To see the roadmap, see to the tracker issue in the section bellow.

New Web Services entries are automatically generated for each new major version via this script: https://github.com/moodlehq/moodlemobile-scripts/blob/master/ws-documenter.php
<F2>

=== API Roadmap===
Tracker issue: MDL-29934

= See also =
* [[Web services API Changes]]
* [[How to contribute a web service function to core]]
* [[Web services|Web services developer documentation]]
* [[:en:Web services|Web services user documentation]]

[[Category:Web Services]]
[[Category:API]]

Core plugins review for Moodle 4.0

2022-10-21T21:28:50Z

Stronk7: just adding a few details in case somebody searches the docs looking for plugin removal information.

{{Infobox Project
|name = Core plugins review
|state = Completed
|tracker = MDL-72046 (epic)
|discussion = [https://moodle.org/mod/forum/discuss.php?d=426053 Moodle core plugins review]
|assignee = Sara Arjona
}}
{{Template:Moodle 4.0}}
==Introduction==
This project is about reviewing the plugins in core Moodle LMS with the aim of removing any which are no longer or hardly used, and if appropriate, adding them to the Moodle plugins directory.
==Plugins to be deleted from core==
The following plugins will be deleted from core but not put in the plugins directory because the technology is discontinued.
* WebCT question import/export format (qformat_webct)
* Examview question import/export format (qformat_examview)
* Flash animation media player (media_swf)
* VideoJS Flash plugin
* Picasa repository (repository_picasa)
* Picasa portfolio (portfolio_picasa)
* Microsoft OneDrive (legacy) (repository_skydrive)
==Plugins to be removed from core and added to the plugins directory==
Plugins which have been removed from core and added to the plugins directory will initially be listed with Moodle HQ as maintainer while we seek new maintainers via the [[Plugins adoption programme]].
* Word censorship filter (filter_censor)
* Health center admin tool (tool_health)
* Jabber notification (message_jabber)
* Quiz results block (block_quiz_results)
* Box repository (repository_boxnet)
* Box portfolio (portfolio_boxnet)
Note the plugins can be added to the Plugins directory only once the target version 4.0 is registered there, which happens on beta release.

==Plugins we are thinking about removing from core in the future and adding to the plugins directory==
We still need to decide which of the following plugins should be removed from core and added to the plugins directory. It will be done in MDL-73136 (epic). Please let us know your thoughts by posting in the discussion on moodle.org [https://moodle.org/mod/forum/discuss.php?d=426053 Moodle core plugins review]. We will collate all your feedback and review what to do with each plugin.
* Algebra notation filter (filter_algebra)
* Assignment 2.2 module (mod_assignment): MDL-72350
* Equella repository (repository_equella)
* Flickr block (block_tag_flickr): MDL-72614
* Flickr portfolio (portfolio_flickr): MDL-72614
* Flickr repository (repository_flickr): MDL-72614
* Flickr public repository (repository_flickr_public): MDL-72614
* HTML tidy filter (filter_tidy)
* Legacy course files repository (repository_coursefiles)
* Mahara ePortfolio (portfolio_mahara)
* Merlot.org repository (repository_merlot)
* Survey activity (mod_survey)
* URL downloader repository (repository_url)
== How will these plugins be removed from core? ==
* The plugin folder (for instance, question/format/webct/ for qformat_webct), will be completely removed from Moodle core. IMPORTANT: if you want to keep any of the plugins removed from core in your Moodle site, you will need to download and copy the plugin folder to the right place BEFORE running the upgrading process.
* Each plugin will be removed from the standard_plugins_list() method and added to the is_deleted_standard_plugin() method (both placed in lib/classes/plugin_manager.php).
[[File:jabber tobedeleted.png|center|thumb|The plugins will be marked as "To be deleted" if their code is not placed again in the Moodle folder.]]
* The upgrading steps will be added to lib/db/upgrade.php, to remove, when it applies, specific:
** DB tables (drop table statements).
** settings, using unset_all_config_for_plugin().
** capabilities, using capabilities_cleanup().
** ...

The plugins data will be removed only if the plugins files are not present anymore in the code. So, if a site wants to keep any of the plugins removed from core, they should download and copy the plugin folder to the right place (as they use to do with third-party plugins) BEFORE running the upgrading process.

Moodle 4.0 release notes

2022-07-07T17:11:01Z

Stronk7: updating the requirements, no matter the page is blocked/migrated coz this is still visited lots

{{Template:Migrated|newDocId=/general/releases/4.0}}
[[Releases]] > {{FULLPAGENAME}}

Release date: 19 April 2022

Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%224.0%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 4.0].

See our [https://docs.moodle.org/400/en/New_features New features] page in the user documentation for an introduction to Moodle 4.0 with screenshots.
{{MediaPlayer | url = https://www.youtube.com/watch?v=sZxZ_YzsD_w&list=PLxcO_MFWQBDcI0BezfCOW8QRfJw6FblRn&ab_channel=Moodle | desc = Moodle 4.0 new features}}

If you are upgrading from a previous version, please see [[:en:Upgrading|Upgrading]] in the user docs.
==Server requirements==
These are just the minimum supported versions. We recommend keeping all of your software and operating systems up-to-date.
* Moodle upgrade: Moodle 3.6 or later
* PHP version: minimum PHP 7.3.0 ''Note: minimum PHP version has increased since Moodle 3.10''. PHP 7.4.x and 8.0.x are supported too. See [[Moodle and PHP]] for details.
* PHP extension '''sodium''' is recommended. It will be required in Moodle 4.2. For further details, see [https://docs.moodle.org/311/en/Environment_-_PHP_extension_sodium Environment - PHP extension sodium].
* PHP extension '''exif''' is recommended.
* PHP setting '''max_input_vars''' is recommended to be >= 5000 for PHP 7.x installations. It's a requirement for PHP 8.x installations. For further details, see [https://docs.moodle.org/311/en/Environment_-_max_input_vars Environment - max input vars].
=== Database requirements ===
Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.
{| class="wikitable"
|-
! Database
! Minimum version
! Recommended
|-
| [http://www.postgresql.org/ PostgreSQL]
| 10 (increased since Moodle 3.11)
| Latest
|-
| [http://www.mysql.com/ MySQL]
| 5.7
| Latest
|-
| [https://mariadb.org/ MariaDB]
| 10.2.29
| Latest
|-
| [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]
| 2017 (increased since Moodle 3.10)
| Latest
|-
| [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]
| 11.2
| Latest
|}

==Client requirements==
=== Browser support ===
Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

Desktop:
* Chrome
* Firefox
* Safari
* Edge
''Note: Moodle 4.0 does NOT support Internet Explorer 11.''

Safari 7 and below has known compatibility issues with Moodle 4.0.

Mobile:
* MobileSafari
* Google Chrome
For the best experience and optimum security, we recommend that you keep your browser up to date.
==Major UX improvements==
===Navigation improvements===
* MDL-70208 - Implement frontend functionality for primary navigation
* MDL-70207 - Implement backend functionality for primary navigation
* MDL-70202 - Implement frontend functionality for secondary navigation
* MDL-70198 - Implement backend functionality for secondary navigation
* MDL-70196 - Create a module based navigation bar
* MDL-72352 - Ensure that secondary navigation is backwards compatible
* MDL-73462 - Course and category management secondary and tertiary navigation
* MDL-71977 - Define the secondary navigation nodes that should be always displayed in the more menu in the module context
* MDL-71901 - Allow plugins to define their own secondary nav ordering
* MDL-70844 - Update the secondary navigation view to send site administration information in tab form
* MDL-72396 - Allow easy setting of the active tab for navigation views
* MDL-71912 - Implement tertiary navigation for plugins (also see MDL-71913, MDL-71914 and MDL-71914)
* MDL-73863 - Tertiary navigation in course completion
* MDL-72875 - Add tertiary navigation to the participants page
* MDL-72904 - Add tertiary navigation to the badges pages
* MDL-72873 - Add tertiary navigation to the gradebook
* MDL-72094 - Update the course reports page styling and functionality
* MDL-71083 - Move the user menu in the top bar into the primary navigation menu in the mobile view
* MDL-73393 - Ensure that existing third party themes still work with latest navigation changes
* MDL-71943 - Dynamic (AJAX) tabs in Moodle LMS
* MDL-72090 - Convert course admin pages from link farms to dropdowns
* MDL-72413 - Move the activity modules title, description, and activity completion into a standard module API
* MDL-72736 - Remove section navigation on one section per page
* MDL-72834 - Move the calendar link into the user menu
* MDL-72450 - Remove the next and previous activity links from all activity modules in Boost
* MDL-71148 - Combine both the custom menu & primary navigation renderers
* MDL-71683 - Update language menu to move from the top navigation into the user menu when logged in
* MDL-72005 - Update the context_header in Boost to move the breadcrumb to the top
===Course index===
* MDL-71209 - Create the new course index list
* MDL-72660 - Add activity completion indicators to the course index
* MDL-71228 - Implement drag and drop option for sections and activities in the course index
* MDL-71211 - Keep the status of the course index collapsed and expanded sections per user and course
* MDL-71795 - Course index on activity view page
* MDL-71828 - Implement section links' behaviour in course index
* MDL-71664 - Enable drag & drop from course index to course content and vice versa
* MDL-72463 - Add 'highlighted' label to course index
* MDL-71727 - Sync course index and course content when an element is dragged
* MDL-72897 - Mark the current section in the course index
* MDL-73340 - Open course index by default first time a user access the course
* MDL-73310 - Show the course index on all pages within a course
===Course experience===
* MDL-71037 - Sections are now collapsible for Topics and Weekly course formats
* MDL-71691 - Created a new activity UI component
* MDL-71689 - Improvements to add activity and add section design
* MDL-71663 - Created a new "move" option in the sections and activity cog menu in the course editor
* MDL-71779 - Made 'Add a new topic/week' option client side on Topics and Weekly formats
* MDL-72311 - Proceed straight to course content when creating a new course
* MDL-71863 - Created core_courseformat subsystem
* MDL-72578 - Moved activity UI component to output classes and templates
* MDL-73343 - New quick access to create a new course from My courses page when there is no course available
===My Courses page and overview block===
* MDL-70801 - Implement "My courses" page
* MDL-58579 - Allow searching / filtering of courses in myoverview
* MDL-73231 - Provide option of having My courses as defaulthomepage
===Timeline block===
* MDL-72276 - Update timeline block dropdowns to display current selection
* MDL-72277 - Improve the layout and usability of the items in the timeline block
* MDL-73068 - Only display courses in the timeline block if they contain events
* MDL-72295 - Add text search to the timeline block
* MDL-72594 - Improve displaying of overdue items in the timeline block
* MDL-72603 - Replace timeline block pagination with "show more" lazy loading
* MDL-72543 - Change the display of the event names of the items on the timeline block
===Calendar usability===
* MDL-71817 - Render the calendar in the calendar block in month view
* MDL-72237 - Limit number of events shown per day in calendar month view
* MDL-71810 - Add a current date indicator and make calendar block responsive when switching between small and large views
* MDL-71808 - Move the import calendar form to its own page
* MDL-72045 - Improve help information provided on the calendar export page
* MDL-71790 - Revamp the manage subscriptions page
* MDL-71788 - Make it easier to copy the export URL
* MDL-71775 - Add footer links to the calendar block
* MDL-72810 - Remove 3-month calendar view
===Dashboard===
* MDL-72092 - Arrange blocks between My courses & My dashboard
* MDL-73114 - Display a title in the dashboard page
* MDL-71964 - Welcome message for users
* MDL-73233 - Provide option to disable the Dashboard
* MDL-72116 - Remove some of the default blocks from the Dashboard
===User tours===
* MDL-61674 - Allow user tours to be created using the Atto text editor
* MDL-72385 - Improve and simplify design of user tours
* MDL-71938 - Display number of steps in a user tour
* MDL-72783 - Add new user tours
* MDL-72781 - Remove previous user tours
* MDL-72557 - Implement customisable confirmation button for single step user tours
* MDL-71931 - Update user tours to emit events
===Other usability and user experience improvements===
* MDL-69371 - Redesign the Moodle login page (also see MDL-72928)
* MDL-71457 - Update the Moodle activity icons
* MDL-71963 - Turn confirmation page into modals
* MDL-71965 - New footer
* MDL-71456 - Create page drawers for the block and course index areas
* MDL-72095 - Set a main container width of Boost pages
* MDL-71610 - Move the turn editing on button into the navbar
* MDL-72305 - Show user initials as a placeholder for the user profile picture
* MDL-72278 - Fake blocks now in drawer are made visible on first visit
* MDL-72454 - Removal of back to top link
* MDL-72088 - Update styling across top level pages
* MDL-70888 - Update the layouts in Boost theme
* MDL-71292 - Update the page header and include course image / activity icon
* MDL-73608 - Provide a contact form which sends to the site support email and replace mailto link in footer
* MDL-73935 - Improved flexibility of site support form and consistency of site support info provided in Moodle
* MDL-61564 - Allow multiple cohort selection in cohort enrolment
* MDL-66539 - Better handling of link names and URLs with Atto
* MDL-73797 - Dialogues now have the action button on the right
* MDL-60917 - Add highest ranked results section to global search
* MDL-73917 - Notification preferences page improvements
* MDL-72500 - Easier to find a specific component in event list report
* MDL-32103 - Course completion is instant for activity based completion criteria (single user completions only)
==Other major features==
===Report builder integration (from Moodle Workplace)===
* MDL-70795 - Implement functionality for creating custom reports
* MDL-70794 - Implement functionality for creating system reports
* MDL-72588 - Implement custom report audiences
* MDL-72598 - Implement custom report schedules
* MDL-73598 - Allow Custom Reports to be disabled by site admin
* MDL-72280 - Create "Courses" custom report source
* MDL-73069 - Report condition to limit returned data to current user
* MDL-73180 - Improve definitions of previous/next relative date filters
* MDL-72662 - Implement relative date options in the Reportbuilder date filter
* MDL-72172 - Create "Cohort members" custom report source
* MDL-72962 - Format editable report elements (column, filters, etc)
* MDL-72826 - Custom report option to display unique row values
* MDL-71153 - Convert task logs report to a system report
* MDL-71070 - Convert configuration changes report to a system report
===BigBlueButton integration===
* MDL-70658 - Integrate the BigBlueButton plugin into Moodle LMS
===Quiz and Questions===
* MDL-71516 - Create new plugin type - Qbank (for the full list of qbank plugins added to core, see MDL-70329)
* MDL-71679 - Update mod_quiz for new question bank
* MDL-71636 - Add a columnsortorder settings page
* MDL-71696 - Add question versions
* MDL-72076 - Question bank bulk action UI
* MDL-72553 - Add custom fields to questions
* MDL-52206 - Move "Require passing grade" completion option to core
* MDL-52456 - Add notification message for students after questions have been manually graded
* MDL-71984 - Add logging to quiz auto-save, process_attempt and redo_question
* MDL-73337 - Log editing quizzes in detail
* MDL-73699 - Question status UI/UX update
* MDL-72448 - Add qbank_history to core
* MDL-71614 - Add qbank_previewquestion to core
===Update LTI tool provider feature to support 1.3===
* MDL-69543 - Update tool to support 1.3 OAuth2/OIDC launch flow
* MDL-71371 - Provide upgrade path for 1.1 preconfigured tools
* MDL-72745 - Provide account provisioning options for LTI Advantage launches
* MDL-69547 - Update tool enrolment code so that a user is automatically created and enrolled when launching via 1.3
* MDL-69545 - Update user sync task to support 1.3 messages
* MDL-69544 - Update grade sync task to support 1.3 messages
* MDL-72288 - Update library and model code to support issuer and clientid uniqueness on registrations
* MDL-69862 - Add dynamic registration support to the tool
* MDL-70354 - Return line item information during content selection
===Assignment===
* MDL-68913 - Per attempt timing now available in assignments
===Admin configuration presets===
* MDL-72112 - Integrate admin_presets third-party plugin in Moodle LMS
* MDL-73145 - Add a $CFG setting to define the preset to be installed
* MDL-72114 - Include pre-installed admin presets
* MDL-72113 - Add feature to import/export plugins visibility from Admin presets tool
* MDL-73394 - Store the latest site admin preset applied
===Content bank and H5P===
* MDL-68394 - Integrate mod_h5pactivity with recent activity plugins
* MDL-72099 - Add navigation by contexts in the content bank
* MDL-71885 - Inline editing H5P content for mod_h5pactivity
* MDL-71956 - Inline editing H5P content anywhere
===Badges===
* MDL-72141 - Simplifying the external badge page
===Accessibility improvements===
* MDL-67853 - Remove online-offline options on notifications
* MDL-72078 - Give users an indication that they encountered an editor
* MDL-71604 - Move the screen reader helper button to the first row
* MDL-72896 - Make html_tables responsive by default
==Other Highlights==
===Functional changes===
* MDL-70456 - Add custom user field support to all places that display user identity [0,Minor] Improvement
* MDL-73342 - Disable some blocks by default (such as feedback, RSS and self-completion)
* MDL-70905 - Updated media default width/height to use 16:9
* MDL-72118 - Rename "HTML block" to the more easily understood "Text block"
* MDL-72706 - Change default value of "Hidden sections" course format setting
* MDL-72115 - Rename "Miscellaneous" category to "Category 1"
* MDL-72119 - Make “Enable xxxxx” features consistent (hide menus for disabled features)
===For administrators===
* MDL-71347 - Add a filter to "browse list of users" for date of user account creation
* MDL-72031 - Separate out max_time for audio and video files in Atto/RecordRTC
* MDL-71515 - Improve the test outgoing mail configuration admin page
* MDL-67686 - Add more filters to task log (/admin/tasklogs.php)
* MDL-72984 - Ensure support email address is mandatory
* MDL-73592 - MoodleNet integration now enabled by default
* MDL-71621 - Parent role cannot edit custom fields in child profile
* MDL-73918 - Allow admins to change the page width using custom SCSS
* MDL-71927 - Logs and question attempt history now show time to the second, to help investigate issues
* MDL-71466 - Custom user field support: Admin role screens (check permissions, assign)
* MDL-72619 - Provide admin page to view cache size estimates
* MDL-67822 - New check_database_schema performance check
* MDL-70271 - Dropbox token and Permission Updates
* MDL-58395 - LDAP auth sync now skip and report problematic user accounts
* MDL-72251 - Tasks admin UI now shows time to nearest second
===Mobile===
* MDL-67807 - Return concurrent sessions information to apply concurrent login limit in the mobile app
* MDL-69555 - Make duration of QR login and auto-login time between requests configurable
* MDL-73794 - Update the footer in the mobile view
===Performance===
* MDL-72596 - Caching: Track cache I/O size in perfdebug
* MDL-69088 - Make file cache store purges instant with a safe and async purge
* MDL-68164 - Additional caching of pg_field_type postgres field metadata
* MDL-63983 - Improve the performance of non-contact searches in messaging when site-wide messaging is disabled (default)
* MDL-71014 - Cache the siteidentifier and site contextid in local cache
* MDL-72328 - Add TTL support for Redis caches
* MDL-72837 - Cache API should support versioned data
==Security improvements==
* MDL-56873 - Set more secure defaults for the cURL allow/deny lists
* MDL-66776 - Send notifications when new devices are used to log in into the site
* MDL-71627 - Add check API for anti virus and optionally remove admin notifications
* MDL-71806 - Improved the UX of the Moodle security report
* MDL-71176 - New password and change forms should have autocomplete="new-password"
==For developers==
* MDL-61460 - Introduce the UI components library
* MDL-74229 - Add navigation node keys to allow themers to hide navigation tabs
* MDL-74235 - Rename the icons for activities to allow support of multiple icons for multiple versions
* MDL-74033 - Allow full customisation of the primary navigation
* MDL-72779 - Set more than one value on a persistent at the same time
* MDL-70862 - Implement a new callback to extend gradebook plugininfo
* MDL-72289 - Allow callers to customise the rendered icon of inplace editable elements
* MDL-73347 - Allow themes to define un-addable blocks
* MDL-46778 - Allow use a separate DB configuration (not just prefix) for Behat similar to PHPUnit
* MDL-73270 - Warn where XMLRPC is currently in use
* MDL-67228 - Tool_replace maturity set
===Web service additions and updates===
* MDL-71135 - Create core_course_get_state web service
* MDL-71165 - Create core_course_update_course web service
===Core plugins removed===
* MDL-71473 - Jabber removed as a standard notification plugin
* MDL-58939 - Picasa repository and portfolio removed from core
* MDL-72335 - Tool_health removed from core
* MDL-72615 - Boxnet plugins removed from core
* MDL-72616 - Quiz results block removed from core
* MDL-72348 - Microsoft OneDrive (legacy) repository (repository_skydrive) removed from core
* MDL-72347 - Word censorship filter (filter_censor) removed from core
* MDL-72407 - VideoJS Flash plugin removed from core
* MDL-72042 - Flash animation media player removed from core
* MDL-72041 - WebCT question import format removed from core
* MDL-72517 - Examview question import format removed from core
===Deprecations===
* MDL-53544 - Typo3 library removed
* MDL-72004 - Quiz 4.0 Class renaming and deprecation
* MDL-73756 - Deprecate $modinfo param to completion_info::get_data()
* MDL-65799 - Phase 2 of deprecation of functions in lib/deprecatedlib.php initially deprecated in 3.8
* MDL-71175 - Deprecate some plagiarism functions that are not used, or have replacements
* MDL-66266 - Remove deprecated functions in messages/classes/api.php
* MDL-72098 - deprecate grade_grade::insert method that just calls its parent
* MDL-72433 - Final deprecation of get_grades() in lib/classes/grades_external.php
* MDL-71476 - Remove mysql_engine.php
* MDL-65252 - Final deprecations of forum_count_replies and get_forum_discussion_posts
* MDL-67412 - Remove deprecated functions in lib/setuplib.php
* MDL-65801 - Remove strings deprecated in 3.8
===Component API updates===
* admin/tool/generator/upgrade.txt
* admin/tool/log/upgrade.txt
* admin/tool/mobile/upgrade.txt
* admin/tool/upgrade.txt
* admin/tool/usertours/upgrade.txt
* admin/upgrade.txt
* analytics/upgrade.txt
* auth/shibboleth/upgrade.txt
* availability/upgrade.txt
* backup/upgrade.txt
* badges/upgrade.txt
* blocks/section_links/upgrade.txt
* blocks/tag_youtube/upgrade.txt
* blocks/timeline/upgrade.txt
* blocks/upgrade.txt
* cache/upgrade.txt
* calendar/upgrade.txt
* completion/upgrade.txt
* contentbank/upgrade.txt
* course/format/upgrade.txt
* course/upgrade.txt
* customfield/upgrade.txt
* dataformat/upgrade.txt
* enrol/database/upgrade.txt
* enrol/upgrade.txt
* filter/upgrade.txt
* grade/grading/form/upgrade.txt
* grade/upgrade.txt
* group/upgrade.txt
* h5p/upgrade.txt
* lib/upgrade.txt
* media/upgrade.txt
* message/upgrade.txt
* mod/assign/upgrade.txt
* mod/book/upgrade.txt
* mod/feedback/upgrade.txt
* mod/forum/upgrade.txt
* mod/glossary/upgrade.txt
* mod/h5pactivity/upgrade.txt
* mod/lesson/upgrade.txt
* mod/lti/upgrade.txt
* mod/page/upgrade.txt
* mod/quiz/upgrade.txt
* mod/resource/upgrade.txt
* mod/scorm/upgrade.txt
* mod/upgrade.txt
* mod/url/upgrade.txt
* mod/wiki/upgrade.txt
* mod/workshop/upgrade.txt
* my/upgrade.txt
* payment/upgrade.txt
* plagiarism/upgrade.txt
* portfolio/upgrade.txt
* question/bank/upgrade.txt
* question/behaviour/upgrade.txt
* question/engine/upgrade.txt
* question/format/upgrade.txt
* question/type/multichoice/upgrade.txt
* question/type/upgrade.txt
* question/upgrade.txt
* report/eventlist/upgrade.txt
* report/upgrade.txt
* repository/upgrade.txt
* search/upgrade.txt
* theme/upgrade.txt
* user/upgrade.txt
* webservice/upgrade.txt

==See also==
*[[Moodle 3.11 release notes]]

[[Category:Release notes]]
[[Category:Moodle 4.0]]

[[fr:Notes de version de Moodle 4.0]]
[[es:Notas de Moodle 4.0]]

Moodle 3.11 release notes

2022-07-07T17:10:00Z

Stronk7: updating the requirements, no matter the page is blocked/migrated coz this is still visited lots

{{Template:Migrated|newDocId=/general/releases/3.11}}
[[Releases]] > {{FULLPAGENAME}}

Release date: 17 May 2021

Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%223.11%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 3.11].

See our [https://docs.moodle.org/311/en/New_features New features page] in the user documentation for an introduction to Moodle 3.11 with screenshots.

If you are upgrading from a previous version, please see [[:en:Upgrading|Upgrading]] in the user docs.
==Server requirements==
These are just the minimum supported versions. We recommend keeping all of your software and operating systems up-to-date.
* Moodle upgrade: Moodle 3.6 or later
* PHP version: minimum PHP 7.3.0 ''Note: minimum PHP version has increased since Moodle 3.10''. PHP 7.4.x and 8.0.x are supported too. See [[Moodle and PHP]] for details.
* PHP extension '''sodium''' is recommended. It will be required in Moodle 4.2. For further details, see [https://docs.moodle.org/311/en/Environment_-_PHP_extension_sodium Environment - PHP extension sodium].
* PHP setting '''max_input_vars''' is recommended to be >= 5000 for PHP 7.x installations. It's a requirement for PHP 8.x installations. For further details, see [https://docs.moodle.org/311/en/Environment_-_max_input_vars Environment - max input vars].
=== Database requirements ===
Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.
{| class="wikitable"
|-
! Database
! Minimum version
! Recommended
|-
| [http://www.postgresql.org/ PostgreSQL]
| 9.6
| Latest
|-
| [http://www.mysql.com/ MySQL]
| 5.7
| Latest
|-
| [https://mariadb.org/ MariaDB]
| 10.2.29
| Latest
|-
| [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]
| 2017 (increased since Moodle 3.10)
| Latest
|-
| [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]
| 11.2
| Latest
|}

==Client requirements==
=== Browser support ===
Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

Desktop:
* Chrome
* Firefox
* Safari
* Edge
''Note: Moodle 3.10 and above do NOT support Internet Explorer 11.''

Safari 7 and below has known compatibility issues with Moodle 3.10 and above.

Mobile:
* MobileSafari
* Google Chrome
For the best experience and optimum security, we recommend that you keep your browser up to date. https://www.whatsmybrowser.org/
==Warnings==
* If you have a site running on MariaDB / MySQL with many users, you may experience database issues after the upgrade step 2021042100. The upgrade attempts to drop several columns from the user table ("icq", "skype" and others) once they were converted to new user profile fields (MDL-28452). These ALTER TABLE queries typically require copying all the rows into a new tablespace and rebuilding all indexes. Which may eventually lead to time-outs and ''"MySQL server has gone away"'' errors. It should be enough and safe to simply wait for the query to finish on the DB server (you may need to monitor currently running queries there) and then re-run the upgrade until the upgrade step 2021042100.01 finishes successfully.
==Major features==
===Improve student activity completion===
* MDL-71189 - Define sort ordering for completion conditions
* MDL-70821 - Update the course homepage to display the activity information
* MDL-70818 - Implement the activity dates functionality for each activity and output them in view.php
* MDL-70815 - Create a base class for fetching a user's activity completion details
* MDL-70816 - Create a base class for fetching an activity's dates that are relevant for a given user
* MDL-70820 - Implement the completion details functionality for each activity plugins output them in view.php - Part 1
* MDL-70935 - Implement the completion details functionality for each activity plugins output them in view.php - Part 2
* MDL-71235 - Review and update existing web services to return the new fields and exported information from activities
* MDL-71288 - Activity completion fallback for third party plugins
* MDL-71163 - Remove duplicate activity dates
* MDL-71144 - Deprecate the *_get_completion_state() callbacks
* MDL-71234 - Create user tours for the activity information output component
===Brickfield accessibility toolkit===
* MDL-69863 - Brickfield Education Labs accessibility toolkit core integration
===Badges===
* MDL-71117 - Make Moodle OBv2.1 implementation compliant
* MDL-70689 - Add new "IMS OBv2.1" OAuth 2 service
* MDL-70911 - Remove "Backpack settings" site administration page and improve UI
* MDL-63961 - Improve resolution of badge image sent to external backpacks and used when duplicating badges
===Content bank and H5P===
* MDL-69331 - Add ability to disable specified H5P content types
* MDL-66769 - Create a task to clean up unused H5P content
* MDL-70429 - Set the default returntype to reference in repository_contentbank
* MDL-67999 - Update content bank upload button to open file picker in a popup instead of new page
* MDL-69762 - Option to make a content bank item unlisted
* MDL-70408 - Open H5P file from H5P activity when it was added as a reference
* MDL-70438 - Content bank should provide info on the number of places where content is used and warn you when deleting
===Assignment===
* MDL-52420 - Assignment comments should be also saved when clicking 'save changes' in the assignment grader page
* MDL-68533 - Allow mod_assign download all assignments to be streamed
* MDL-67702 - Assignment name filter preference should only affect current assignment's view
* MDL-70038 - Implement Poppler pdftoppm compatibility for faster assignment submission PDF to PNG conversion
* MDL-69631 - Add 'Draft' filter to assignment grading table
===Quiz and questions===
* MDL-32226 - Add Plagiarism support to essay questions
* MDL-70895 - Questions: Default options when creating a question
* MDL-71262 - Add default options for essay question type
* MDL-71225 - Add default options for ddimageortext, ddmarker and match question types
* MDL-71181 - Display pass grade on quiz front page
* MDL-68597 - Add optional min/max word count limits to Essay question type
* MDL-69735 - Read-only view of quiz settings overrides
* MDL-70134 - Improve manual grading of quiz essay answers - web page format
* MDL-66600 - Manual grading of automatically graded questions: show computer grading
* MDL-71205 - Add default options for numerical question type using user-preferences
* MDL-70562 - In a newly created quiz, prevent "Edit quiz" and "Back to the course" buttons sticking together
* MDL-70266 - Quiz override screens should show user identity fields
* MDL-71030 - Quiz review: name the person who made each change in the question response history (if not the student)
===Accessibility improvements===
* MDL-69474 - Improve accessibility of profile images
* MDL-71089 - Make it possible to style toast notifications
===Usability improvements===
* MDL-70817 - Create an output component that displays an activity's information for a user
* MDL-48594 - More filtering options on Activity Completion Report
* MDL-65856 - UX Review of session expired timeout modal
* MDL-65135 - Add year to messaging conversation date headings, if not the current year
* MDL-51287 - Show confirmation when profile changes are saved
* MDL-70565 - Add ability to search country field on Participants page
* MDL-69145 - Default the participants page filtering to "ALL"
* MDL-57831 - Improve notification preferences on/off buttons so they fit better with non-English strings
* MDL-71254 - OAuth2: Display login errors on the login page
* MDL-67028 - LTI: Support Course dates substitution parameters
* MDL-70753 - Create landing page for the reports link in the secondary navigation
* MDL-71403 - Update message preferences of a user as admin to use consistent toggle icons
* MDL-71064 - Add support for keyboard hotkeys in VideoJS
* MDL-69878 - Always show the close button on the message drawer
==Other highlights==
===Functional changes===
* MDL-28452 - Convert user profile fields for messaging/networking into custom profile fields
* MDL-58673 - Enable playbackrates for videojs
* MDL-45242 - Allow user profile fields to be specified as user identity fields - New code is backwards-compatible, but report code should be updated.
* MDL-66431 - Remove "Enable activity chooser" user preference
* MDL-61768 - Update Google Drive repository to allow Shared drive files
* MDL-63381 - Option to not include permissions overrides when importing or restoring a backup
* MDL-71190 - Backup and Restore lastaccess to course
* MDL-48269 - Remove option to hide a group picture
* MDL-71118 - Differentiate between grade as a noun and grade as a verb in the UI texts
* MDL-71186 - Add custom user field support to group management screens
* MDL-69773 - Add an option to display section names in Section link block
===For administrators===
* MDL-70722 - Move Microsoft, Facebook and NextCloud OAuth2 services to new, reorganised architecture
* MDL-42382 - Add a "Replace filter" option on the admin browse users page
* MDL-65843 - Ability to force cron scheduled task definitions in config.php (schedule and disabled)
* MDL-70536 - Create a CLI script to reset user dashboards
* MDL-67748 - Improve the web services tokens management to allow searching and filtering
* MDL-69460 - Check for removed files before CLI upgrade
* MDL-70828 - Add ability to switch off session lock debugging
* MDL-70583 - Implement a renderer for progress_bar in cli output
* MDL-68010 - Allow disabled tasks to be run from the GUI
* MDL-71017 - Add the ability to configure OAuth2 services for login only; add login display name
* MDL-70269 - Update the ClamAV default behaviour when an error occurs
* MDL-70500 - Use Dynamic Registration to allow Tools to update to LTI Advantage
* MDL-70287 - Payment service consumers should be able to specify url after payment
* MDL-70158 - Make it easier to find a specific component in template library
* MDL-70632 - Allow searching of available language packs
* MDL-70362 - Add showdebugging and showsql options to admin/cli/uninstall_plugins.php
* MDL-69898 - Config change event should link to config change report
* MDL-70159 - Sort capabilities in capability overview tool
===Mobile===
* MDL-71273 - Add a new option in Moodle app "Disabled features" for preventing the new LTI launch in the app
* MDL-65983 - Include option for testing Push notifications in a site
===Performance===
* MDL-68481 - mod/folder/download_folder.php should be a streaming zip download
* MDL-70444 - Make my_reset_page_for_all_users for dashboards more robust
* MDL-68052 - Implement cleanup of analytics_indicator_calc stores table
* MDL-71044 - Extend the 'backup_cleanup_task' scheduled task to remove old files
* MDL-66667 - Cache course image in the course_summary_exporter
* MDL-69121 - Allow redis session store to use zip or zStd for compression like redis MUC
* MDL-70107 - Running a scheduled task in the GUI should unlock the session
* MDL-27193 - Eliminate DB queries in mod/glossary/settings.php
* MDL-70608 - Update language pack installs / updates to run asynchronously to avoid timeouts when multiple are used
==Security improvements==
* MDL-65818 - Provide admin setting type for secure data (passwords/tokens)
* MDL-64865 - Add logging when auth config is automatically changed due to config/filesystem mismatch
* MDL-69333 - Reduce ability to fingerprint a server with a htaccess-dist / nginx file / docs
* MDL-69522 - Allow antivirus scanners to specify the message to the user
* MDL-67882 - Log changes to the message notifications settings
* MDL-70649 - Allow plugins to augment the cURL security helper via callback
* MDL-70735 - Reduce information disclosure from TCPDF version
* MDL-70766 - Log changes to auth plugin settings in config log
* MDL-70439 - Display user email address visibility settings on their own profile
==For developers==
The PHPUnit upgrade will almost certainly break your tests. See [[Writing PHPUnit tests#Upgrading unit tests to work with Moodle 3.11 and up .28PHPUnit 9.5.29]]
* MDL-52817 - New sql_group_concat db method
* MDL-64554 - Add module for displaying moodleform in a modal window
* MDL-71036 - Upgrade PHPUnit to 9.5.x
* MDL-68608 - Improve the readonly session debugging message
* MDL-71012 - HTTP 503 Service Not Available is returned by exceptions and should be 500 instead
* MDL-70311 - Upgrade boost to use Bootstrap latest version
* MDL-69202 - Restore backup: add getter method for oldmoduleid
* MDL-70055 - Support large number of SQL-IN parameters in Postgres
* MDL-70142 - Preserve form data when purging individual caches
* MDL-71099 - Move user_fields from core to core_user
===Web service additions and updates===
* MDL-69869 - Add ability for "get enrolled users" web service to be filtered by suspended users
* MDL-70128 - Create a new endpoint (script) to retrieve draft files from web services
* MDL-68853 - Create web service to trigger report_viewed event for H5P activities
* MDL-69259 - Create H5P activity web service to get the list of students that attempted an activity
* MDL-70387 - New web service core_files_get_unused_draft_itemid
* MDL-71492 - Return quiz pass grade via web services
* MDL-70037 - Update mod_forum_get_discussion_posts web service to return the last_modified attribute
* MDL-71031 - Batch create API for grade categories
* MDL-71169 - All new external functions implementation classes should use <tt>execute</tt> as the method name, in which case the <tt>methodname</tt> property should not be specified in db/services.php file
===Deprecations===
* MDL-69792 - Deprecate unused backpack js functions
* MDL-66138 - Deprecate get_forum_discussions_paginated webservice
* MDL-65319 - Phase 2 of deprecation of functions in lib/deprecatedlib.php initially deprecated in 3.7
* MDL-65284 - Final deprecation for analytics methods deprecated in MDL-64783
* MDL-65215 - Final deprecation of i_dock_block()
* MDL-65186 - Final deprecation of \core_analytics\manager::add_builtin_models()
* MDL-65086 - get_enabled_time_splitting_methods final deprecation
* MDL-64982 - Final deprecation of behat_base::TIMEOUT and related constants
* MDL-64866 - Remove message/defaultoutputs.php and final deprecation of admin_page_manageqbehaviours class
* MDL-64776 - Final deprecation of booktool_print_get_toc()
* MDL-63266 - Final deprecation of enrol/database/cli/sync.php
===Component API updates===
* admin/upgrade.txt
* analytics/upgrade.txt
* auth/shibboleth/upgrade.txt
* backup/upgrade.txt
* badges/upgrade.txt
* blocks/section_links/upgrade.txt
* blocks/tag_youtube/upgrade.txt
* completion/upgrade.txt
* contentbank/upgrade.txt
* course/upgrade.txt
* customfield/upgrade.txt
* enrol/database/upgrade.txt
* enrol/upgrade.txt
* group/upgrade.txt
* h5p/upgrade.txt
* lib/upgrade.txt
* mod/book/upgrade.txt
* mod/feedback/upgrade.txt
* mod/forum/upgrade.txt
* mod/h5pactivity/upgrade.txt
* mod/quiz/upgrade.txt
* payment/upgrade.txt
* plagiarism/upgrade.txt
* question/type/upgrade.txt
* report/upgrade.txt
* repository/upgrade.txt
* theme/upgrade.txt
* user/upgrade.txt
* webservice/upgrade.txt
==See also==
*[[Moodle 3.10 release notes]]

[[Category:Release notes]]
[[Category:Moodle 3.11]]

[[fr:Notes de mise à jour de Moodle 3.11]]
[[es:Notas de Moodle 3.11]]

Moodle and PHP

2022-07-07T11:04:12Z

Stronk7: php80 supported since 3.11.8, 4.0.2 and up. And php74 min version for 4.1 and up.

New PHP versions are [https://www.php.net/supported-versions.php released every year] and come with important improvements and changes compared with previous versions. Moodle tries to support them as soon as possible, always matching them with our own [https://docs.moodle.org/dev/Releases#Version_support scheduled release plans].

This page contains the current status of support for every PHP version and Moodle versions. For details, follow also the epic links below that combine all the changes that were made in Moodle to ensure PHP compatibility. ''(Note: you must be logged in to tracker to see issues in Epics)''

MDL-50565 - '''PHP 7.0 can be used with Moodle 3.0.1, Moodle 3.1 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.4. See [[Moodle and PHP 7.0 details]] for details.

MDL-55120 - '''PHP 7.1 can be used with Moodle 3.2 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.7.

MDL-60279 - '''PHP 7.2 can be used with Moodle 3.4 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.9.

MDL-63420 - '''PHP 7.3 can be used with Moodle 3.6.4, Moodle 3.7 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.11.

MDL-66260 - '''PHP 7.4 can be used with Moodle 3.8.3, Moodle 3.9 and later releases.''' It is also the '''minimum''' supported version for Moodle 4.1.

MDL-70745 - '''PHP 8.0 can be used with Moodle 3.11.8, Moodle 4.0.2 and later releases.'''

MDL-73016 - '''PHP 8.1 support is being implemented for Moodle 4.1 and later releases. Hence it's still incomplete and only for development purposes'''
[[fr:Moodle et PHP]]

Github actions integration

2022-06-21T15:09:54Z

Stronk7: just-just out

== Moodle core ==

=== Background ===

Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.

There are many Continuous Integration tools available to developers, and [https://github.com/features/actions GitHub Actions] (usually named simply "GHA") is just one of those available to the Open Source community.

Since November 2020 (Moodle 3.5.16 and up), Moodle includes a GitHub Actions configuration file in its repository. This configuration file configures and controls a GitHub build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.

Note: Moodle HQ uses the Jenkins CI platform and this should be seen as the [https://ci.moodle.org/ canonical CI server for Moodle]. The GitHub Actions integration aims is to provide early warning to developers of any issues with their code.

=== Usage ===

GitHub Actions are available and enabled by default for all public repositories @ GitHub. You can enable or disable them going to your moodle.git clone page, then settings tab -> actions . Please use the "Allow all" option as far as the integration reuses actions from different sources.

[[File:enable_disable_github_actions.png|Enabling and disabling GitHub Actions for your repos]]

For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the service available from GitHub Actions is only available to github public repositories.

=== How do I start a build? ===

Whenever you push a change to any branch in your repository... a build will be queued and executed. You can see how all your builds are progressing by visiting your moodle.git clone page at GitHub, then selecting the actions tab. From there you can filter by branch, by status, access to every build, see failures, relaunch jobs...

[[File:actions_dashboard.png|GitHub Actions "dashboard"]]

You will receive notifications (by email or web) whenever a build finish (can be configured from your account notification settings). Also, if your branches match the branch names in any issue in the Tracker, you will get there the corresponding pass/fail badges [[File:github_passing.png|GitHub passing badge]]. Clicking on them you will access straight to the job details @ GitHub.

And that's all, pretty nice, simple and effective.

=== How do I configure the PHPUnit executions ===

Since Moodle 3.11.8 and 4.0.2, it's possible to configure the PHPUnit executions by creating a [https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository GitHub repository secret] named <code>phpunit_options</code>. Just setup its value to the options that you want to pass to PHPUnit and they will come into effect for all runs. For a list of [https://phpunit.readthedocs.io/en/9.5/textui.html#command-line-options PHPUnit available options] use the <code>vendor/bin/phpunit --help</code> command.

== Moodle plugins ==

See [https://moodlehq.github.io/moodle-plugin-ci/#github-actions the instructions in the Moodle Plugin CI repository].

== See also ==

* [[Travis integration]]: For information about the, also supported, integration with Travis CI facilities.

[[Category:Developer tools]]

Github actions integration

2022-06-21T15:09:00Z

Stronk7: Add "GHA" abbreviation to the description.

== Moodle core ==

=== Background ===

Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.

There are many Continuous Integration tools available to developers, and [https://github.com/features/actions GitHub Actions] (usually named just GHA) is just one of those available to the Open Source community.

Since November 2020 (Moodle 3.5.16 and up), Moodle includes a GitHub Actions configuration file in its repository. This configuration file configures and controls a GitHub build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.

Note: Moodle HQ uses the Jenkins CI platform and this should be seen as the [https://ci.moodle.org/ canonical CI server for Moodle]. The GitHub Actions integration aims is to provide early warning to developers of any issues with their code.

=== Usage ===

GitHub Actions are available and enabled by default for all public repositories @ GitHub. You can enable or disable them going to your moodle.git clone page, then settings tab -> actions . Please use the "Allow all" option as far as the integration reuses actions from different sources.

[[File:enable_disable_github_actions.png|Enabling and disabling GitHub Actions for your repos]]

For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the service available from GitHub Actions is only available to github public repositories.

=== How do I start a build? ===

Whenever you push a change to any branch in your repository... a build will be queued and executed. You can see how all your builds are progressing by visiting your moodle.git clone page at GitHub, then selecting the actions tab. From there you can filter by branch, by status, access to every build, see failures, relaunch jobs...

[[File:actions_dashboard.png|GitHub Actions "dashboard"]]

You will receive notifications (by email or web) whenever a build finish (can be configured from your account notification settings). Also, if your branches match the branch names in any issue in the Tracker, you will get there the corresponding pass/fail badges [[File:github_passing.png|GitHub passing badge]]. Clicking on them you will access straight to the job details @ GitHub.

And that's all, pretty nice, simple and effective.

=== How do I configure the PHPUnit executions ===

Since Moodle 3.11.8 and 4.0.2, it's possible to configure the PHPUnit executions by creating a [https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository GitHub repository secret] named <code>phpunit_options</code>. Just setup its value to the options that you want to pass to PHPUnit and they will come into effect for all runs. For a list of [https://phpunit.readthedocs.io/en/9.5/textui.html#command-line-options PHPUnit available options] use the <code>vendor/bin/phpunit --help</code> command.

== Moodle plugins ==

See [https://moodlehq.github.io/moodle-plugin-ci/#github-actions the instructions in the Moodle Plugin CI repository].

== See also ==

* [[Travis integration]]: For information about the, also supported, integration with Travis CI facilities.

[[Category:Developer tools]]

Github actions integration

2022-06-21T15:07:32Z

Stronk7: Document the availability of phpunit_options for GHA runs (3.11.8, 4.0.2 and up)

== Moodle core ==

=== Background ===

Moodle is regularly tested against a matrix of Databases, PHP Versions, and operating systems, however many developers do not have the resources available to run on many of these combinations before pushing an issue for integration as they are time-consuming to both set up and to run.

There are many Continuous Integration tools available to developers, and [https://github.com/features/actions GitHub Actions] is just one of those available to the Open Source community.

Since November 2020 (Moodle 3.5.16 and up), Moodle includes a GitHub Actions configuration file in its repository. This configuration file configures and controls a GitHub build across a matrix of testing environments. This allows developers pushing patches to Moodle to have their code unit tested before it reaches integration. The hope is that the availability of this integration should reduce the number of unit test failures seen during Integration.

Note: Moodle HQ uses the Jenkins CI platform and this should be seen as the [https://ci.moodle.org/ canonical CI server for Moodle]. The GitHub Actions integration aims is to provide early warning to developers of any issues with their code.

=== Usage ===

GitHub Actions are available and enabled by default for all public repositories @ GitHub. You can enable or disable them going to your moodle.git clone page, then settings tab -> actions . Please use the "Allow all" option as far as the integration reuses actions from different sources.

[[File:enable_disable_github_actions.png|Enabling and disabling GitHub Actions for your repos]]

For the purpose of this documentation, it is assumed that you are pushing to a public Moodle repository on GitHub. Other integrations are supported, but the service available from GitHub Actions is only available to github public repositories.

=== How do I start a build? ===

Whenever you push a change to any branch in your repository... a build will be queued and executed. You can see how all your builds are progressing by visiting your moodle.git clone page at GitHub, then selecting the actions tab. From there you can filter by branch, by status, access to every build, see failures, relaunch jobs...

[[File:actions_dashboard.png|GitHub Actions "dashboard"]]

You will receive notifications (by email or web) whenever a build finish (can be configured from your account notification settings). Also, if your branches match the branch names in any issue in the Tracker, you will get there the corresponding pass/fail badges [[File:github_passing.png|GitHub passing badge]]. Clicking on them you will access straight to the job details @ GitHub.

And that's all, pretty nice, simple and effective.

=== How do I configure the PHPUnit executions ===

Since Moodle 3.11.8 and 4.0.2, it's possible to configure the PHPUnit executions by creating a [https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository GitHub repository secret] named <code>phpunit_options</code>. Just setup its value to the options that you want to pass to PHPUnit and they will come into effect for all runs. For a list of [https://phpunit.readthedocs.io/en/9.5/textui.html#command-line-options PHPUnit available options] use the <code>vendor/bin/phpunit --help</code> command.

== Moodle plugins ==

See [https://moodlehq.github.io/moodle-plugin-ci/#github-actions the instructions in the Moodle Plugin CI repository].

== See also ==

* [[Travis integration]]: For information about the, also supported, integration with Travis CI facilities.

[[Category:Developer tools]]

Javascript Modules

2022-06-08T16:59:03Z

Stronk7: /* Install NVM and Node */

{{Moodle 2.9}}
= Javascript Modules =
== What is a Javascript module and why do I care? ==
A Javascript module is nothing more than a collection of Javascript code that can be used (reliably) from other pieces of Javascript.
== Why should I package my code as a module? ==
By packaging your code as a module you break your code up into smaller reusable pieces. This is good because:

a) Each smaller piece is simpler to understand / debug

b) Each smaller piece is simpler to test

c) You can re-use common code instead of duplicating it
= How do I write a Javascript module in Moodle? =
Since version 2.9, Moodle supports Javascript modules written using the Asynchronous Module Definition ([https://github.com/amdjs/amdjs-api/wiki/AMD AMD]) API. This is a standard API for creating Javascript modules and you will find many useful third party libraries that are already using this format.

To edit or create an AMD module in Moodle you need to do a couple of things.

Since version 3.8, Moodle supports [https://github.com/lukehoban/es6features#readme ECMAScript 2015 features] (aka ES6) in a cross browser compatible way thanks to [https://babeljs.io/ Babel JS]. In order to achieve the compatibility with older browsers Babel will compile the newer ES6 features back into ES5 Javascript. Unfortunately this means that in order for your Javascript changes to show in the browser they must be compiled by running [[Grunt]], even with the cachejs config setting set to false (i.e. "Development mode").

Note that, for Moodle 3.10 and up (see MDLSITE-6130), any new Javascript module '''must''' be written on ES6.
== Install NVM and Node ==
The recommended way of installing NodeJS is via the [https://github.com/nvm-sh/nvm Node Version Manager], or NVM. NVM allows you to have several different versions of NodeJS installed at and in-use at any once on your computer. Supported versions of Moodle all use version {{NodeJSExactVersion}} of NodeJS.

For Linux and Mac, follow https://github.com/nvm-sh/nvm#installing-and-updating

For Windows, use https://github.com/coreybutler/nvm-windows/releases -- Note! NVM 1.1.7 for Windows has bugs. You should upgrade to at least 1.1.9.)

Confirm it is working (version below in on Linux, and probably not current):
$ nvm --version
0.35.3
After you have installed '''nvm''', you should install the correct version of NodeJS by running the following commands from your Moodle directory:
nvm install
nvm use
If your primary use of NodeJS is for Moodle then we recommend that you set NodeJS version {{NodeJSExactVersion}} as your default version. You can do this by running:
nvm alias default {{NodeJSExactVersion}}

== Install grunt ==
The AMD modules in Moodle must be processed by some build tools before they will be visible to your web browser. We use "[[grunt]]" as a build tool to wrap our different processes. Grunt is a build tool written in Javascript that runs in the "[http://nodejs.org/ nodejs]" environment.

Once this is done, you can run the the following commands from your Moodle directory:
npm install
'''This may mention vulnerabilities, that's fine and doesn't apply.'''
npm install -g grunt-cli
Troubleshooting: on Mac, if you get weird errors, try running <code>sudo xcode-select --reset</code>. And, this probably means that you need to have Xcode or simlar build tools installed and resonably up to date.
== Development mode (Moodle v2.9 to v3.7) ==
To avoid having to constantly run grunt, make sure you set the following in your config.php
<syntaxhighlight lang="php">
// Prevent JS caching
$CFG->cachejs = false;
</syntaxhighlight>
Moodle will now run your module from the amd/src module. Don't forget to switch this off and run 'grunt' before deploying the new version!

In this mode - if you get a strange message in your javascript console like "No define call for core/first" it means you have a syntax error in the javascript you are developing.
Or, "No define call for theme_XXX/loader" as you are probably missing the 'src' folder with relevant JS files. which might happen when you turn debugging ON on a theme that was bought, without 'src' folder :-(
== Development mode (Moodle v3.8 and above) ==
All Javascript code is now compiled using Babel which means Moodle will only ever serve minified Javascript to the browser, even in development mode. However in development mode Moodle will also send the browser the corresponding source map files for each of the Javascript modules. The source map files will tell the browser how to map the minified source code back to the unminified original source code so that the original source files will be displayed in the sources section of the browser's development tools.

While in development mode each of the Javascript modules will appear in the browser's source tree as separate modules (no more giant first.js file!) and they will also be loaded with individual network requests (this is a compromise we had to make thanks to some browser bugs with source map files).

To enable development mode set the '''cachejs''' config value to '''false''' in the admin settings or directly in your config.php file:
<syntaxhighlight lang="php">
// Prevent JS caching
$CFG->cachejs = false;
</syntaxhighlight>
Since all Javascript must now be compiled you must run [[Grunt]] in order for you changes to appear in the browser. However rather than running Grunt manually each time on either the whole project or each file you modified, it is recommended that you just run the '''grunt watch''' task at the root of your Moodle directory. The grunt watch task will listen for changes to the Javascript files in the Moodle directory and will automatically lint and compile only the file that is changed after each change is detected. This removes the need to manually run grunt after each change.
== Development mode (Moodle v3.10 and above) ==
All the above for Moodle 3.8 and up applies, plus (see MDLSITE-6130), any new Javascript module must be written on ES6.
== Running grunt ==
You can run grunt in your plugin's 'amd' directory and it will only operate on your modules. If you're having problems or just want to check your work it is worth running for the 'lint' feature. This can find basic problems. This sub-directory support wont work on Windows unfortunately but there is an alternative: Run grunt from the top directory with the --root=path/to/dir to limit execution to a sub-directory.

See [[Grunt#Running_grunt]] for more details of specific grunt commands which can be used.

If you get the error message
/usr/bin/env: node: No such file or directory
Then see the thread https://github.com/nodejs/node-v0.x-archive/issues/3911

On Ubuntu 14.04 this fixed it for me:
sudo ln -fs /usr/bin/nodejs /usr/local/bin/node
Note: Once you have run grunt and built your code, you will then need to purge Moodle caches otherwise the changes made to your minified files may not be picked up by Moodle.
== ES6 Modules (Moodle v3.8 and above) ==
In addition to AMD module syntax Moodle now supports the [https://github.com/lukehoban/es6features#modules ES6 syntax] for writing Javascript modules. All modules (defined using either syntax) are compatible with one another. Behind the scenes the ES6 module syntax is converted into an AMD syntax as part of the Babel compiling process.

Note that, for Moodle 3.10 and up (see MDLSITE-6130), any new Javascript module must be written on ES6.

The call from a PHP file takes the same format
<syntaxhighlight lang="php">
$PAGE->requires->js_call_amd('myplugin/myfile','init');
</syntaxhighlight>
And a minimal ES6 file will work with
<syntaxhighlight lang="php">
export const init = () => {
window.console.log('we have been started');
};
</syntaxhighlight>
=== Export default ===
There is one slight difference between the ES6 definition for exporting modules and the RequireJS (AMD) definition.

ES6 allows you to export a “default” value which is actually no different to exporting a named value where the name is “default”. Unfortunately, RequireJS allows for unnamed default exports (e.g. you can do "return SomeClass;") which can be imported by just requiring them in other AMD modules.

That’s a bit confusing, get to the point! Well, it basically means that in Moodle you won’t be able to write an ES6 module that exports both a default and named exports, e.g. "export default function() {...}" and "export const FOO = 'bar'" in the same module. The export default will simply override all other exports in that module.
=== Inline Javascript ===
Another important note is that ES6 support is only for stand alone Javascript files because it relies on the compilation from Babel and Grunt. That means any inline Javascript (either in PHP or in Mustache templates) won't support the ES6 features. Instead it would be best to keep the inline Javascript as minimal as possible and only use it to load a stand alone Javascript module.
== Minimum (getting started) module for plugins ==
This shows the absolute minimum module you need to get started adding modules to your plugins. It's actually quite simple...
<syntaxhighlight lang="javascript">
// Put this file in path/to/plugin/amd/src
// You can call it anything you like

export const init = () => {
document.addEventListener('change', e => {
const someNode = e.target.closest('.someclass');
if (someNode) {
alert('It changed!');
}
});
};
</syntaxhighlight>
For older versions of Moodle prior to 3.8, you will need to use the legacy ES5 format instead:
<syntaxhighlight lang="javascript">
define([], function() {

return {
init: function() {
document.addEventListener('change', function(e) {
var someNode = e.target.closest('.someclass');
if (someNode) {
alert('It changed!');
}
});
}
};
});
</syntaxhighlight>
This code passes the jquery module into our function (parameter $). There are a number of other useful modules available in Moodle, some of which you'll probably need in a practical application. See [[Useful_core_Javascript_modules]]. Simply list them in both the define() first parameter and the function callback. E.g.,
<syntaxhighlight lang="javascript">
import jQuery from 'jquery'; // We recommend that you strongly consider whether you really need jQuery. It is typically not needed in modern code.
import * as Str from 'core/str';
import Ajax from 'core/ajax';

export const init = config => {
};
</syntaxhighlight>
The idea here is that we will run the 'init' function from our (PHP) code to set things up. This is called from PHP like this...
<syntaxhighlight lang="php">
$PAGE->requires->js_call_amd('frankenstyle_path/your_js_filename', 'init');
</syntaxhighlight>
Don't forget to supply the complete '[[Frankenstyle]]' path. The .js is not needed.

js_call_amd takes a third parameter which is an ''array'' of parameters. These will translate to individual parameters in the 'init' function call. For example...
<syntaxhighlight lang="php">
$PAGE->requires->js_call_amd('block_iomad_company_admin/department_select', 'init', array($first, $last));
</syntaxhighlight>
...calls
<syntaxhighlight lang="javascript">
export const init = (first, last) {
window.console.log(`The first name was '${first}' and the last name was '${last}'`);
};
</syntaxhighlight>
A more comprehensive explanation follows...
== "Hello World" I am a Javascript Module ==
Lets now create a simple Javascript module so we can see how to lay things out.

Each Javascript module is contained in a single source file in the <componentdir>/amd/src folder. The final name of the module is taken from the file name and the component name. E.g. block_overview/amd/src/helloworld.js would be a module named "block_overview/helloworld". the name of the module is important when you want to call it from somewhere else in the code.

After running grunt - the minified Javascript files are stored in the <componentdir>/amd/build folder. The javascript files are renamed to show that they are minified (helloworld.js becomes helloworld.min.js).

Don't forget to add the built files (the ones in amd/build) to your git commits, or in production no-one will see your changes.

Lets create a simple module now:

blocks/overview/amd/src/helloworld.js
<syntaxhighlight lang="javascript">
// Standard license block omitted.
/*
* @module block_overview/helloworld
* @copyright 2015 Someone cool
* @license http://www.gnu.org/copyleft/gpl.html GNU GPL v3 or later
*/

import * as Str from 'core/str';

/**
* Reveal all of the hidden notes.
*/
const showAllNotes = () => {
document.querySelectorAll('.note.hidden').map(note => note.removeClass('hidden'));
};

/**
* Hide all of the notes.
*/
const hideAllNotes = () => document.querySelectorAll('.note').map(note => note.addClass('hidden'));

/**
* Return a personalised, formal, greeting.
*
* @param {String} name The name of the person to greet
* @returns {Promise}
*/
export const formal = name => Str.get_string('formallygreet', 'block_overview', name);

/**
* Return a personalised, informal, greeting.
*
* @param {String} name The name of the person to greet
* @returns {Promise}
*/
export const informal = name => {
return Str.get_string('informallygreet', 'block_overview', name);
};
</syntaxhighlight>
It's important to note tha tonly functions which are exported will be callable from outside the module. These are part of the public API.
== Loading modules dynamically ==
What do you do if you don't know in advance which modules will be required? In a limited number of situations you may not know the modules that you need until you call them. You can make use of dynamic imports to import them when you know what they are. Note: This is not the recommended approach in most cases.
<syntaxhighlight lang="javascript">
export const showTheThing = thingToShow => {
// Load the module for this thing.
import(`local_examples/local/types/type_${thingToShow.modname}`)
.then(thingModule => {
window.console.log(`The ${thingToShow.modname} is now available under thingModule within this scope`);

return thingModule;
});
};
</syntaxhighlight>
== Including an external javascript/jquery library ==
If you want to include a javascript / jquery library downloaded from the internet you can do so as follows:

'''Warning: if the library you download, supports AMD but is already "named" you will not be able to include it directly'''
e.g.
<syntaxhighlight lang="javascript">
// DO NOT DO THIS - IT DOES NOT WORK IN MOODLE
define("typeahead.js", *[ "jquery" ], function(a0) {
return factory(a0);
});
</syntaxhighlight>
will not work, as moodle injects it's own define name when loading the library.

If the library is in AMD format and has a define:
e.g. i want to include the jquery final countdown timer on my page ( hilios.github.io/jQuery.countdown/ )
* download the module in both normal and minified versions
* place the modules in your moodle install e.g. your custom theme dir, or plugin dir
* /theme/mytheme/amd/src/jquery.countdown.js
you can now include the module and initialise it (there are multiple ways to do this)
php:

1. Create your own AMD module and initialise it:

In your PHP file:
<syntaxhighlight lang="php">
$this->page->requires->js_call_amd('theme_mytheme/countdowntimer', 'init', $params);
</syntaxhighlight>
Javascript module:
<syntaxhighlight lang="javascript">
// /theme/mytheme/amd/src/countdowntimer.js
import Countdown from 'theme_mytheme/jquery.countdown');
import $ from 'jquery';

export const init = params => {
$('#clock').countdown(params.targetItem, event => {
$(event.target).html(event.strftime('%D days %H:%M:%S'));
});
};
</syntaxhighlight>
2. Call your Javascript module from your template:
<syntaxhighlight lang="javascript">
// /theme/mytheme/templates/countdowntimer.mustache
<span id="theme_mytheme-clock-{{uniqid}}"></span>
{{#js}}
require(['theme_mytheme/countdowntimer'], function(myModule) {
myModule.init({
targetItem: 'theme_mytheme-clock-{{uniqid}}'
});
});
{{/js}}
</syntaxhighlight>
Note: If you feel that you need to work around MDL-62468, then you should probably be putting the data into the DOM in your template via data Attributes, or loading it via a Web Service.

Another example of adding a 3rd-party library to a Moodle plugin (by Ruslan Kabalin)

If you want use https://github.com/R-TEK/colr_pickr in your plugin but this module isn't RequireJS-compatible.

You need to configure requirejs in your plugin to use third-party library:
<syntaxhighlight lang="php">
$config = ['paths' => ['colorpicker' => 'CDN or local path...']];
$requirejs = 'require.config(' . json_encode($config) . ')';
$PAGE->requires->js_amd_inline($requirejs);
</syntaxhighlight>
Then in your JS module in the plugin:
<syntaxhighlight lang="javascript">
define([colorpicker], function(ColorPicker) {
const button = document.getElementById('my_picker');
let picker = new ColorPicker(button, '#ff0000');
}
</syntaxhighlight>
And another example of using https://github.com/itsjavi/bootstrap-colorpicker (that has a [[jQuery]] dependency) with native ES6 JS:
NOTE: It is advised to move away from [[jQuery]] related plugins, as Moodle core is moving away from jQuery.
<br>
<syntaxhighlight lang="javascript">
import ColourPicker from 'local_myplugin/bootstrap-colorpicker';

const myElement = document.querySelector('.myelement');
const picker = new ColourPicker(myElement);
</syntaxhighlight>
== Embedding AMD code in a page ==
So you have created lots of cool Javascript modules. Great. How do we actually call them? Any javascript code that calls an AMD module must execute AFTER the requirejs module loader has finished loading. We have provided a function "js_call_amd" that will call a single function from an AMD module with parameters.
<syntaxhighlight lang="php">
$PAGE->requires->js_call_amd($modulename, $functionname, $params);
</syntaxhighlight>
that will "do the right thing" with your block of AMD code and execute it at the end of the page, after our AMD module loader has loaded.
Notes:
* the $modulename is the 'componentname/modulename' discussed above
* the $functionname is the name of a public function exposed by the amd module.
* the $params is an array of params passed as arguments to the function. These should be simple types that can be handled by json_encode (no recursive arrays, or complex classes please).
* if the size of the params array is too large (> 1Kb), this will produce a developer warning. Do not attempt to pass large amounts of data through this function, it will pollute the page size. A preferred approach is to pass css selectors for DOM elements that contain data-attributes for any required data, or fetch data via ajax in the background.
AMD / JS code can also be embedded on a page via mustache templates
see here: https://docs.moodle.org/dev/Templates#What_if_a_template_contains_javascript.3F
== Troubleshooting ==
=== npm-shrinkwrap.json sha1 / sha512 changes ===
If grunt changes all the hashes in npm-shrinkwrap.json then try this:
rm -rf node_modules && npm i
== But I have a mega JS file I don't want loaded on every page? ==
Loading all JS files at once and stuffing them in the browser cache is the right choice for MOST js files, there are probably some exceptions. For these files, you can rename the javascript file to end with the suffix "-lazy.js" which indicates that the module will not be loaded by default, it will be requested the first time it is used. There is no difference in usage for lazy loaded modules, the require() call looks exactly the same, it's just that the module name will also have the "-lazy" suffix.
== Useful links ==
* [https://assets.moodlemoot.org/sites/15/20171004085436/JavaScript-AMD-with-RequireJS-presented-by-Daniel-Roperto-Catalyst.pdf JavaScript AMD with RequireJS] presented by Daniel Roperto, Catalyst. (MoodleMOOT AU 2017)
* [[Useful_core_Javascript_modules]]
*[[Guide_to_adding_third_party_jQuery_for_AMD]] by Patrick Thibaudeau
*[https://moodle.org/mod/forum/discuss.php?d=378112#p1524459 How to get variables from PHP into javascript AMD modules in M3.5] Justin Hunt, on Moodle forums.
*MDL-67327 JavaScript issues when not following the official documentation, since Moodle 3.8
*[https://moodle.org/mod/forum/discuss.php?d=405829 Error from grunt watch - Moodle 3.9] Forum Discussion
[[Category:AJAX]]
[[Category:Javascript]]

Template:NodeJSExactVersion

2022-06-08T16:55:43Z

Stronk7:

v16.15.1

Moodle and PHP

2022-05-26T21:13:25Z

Stronk7: Add information about php81 status

New PHP versions are [https://www.php.net/supported-versions.php released every year] and come with important improvements and changes compared with previous versions. Moodle tries to support them as soon as possible, always matching them with our own [https://docs.moodle.org/dev/Releases#Version_support scheduled release plans].

This page contains the current status of support for every PHP version and Moodle versions. For details, follow also the epic links below that combine all the changes that were made in Moodle to ensure PHP compatibility. ''(Note: you must be logged in to tracker to see issues in Epics)''

MDL-50565 - '''PHP 7.0 can be used with Moodle 3.0.1, Moodle 3.1 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.4. See [[Moodle and PHP 7.0 details]] for details.

MDL-55120 - '''PHP 7.1 can be used with Moodle 3.2 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.7.

MDL-60279 - '''PHP 7.2 can be used with Moodle 3.4 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.9.

MDL-63420 - '''PHP 7.3 can be used with Moodle 3.6.4, Moodle 3.7 and later releases.''' It is also the '''minimum''' supported version for Moodle 3.11.

MDL-66260 - '''PHP 7.4 can be used with Moodle 3.8.3, Moodle 3.9 and later releases.'''

MDL-70745 - '''PHP 8.0 support is being implemented for Moodle 3.11 and later releases. Hence it's still incomplete and only for development purposes'''

MDL-73016 - '''PHP 8.1 support is being implemented for Moodle 4.1 and later releases. Hence it's still incomplete and only for development purposes'''
[[fr:Moodle et PHP]]

Releases

2022-05-09T07:34:40Z

Stronk7: today... it ended :-)

This page lists all official releases of Moodle, grouped by branch in reverse chronological order.
==Version support==
From Moodle 2.6 onwards, the end of support, both general and security, happens the second Monday of May and November, observing the 12, 18... month periods, no matter if the major release date was moved or not.

The most recent [https://en.wikipedia.org/wiki/Long-term_support long-term support release (LTS)] version is Moodle 3.9.
{| class="wikitable" border="1px solid #dee2e6;"
|-
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Version
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Release status
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Initial release
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:rgba(0, 0, 0, 0.05);" | General support ends
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Security support ends
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 3.9 (LTS)
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#239cae; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 15 June 2020
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 10 May 2021
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 13 November 2023 (ext 6M)
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 3.11
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#f98012; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current stable
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 17 May 2021
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 14 Nov 2022 (ext 6M)
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 13 Nov 2023 (ext 12M)
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |4.0
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#f98012; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current stable
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |19 April 2022
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |8 May 2023
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |13 November 2023
|-
|4.1 (LTS)
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#9cbd50; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Future stable
|November 2022
|November 2023
|November 2025
|}
[[Image:401_release_graph.png|alt=Release graph]]

<b>Release graph key:</b>
{| class="wikitable" border="1px solid #dee2e6;"
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#f98012; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Current stables
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" |Currently supported stable releases.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#239cae; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Current security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | Current release of versions still receiving security-only updates.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#9cbd50; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Future stables
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" |Future point releases receiving bug fixes, as well as security updates.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#316d5e; color:white; adding: .3rem 0.5rem 0.3rem 0.5rem;" |Future security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |Future point releases receiving security-only updates.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#686566; color:white; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Past stables
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" |Previously released versions containing bug fixes, as well as security updates. Updating to a currently supported version is recommended.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#282828; color:white; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Past security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |Previously released versions containing security updates only. Updating to a currently supported version is recommended.
|}

==General release calendar==
These are the target dates for releases. These dates may vary slightly due to unforeseen circumstances.
{| class="wikitable"
|-
!Release type
!Frequency
!Months
|-
|[[Process#Major_release_cycles|Major]] (eg. 3.x)
|6 monthly
|Second Monday of May and November
|-
|[[Process#Stable_maintenance_cycles|Minor]] (Point) (eg. 3.x.y)
| 2 monthly
|Second Monday of July, September, November, March and May.
Third Monday of January.
|}
All releases are preceded by a one week warning. Upcoming release dates can be found in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar] (Note, this is an iCAL link that will try to add the dates to your personal calendar. If you just want to browse the dates online, use [https://calendar.google.com/calendar/embed?src=moodle.com_p4c2oe7hsb77ltaro5qtihb5d4@group.calendar.google.com&pli=1 this link].).

==Moodle 4.0==
{| class="wikitable"
|-
!Moodle 4.0
|19 April 2022
|2022041900
|[[Moodle 4.0 release notes|Release Notes]]
|[https://docs.moodle.org/400/en/Upgrading Upgrading to 4.0]
|-
!Moodle 4.0.1
|9 May 2022
|2022041901
|[[Moodle 4.0.1 release notes|Release Notes]]
|
|}
Bug fixes for general core bugs in 4.0.x will end 8 May 2023 (12 months).
Bug fixes for security issues in 4.0.x will end 13 November 2023 (18 months).

==Moodle 3.11==
{| class="wikitable"
|-
!Moodle 3.11
|17 May 2021
|2021051700
|[[Moodle 3.11 release notes|Release Notes]]
|[https://docs.moodle.org/311/en/Upgrading Upgrading to 3.11]
|-
!Moodle 3.11.1
|12 July 2021
|2021051701
|[[Moodle 3.11.1 release notes|Release Notes]]
|
|-
!Moodle 3.11.2
|29 July 2021
|2021051702
|[[Moodle 3.11.2 release notes|Release Notes]]
|Emergency minor release
|-
! Moodle 3.11.3
|13 September 2021
|2021051703
|[[Moodle 3.11.3 release notes|Release Notes]]
|
|-
! Moodle 3.11.4
|8 November 2021
|2021051704
|[[Moodle 3.11.4 release notes|Release Notes]]
|
|-
! Moodle 3.11.5
|17 January 2022
|2021051705
|[[Moodle 3.11.5 release notes|Release Notes]]
|
|-
! Moodle 3.11.6
|14 March 2022
|2021051706
|[[Moodle 3.11.6 release notes|Release Notes]]
|
|-
! Moodle 3.11.7
|9 May 2022
|2021051707
|[[Moodle 3.11.7 release notes|Release Notes]]
|
|}
Bug fixes for general core bugs in 3.11.x will end 14 Nov 2022 (12 months plus 6 months extension).
Bug fixes for security issues in 3.11.x will end 13 Nov 2023 (18 months plus 12 months extension).

==Moodle 3.10==
{| class="wikitable"
|-
! Moodle 3.10
|9 November 2020
|2020110900
|
[[Moodle 3.10 release notes|Release Notes]]
|[https://docs.moodle.org/310/en/Upgrading Upgrading to 3.10]
|-
!Moodle 3.10.1
|18 January 2021
|2020110901
| [[Moodle 3.10.1 release notes|Release Notes]]
|
|-
!Moodle 3.10.2
|8 March 2021
|2020110902
|[[Moodle 3.10.2 release notes|Release Notes]]
|
|-
! Moodle 3.10.3
|25 March 2021
|2020110903
|[[Moodle 3.10.3 release notes|Release Notes]]
|
|-
!Moodle 3.10.4
|10 May 2021
|2020110904
|[[Moodle 3.10.4 release notes|Release Notes]]
|
|-
!Moodle 3.10.5
|12 July 2021
|2020110905
|[[Moodle 3.10.5 release notes|Release Notes]]
|
|-
!Moodle 3.10.6
|29 July 2021
|2020110906
|[[Moodle 3.10.6 release notes|Release Notes]]
|Emergency minor release
|-
! Moodle 3.10.7
|13 September 2021
|2020110907
|[[Moodle 3.10.7 release notes|Release Notes]]
|
|-
!Moodle 3.10.8
|8 November 2021
|2020110908
|[[Moodle 3.10.8 release notes|Release Notes]]
|
|-
!Moodle 3.10.9
|17 January 2022
|2020110909
|[[Moodle 3.10.9 release notes|Release Notes]]
|
|-
!Moodle 3.10.10
|14 March 2022
|2020110910
|[[Moodle 3.10.10 release notes|Release Notes]]
|
|-
!Moodle 3.10.11
|9 May 2022
|2020110911
|[[Moodle 3.10.11 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.10.x ended 8 November 2021 (12 months).
Bug fixes for security issues in 3.10.x ended 9 May 2022 (18 months).

==Moodle 3.9 (LTS)==
{| class="wikitable"
|-
! Moodle 3.9
|15 June 2020
|2020061500
|[[Moodle 3.9 release notes|Release Notes]]
|
[https://docs.moodle.org/39/en/Upgrading Upgrading to 3.9]
|-
!Moodle 3.9.1
|13 July 2020
|2020061501
|[[Moodle 3.9.1 release notes|Release Notes]]
|
|-
!Moodle 3.9.2
|14 September 2020
|2020061502
| [[Moodle 3.9.2 release notes|Release Notes]]
|
|-
!Moodle 3.9.3
|9 November 2020
|2020061503
| [[Moodle 3.9.3 release notes|Release Notes]]
|
|-
!Moodle 3.9.4
|18 January 2021
|2020061504
|[[Moodle 3.9.4 release notes|Release Notes]]
|
|-
!Moodle 3.9.5
|8 March 2021
|2020061505
|[[Moodle 3.9.5 release notes|Release Notes]]
|
|-
!Moodle 3.9.6
|25 March 2021
|2020061506
|[[Moodle 3.9.6 release notes|Release Notes]]
|
|-
!Moodle 3.9.7
|10 May 2021
|2020061507
|[[Moodle 3.9.7 release notes|Release Notes]]
|
|-
! Moodle 3.9.8
|12 July 2021
|2020061508
|[[Moodle 3.9.8 release notes|Release Notes]]
|
|-
!Moodle 3.9.9
|29 July 2021
|2020061509
|[[Moodle 3.9.9 release notes|Release Notes]]
|Emergency minor release
|-
! Moodle 3.9.10
|13 September 2021
|2020061510
|[[Moodle 3.9.10 release notes|Release Notes]]
|
|-
!Moodle 3.9.11
| 8 November 2021
|2020061511
|[[Moodle 3.9.11 release notes|Release Notes]]
|
|-
!Moodle 3.9.12
| 17 January 2022
|2020061512
|[[Moodle 3.9.12 release notes|Release Notes]]
|-
!Moodle 3.9.13
| 14 March 2022
|2020061513
|[[Moodle 3.9.13 release notes|Release Notes]]
|
|-
!Moodle 3.9.14
| 9 May 2022
|2020061514
|[[Moodle 3.9.14 release notes|Release Notes]]
|
|}
Bug fixes for general core bugs in 3.9.x ended 10 May 2021 (12 months).
Bug fixes for security issues in 3.9.x will end 13 Nov 2023 (36 months plus 6 months extension).
==Moodle 3.8==
{| class="wikitable"
|-
!Moodle 3.8
|18 November 2019
|2019111800
|[[Moodle 3.8 release notes|Release Notes]]
|
[https://docs.moodle.org/38/en/Upgrading Upgrading to 3.8]
|-
!Moodle 3.8.1
|13 January 2020
|2019111801
|[[Moodle 3.8.1 release notes|Release Notes]]
|
|-
!Moodle 3.8.2
|9 March 2020
|2019111802
|[[Moodle 3.8.2 release notes|Release Notes]]
|
|-
!Moodle 3.8.3
|11 May 2020
|2019111803
|[[Moodle 3.8.3 release notes|Release Notes]]
|
|-
!Moodle 3.8.4
|13 July 2020
|2019111804
|[[Moodle 3.8.4 release notes|Release Notes]]
|
|-
!Moodle 3.8.5
|14 September 2020
|2019111805
| [[Moodle 3.8.5 release notes|Release Notes]]
|
|-
!Moodle 3.8.6
|9 November 2020
|2019111806
| [[Moodle 3.8.6 release notes|Release Notes]]
|
|-
!Moodle 3.8.7
|18 January 2021
|2019111807
|[[Moodle 3.8.7 release notes|Release Notes]]
|
|-
!Moodle 3.8.8
|8 March 2021
|2019111808
|[[Moodle 3.8.8 release notes|Release Notes]]
|
|-
!Moodle 3.8.9
|10 May 2021
|2019111809
|[[Moodle 3.8.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.8.x ended 9 November 2020 (12 months).
Bug fixes for security issues in 3.8.x ended 10 May 2021 (18 months).
==Moodle 3.7==
{| class="wikitable"
|-
!Moodle 3.7
|20 May 2019
|2019052000
|[[Moodle 3.7 release notes|Release Notes]]
|[https://docs.moodle.org/37/en/Upgrading Upgrading to 3.7]
|-
!Moodle 3.7.1
|8 July 2019
|2019052001
|[[Moodle 3.7.1 release notes|Release Notes]]
|
|-
!Moodle 3.7.2
|9 September 2019
|2019052002
|[[Moodle 3.7.2 release notes|Release Notes]]
|
|-
!Moodle 3.7.3
|11 November 2019
|2019052003
| [[Moodle 3.7.3 release notes|Release Notes]]
|
|-
!Moodle 3.7.4
|13 January 2020
|2019052004
|[[Moodle 3.7.4 release notes|Release Notes]]
|
|-
!Moodle 3.7.5
|9 March 2020
|2019052005
|[[Moodle 3.7.5 release notes|Release Notes]]
|
|-
!Moodle 3.7.6
|11 May 2020
|2019052006
|[[Moodle 3.7.6 release notes|Release Notes]]
|
|-
!Moodle 3.7.7
|13 July 2020
|2019052007
|[[Moodle 3.7.7 release notes|Release Notes]]
|
|-
!Moodle 3.7.8
|14 September 2020
|2019052008
| [[Moodle 3.7.8 release notes|Release Notes]]
|
|-
!Moodle 3.7.9
|9 November 2020
|2019052009
|[[Moodle 3.7.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.7.x ended 11 May 2020 (12 months).
Bug fixes for security issues in 3.7.x ended 9 November 2020 (18 months).
==Moodle 3.6==
{| class="wikitable"
|-
!Moodle 3.6
| 3 December 2018
|2018120300
|[[Moodle 3.6 release notes|Release Notes]]
|
[https://docs.moodle.org/36/en/Upgrading Upgrading to 3.6]
|-
!Moodle 3.6.1
|5 December 2018
|2018120301
| [[Moodle 3.6.1 release notes|Release Notes]]
|
|-
! Moodle 3.6.2
|14 January 2019
|2018120302
|[[Moodle 3.6.2 release notes|Release Notes]]
|
|-
!Moodle 3.6.3
|11 March 2019
|2018120303
|[[Moodle 3.6.3 release notes|Release Notes]]
|
|-
!Moodle 3.6.4
|13 May 2019
|2018120304
|[[Moodle 3.6.4 release notes|Release Notes]]
|
|-
!Moodle 3.6.5
|8th July 2019
|2018120305
|[[Moodle 3.6.5 release notes|Release Notes]]
|
|-
!Moodle 3.6.6
|9th September 2019
|2018120306
|[[Moodle 3.6.6 release notes|Release Notes]]
|
|-
!Moodle 3.6.7
| 11th November 2019
|2018120307
|[[Moodle 3.6.7 release notes|Release Notes]]
|
|-
!Moodle 3.6.8
|13th January 2020
|2018120308
|[[Moodle 3.6.8 release notes|Release Notes]]
|
|-
!Moodle 3.6.9
|9th March 2020
|2018120309
| [[Moodle 3.6.9 release notes|Release Notes]]
|
|-
!Moodle 3.6.10
|11th May 2020
|2018120310
|[[Moodle 3.6.10 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.6.x ended 11 November 2019 (12 months).
Bug fixes for security issues in 3.6.x ended 11 May 2020 (18 months).
==Moodle 3.5 (LTS)==
{| class="wikitable"
|-
!Moodle 3.5
|17 May 2018
|2018051700
|[[Moodle 3.5 release notes|Release Notes]]
|[https://docs.moodle.org/35/en/Upgrading Upgrading to 3.5]
|-
! Moodle 3.5.1
|9 July 2018
|2018051701
|[[Moodle 3.5.1 release notes|Release Notes]]
|
|-
!Moodle 3.5.2
|10 September 2018
|2018051702
|[[Moodle 3.5.2 release notes|Release Notes]]
|
|-
!Moodle 3.5.3
|12 November 2018
|2018051703
| [[Moodle 3.5.3 release notes|Release Notes]]
|
|-
! Moodle 3.5.4
|14 January 2019
|2018051704
|[[Moodle 3.5.4 release notes|Release Notes]]
|
|-
!Moodle 3.5.5
|11 March 2019
|2018051705
|[[Moodle 3.5.5 release notes|Release Notes]]
|
|-
!Moodle 3.5.6
|13 May 2019
|2018051706
|[[Moodle 3.5.6 release notes|Release Notes]]
|
|-
!Moodle 3.5.7
|8 July 2019
|2018051707
|[[Moodle 3.5.7 release notes|Release Notes]]
|
|-
!Moodle 3.5.8
|9 September 2019
|2018051708
|[[Moodle 3.5.8 release notes|Release Notes]]
|
|-
!Moodle 3.5.9
|11 November 2019
|2018051709
|[[Moodle 3.5.9 release notes|Release Notes]]
|
|-
!Moodle 3.5.10
|13 January 2020
|2018051710
| [[Moodle 3.5.10 release notes|Release Notes]]
|
|-
!Moodle 3.5.11
|9 March 2020
|2018051711
|[[Moodle 3.5.11 release notes|Release Notes]]
|
|-
!Moodle 3.5.12
|11 May 2020
|2018051712
| [[Moodle 3.5.12 release notes|Release Notes]]
|
|-
!Moodle 3.5.13
|13 July 2020
|2018051713
|[[Moodle 3.5.13 release notes|Release Notes]]
|
|-
!Moodle 3.5.14
| 14 September 2020
|2018051714
|[[Moodle 3.5.14 release notes|Release Notes]]
|
|-
!Moodle 3.5.15
|9 November 2020
|2018051715
|[[Moodle 3.5.15 release notes|Release Notes]]
|
|-
!Moodle 3.5.16
|18 January 2021
|2018051716
| [[Moodle 3.5.16 release notes|Release Notes]]
|
|-
!Moodle 3.5.17
|8 March 2021
| 2018051717
|[[Moodle 3.5.17 release notes|Release Notes]]
|
|-
!Moodle 3.5.18
| 10 May 2021
| 2018051718
|[[Moodle 3.5.18 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.5.x ended May 2019 (12 months).
Bug fixes for security issues in 3.5.x ended 10 May 2021 (36 months).
==Moodle 3.4==
{| class="wikitable"
|-
!Moodle 3.4
|13 November 2017
|2017111300
|[[Moodle 3.4 release notes|Release Notes]]
|
[https://docs.moodle.org/34/en/Upgrading Upgrading to 3.4]
|-
! Moodle 3.4.1
|15 January 2018
|2017111301
|[[Moodle 3.4.1 release notes|Release Notes]]
|
|-
!Moodle 3.4.2
|19 March 2018
|2017111302
|[[Moodle 3.4.2 release notes|Release Notes]]
|
|-
!Moodle 3.4.3
|17 May 2018
|2017111303
|[[Moodle 3.4.3 release notes|Release Notes]]
|
|-
! Moodle 3.4.4
|9 July 2018
|2017111304
|[[Moodle 3.4.4 release notes|Release Notes]]
|
|-
!Moodle 3.4.5
|10 September 2018
|2017111305
|[[Moodle 3.4.5 release notes|Release Notes]]
|
|-
!Moodle 3.4.6
|12 November 2018
|2017111306
| [[Moodle 3.4.6 release notes|Release Notes]]
|
|-
! Moodle 3.4.7
|14 January 2019
|2017111307
|[[Moodle 3.4.7 release notes|Release Notes]]
|
|-
!Moodle 3.4.8
|11 March 2019
|2017111308
|[[Moodle 3.4.8 release notes|Release Notes]]
|
|-
!Moodle 3.4.9
|13 May 2019
|2017111309
| [[Moodle 3.4.9 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.4.x ended 12 November 2018 (12 months).
Bug fixes for security issues in 3.4.x ended 13 May 2019 (18 months).
==Moodle 3.3==
{| class="wikitable"
|-
!Moodle 3.3
|15 May 2017
|2017051500
|[[Moodle 3.3 release notes|Release Notes]]
|
[https://docs.moodle.org/33/en/Upgrading Upgrading to 3.3]
|-
!Moodle 3.3.1
|10 July 2017
|2017051501
|[[Moodle 3.3.1 release notes|Release Notes]]
|
|-
!Moodle 3.3.2
|11 September 2017
|2017051502
|[[Moodle 3.3.2 release notes|Release Notes]]
|
|-
!Moodle 3.3.3
|13 November 2017
|2017051503
| [[Moodle 3.3.3 release notes|Release Notes]]
|
|-
! Moodle 3.3.4
|15 January 2018
|2017051504
|[[Moodle 3.3.4 release notes|Release Notes]]
|
|-
!Moodle 3.3.5
|19 March 2018
|2017051505
|[[Moodle 3.3.5 release notes|Release Notes]]
|
|-
!Moodle 3.3.6
|17 May 2018
|2017051506
|[[Moodle 3.3.6 release notes|Release Notes]]
|
|-
! Moodle 3.3.7
|9 July 2018
|2017051507
|[[Moodle 3.3.7 release notes|Release Notes]]
|
|-
!Moodle 3.3.8
|10 September 2018
|2017051508
|[[Moodle 3.3.8 release notes|Release Notes]]
|
|-
! Moodle 3.3.9
|12 November 2018
|2017051509
|[[Moodle 3.3.9 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.3.x ended 17 May 2018 (12 months).
Bug fixes for security issues in 3.3.x ended 12 November 2018 (18 months).
==Moodle 3.2==
{| class="wikitable"
|-
!Moodle 3.2
| 5 December 2016
|2016120500
|[[Moodle 3.2 release notes|Release Notes]]
|[https://docs.moodle.org/32/en/Upgrading Upgrading to 3.2]
|-
!Moodle 3.2.1
|9 January 2017
|2016120501
|[[Moodle 3.2.1 release notes|Release Notes]]
|
|-
!Moodle 3.2.2
|13 March 2017
|2016120502
|[[Moodle 3.2.2 release notes|Release Notes]]
|
|-
!Moodle 3.2.3
|8 May 2017
|2016120503
|[[Moodle 3.2.3 release notes|Release Notes]]
|
|-
!Moodle 3.2.4
|10 July 2017
|2016120504
|[[Moodle 3.2.4 release notes|Release Notes]]
|
|-
!Moodle 3.2.5
|11 September 2017
|2016120505
|[[Moodle 3.2.5 release notes|Release Notes]]
|
|-
!Moodle 3.2.6
|13 November 2017
|2016120506
| [[Moodle 3.2.6 release notes|Release Notes]]
|
|-
! Moodle 3.2.7
|15 January 2018
|2016120507
|[[Moodle 3.2.7 release notes|Release Notes]]
|
|-
!Moodle 3.2.8
|19 March 2018
|2016120508
|[[Moodle 3.2.8 release notes|Release Notes]]
|
|-
!Moodle 3.2.9
|17 May 2018
|2016120509
| [[Moodle 3.2.9 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.2.x ended 13 November 2017 (12 months).
Bug fixes for security issues in 3.2.x ended 17 May 2018 (18 months).
==Moodle 3.1 (LTS)==
{| class="wikitable"
|-
!Moodle 3.1
|23 May 2016
|2016052300
|[[Moodle 3.1 release notes|Release Notes]]
|
[https://docs.moodle.org/31/en/Upgrading Upgrading to 3.1]
|-
!Moodle 3.1.1
|11 July 2016
|2016052301
|[[Moodle 3.1.1 release notes|Release Notes]]
|
|-
!Moodle 3.1.2
|12 September 2016
|2016052302
|[[Moodle 3.1.2 release notes|Release Notes]]
|
|-
!Moodle 3.1.3
|14 November 2016
|2016052303
|[[Moodle 3.1.3 release notes|Release Notes]]
|
|-
!Moodle 3.1.4
|9 January 2017
|2016052304
|[[Moodle 3.1.4 release notes|Release Notes]]
|
|-
!Moodle 3.1.5
|13 March 2017
|2016052305
|[[Moodle 3.1.5 release notes|Release Notes]]
|
|-
!Moodle 3.1.6
|8 May 2017
|2016052306
|[[Moodle 3.1.6 release notes|Release Notes]]
|
|-
!Moodle 3.1.7
|10 July 2017
|2016052307
|[[Moodle 3.1.7 release notes|Release Notes]]
|
|-
!Moodle 3.1.8
|11 September 2017
|2016052308
|[[Moodle 3.1.8 release notes|Release Notes]]
|
|-
!Moodle 3.1.9
|13 November 2017
|2016052309
|[[Moodle 3.1.9 release notes|Release Notes]]
|
|-
!Moodle 3.1.10
|15 January 2018
|2016052310
|[[Moodle 3.1.10 release notes|Release Notes]]
|
|-
! Moodle 3.1.11
|19 March 2018
|2016052311
|[[Moodle 3.1.11 release notes|Release Notes]]
|
|-
!Moodle 3.1.12
|17 May 2018
|2016052312
|[[Moodle 3.1.12 release notes|Release Notes]]
|
|-
!Moodle 3.1.13
|9 July 2018
|2016052313
|[[Moodle 3.1.13 release notes|Release Notes]]
|
|-
!Moodle 3.1.14
|10 September 2018
|2016052314
|[[Moodle 3.1.14 release notes|Release Notes]]
|
|-
! Moodle 3.1.15
|12 November 2018
|2016052315
|[[Moodle 3.1.15 release notes|Release Notes]]
|
|-
!Moodle 3.1.16
|14 January 2019
|2016052316
|[[Moodle 3.1.16 release notes|Release Notes]]
|
|-
! Moodle 3.1.17
|11 March 2019
| 2016052317
|[[Moodle 3.1.17 release notes|Release Notes]]
|
|-
!Moodle 3.1.18
|13 May 2019
|2016052318
|[[Moodle 3.1.18 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.1.x ended 8 May 2017 (12 months).
Bug fixes for security issues in 3.1.x ended 13 May 2019 (36 months).
==Moodle 3.0==
{| class="wikitable"
|-
!Moodle 3.0
|16 November 2015
|2015111600
|[[Moodle 3.0 release notes|Release Notes]]
|[https://docs.moodle.org/30/en/Upgrading Upgrading to 3.0]
|-
!Moodle 3.0.1
|21 December 2015
|2015111601
| [[Moodle 3.0.1 release notes|Release Notes]]
|
|-
! Moodle 3.0.2
|11 January 2016
|2015111602
|[[Moodle 3.0.2 release notes|Release Notes]]
|
|-
!Moodle 3.0.3
|14 March 2016
|2015111603
|[[Moodle 3.0.3 release notes|Release Notes]]
|
|-
!Moodle 3.0.4
|9 May 2016
|2015111604
|[[Moodle 3.0.4 release notes|Release Notes]]
|
|-
!Moodle 3.0.5
|11 July 2016
|2015111605
|[[Moodle 3.0.5 release notes|Release Notes]]
|
|-
!Moodle 3.0.6
|12 September 2016
|2015111606
|[[Moodle 3.0.6 release notes|Release Notes]]
|
|-
!Moodle 3.0.7
|14 November 2016
|2015111607
|[[Moodle 3.0.7 release notes|Release Notes]]
|
|-
!Moodle 3.0.8
|9 January 2017
|2015111608
|[[Moodle 3.0.8 release notes|Release Notes]]
|
|-
!Moodle 3.0.9
|13 March 2017
|2015111609
|[[Moodle 3.0.9 release notes|Release Notes]]
|
|-
!Moodle 3.0.10
|8 May 2017
|2015111610
|[[Moodle 3.0.10 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.0.x ended 14 November 2016 (12 months).
Bug fixes for security issues in 3.0.x ended 8 May 2017 (18 months).
==Moodle 2.9==
{| class="wikitable"
|-
!Moodle 2.9
| 11 May 2015
|2015051100
|[[Moodle 2.9 release notes|Release Notes]]
| [https://docs.moodle.org/29/en/Upgrading_to_Moodle_2.9 Upgrading to 2.9]
|-
! Moodle 2.9.1
|6 July 2015
|2015051101
|[[Moodle 2.9.1 release notes|Release Notes]]
|
|-
!Moodle 2.9.2
|14 September 2015
|2015051102
| [[Moodle 2.9.2 release notes|Release Notes]]
|
|-
!Moodle 2.9.3
|9 November 2015
|2015051103
| [[Moodle 2.9.3 release notes|Release Notes]]
|
|-
! Moodle 2.9.4
|11 January 2016
|2015051104
|[[Moodle 2.9.4 release notes|Release Notes]]
|
|-
!Moodle 2.9.5
|14 March 2016
|2015051105
|[[Moodle 2.9.5 release notes|Release Notes]]
|
|-
!Moodle 2.9.6
|9 May 2016
|2015051106
|[[Moodle 2.9.6 release notes|Release Notes]]
|
|-
!Moodle 2.9.7
|11 July 2016
|2015051107
|[[Moodle 2.9.7 release notes|Release Notes]]
|
|-
!Moodle 2.9.8
|12 September 2016
|2015051108
|[[Moodle 2.9.8 release notes|Release Notes]]
|
|-
! Moodle 2.9.9
|14 November 2016
|2015051109
|[[Moodle 2.9.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.9.x ended 9 May 2016 (12 months).
Bug fixes for security issues in 2.9.x ended 14 November 2016 (18 months).
==Moodle 2.8==
{| class="wikitable"
|-
!Moodle 2.8
|10 November 2014
|2014111000
| [[Moodle 2.8 release notes|Release Notes]]
|[https://docs.moodle.org/28/en/Upgrading_to_Moodle_2.8 Upgrading to 2.8]
|-
!Moodle 2.8.1
|13 November 2014
|2014111001
| [[Moodle 2.8.1 release notes|Release Notes]]
|
|-
!Moodle 2.8.2
|12 January 2015
|2014111002
| [[Moodle 2.8.2 release notes|Release Notes]]
|
|-
!Moodle 2.8.3
|2 February 2015
|2014111003
|[[Moodle 2.8.3 release notes|Release Notes]]
|
|-
!Moodle 2.8.4
|9 March 2015
|2014111004
|[[Moodle 2.8.4 release notes|Release Notes]]
|
|-
!Moodle 2.8.5
|10 March 2015
|2014111005
|[[Moodle 2.8.5 release notes|Release Notes]]
|
|-
!Moodle 2.8.6
|11 May 2015
|2014111006
|[[Moodle 2.8.6 release notes|Release Notes]]
|
|-
! Moodle 2.8.7
|6 July 2015
|2014111007
|[[Moodle 2.8.7 release notes|Release Notes]]
|
|-
!Moodle 2.8.8
|14 September 2015
|2014111008
| [[Moodle 2.8.8 release notes|Release Notes]]
|
|-
!Moodle 2.8.9
|9 November 2015
|2014111009
|[[Moodle 2.8.9 release notes|Release Notes]]
|
|-
!Moodle 2.8.10
|11 January 2016
|2014111010
|[[Moodle 2.8.10 release notes|Release Notes]]
|
|-
!Moodle 2.8.11
|14 March 2016
|2014111011
|[[Moodle 2.8.11 release notes|Release Notes]]
|
|-
!Moodle 2.8.12
|9 May 2016
|2014111012
| [[Moodle 2.8.12 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.8.x ended 9 November 2015 (12 months).
Bug fixes for security issues in 2.8.x ended 9 May 2016 (18 months).
==Moodle 2.7 (LTS)==
{| class="wikitable"
|-
!Moodle 2.7
| 12 May 2014
|2014051200
|[[Moodle 2.7 release notes|Release Notes]]
|[https://docs.moodle.org/27/en/Upgrading_to_Moodle_2.7 Upgrading to 2.7]
|-
! Moodle 2.7.1
|14 July 2014
|2014051201
|[[Moodle 2.7.1 release notes|Release Notes]]
|
|-
!Moodle 2.7.2
|8 September 2014
|2014051202
|[[Moodle 2.7.2 release notes|Release Notes]]
|
|-
!Moodle 2.7.3
|10 November 2014
|2014051203
| [[Moodle 2.7.3 release notes|Release Notes]]
|
|-
!Moodle 2.7.4
|12 January 2015
|2014051204
| [[Moodle 2.7.4 release notes|Release Notes]]
|
|-
!Moodle 2.7.5
|2 February 2015
|2014051205
|[[Moodle 2.7.5 release notes|Release Notes]]
|
|-
!Moodle 2.7.6
|9 March 2015
|2014051206
|[[Moodle 2.7.6 release notes|Release Notes]]
|
|-
!Moodle 2.7.7
|10 March 2015
|2014051207
|[[Moodle 2.7.7 release notes|Release Notes]]
|
|-
!Moodle 2.7.8
|11 May 2015
|2014051208
|[[Moodle 2.7.8 release notes|Release Notes]]
|
|-
!Moodle 2.7.9
|6 July 2015
|2014051209
|[[Moodle 2.7.9 release notes|Release Notes]]
|
|-
!Moodle 2.7.10
| 14 September 2015
|2014051210
|[[Moodle 2.7.10 release notes|Release Notes]]
|
|-
!Moodle 2.7.11
|9 November 2015
|2014051211
|[[Moodle 2.7.11 release notes|Release Notes]]
|
|-
!Moodle 2.7.12
|11 January 2016
|2014051212
|[[Moodle 2.7.12 release notes|Release Notes]]
|
|-
!Moodle 2.7.13
|14 March 2016
|2014051213
|[[Moodle 2.7.13 release notes|Release Notes]]
|
|-
!Moodle 2.7.14
|9 May 2016
|2014051214
| [[Moodle 2.7.14 release notes|Release Notes]]
|
|-
!Moodle 2.7.15
|11 July 2016
|2014051215
|[[Moodle 2.7.15 release notes|Release Notes]]
|
|-
!Moodle 2.7.16
|12 September 2016
|2014051216
|[[Moodle 2.7.16 release notes|Release Notes]]
|
|-
!Moodle 2.7.17
|14 November 2016
|2014051217
|[[Moodle 2.7.17 release notes|Release Notes]]
|
|-
!Moodle 2.7.18
|9 January 2017
|2014051218
|[[Moodle 2.7.18 release notes|Release Notes]]
|
|-
!Moodle 2.7.19
|13 March 2017
|2014051219
|[[Moodle 2.7.19 release notes|Release Notes]]
|
|-
!Moodle 2.7.20
|8 May 2017
|2014051220
| [[Moodle 2.7.20 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.7.x ended 11 May 2015 (12 months).
Bug fixes for security issues in 2.7.x ended 8 May 2017 (36 months).
==Moodle 2.6==
{| class="wikitable"
|-
!Moodle 2.6
|18 November 2013
|2013111800
|[[Moodle 2.6 release notes|Release Notes]]
|[https://docs.moodle.org/26/en/Upgrading_to_Moodle_2.6 Upgrading to 2.6]
|-
!Moodle 2.6.1
|13 January 2014
| 2013111801
| [[Moodle 2.6.1 release notes|Release Notes]]
|
|-
!Moodle 2.6.2
|10 March 2014
|2013111802
|[[Moodle 2.6.2 release notes|Release Notes]]
|
|-
!Moodle 2.6.3
|12 May 2014
|2013111803
|[[Moodle 2.6.3 release notes|Release Notes]]
|
|-
!Moodle 2.6.4
|14 July 2014
|2013111804
|[[Moodle 2.6.4 release notes|Release Notes]]
|
|-
!Moodle 2.6.5
|8 September 2014
|2013111805
|[[Moodle 2.6.5 release notes|Release Notes]]
|
|-
!Moodle 2.6.6
|10 November 2014
|2013111806
|[[Moodle 2.6.6 release notes|Release Notes]]
|
|-
!Moodle 2.6.7
|12 January 2015
|2013111807
|[[Moodle 2.6.7 release notes|Release Notes]]
|
|-
! Moodle 2.6.8
|2 February 2015
|2013111808
|[[Moodle 2.6.8 release notes|Release Notes]]
|
|-
! Moodle 2.6.9
|9 March 2015
|2013111809
|[[Moodle 2.6.9 release notes|Release Notes]]
|
|-
!Moodle 2.6.10
|10 March 2015
|2013111810
| [[Moodle 2.6.10 release notes|Release Notes]]
|
|-
!Moodle 2.6.11
|11 May 2015
|2013111811
|[[Moodle 2.6.11 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 2.6.x ended 10 November 2014 (12 months).
Bug fixes for security issues in 2.6.x ended 11 May 2015 (18 months).
==Moodle 2.5==
{| class="wikitable"
|-
!Moodle 2.5
| 14 May 2013
|2013051400
|[[Moodle 2.5 release notes|Release Notes]]
| [https://docs.moodle.org/25/en/Upgrading_to_Moodle_2.5 Upgrading to 2.5]
|-
! Moodle 2.5.1
|8 July 2013
|2013051401
|[[Moodle 2.5.1 release notes|Release Notes]]
|
|-
!Moodle 2.5.2
|9 September 2013
|2013051402
|[[Moodle 2.5.2 release notes|Release Notes]]
|
|-
!Moodle 2.5.3
|11 November 2013
|2013051403
|[[Moodle 2.5.3 release notes|Release Notes]]
|
|-
!Moodle 2.5.4
|13 January 2014
| 2013051404
| [[Moodle 2.5.4 release notes|Release Notes]]
|
|-
!Moodle 2.5.5
|10 March 2014
|2013051405
|[[Moodle 2.5.5 release notes|Release Notes]]
|
|-
!Moodle 2.5.6
|12 May 2014
|2013051406
|[[Moodle 2.5.6 release notes|Release Notes]]
|
|-
!Moodle 2.5.7
|14 July 2014
|2013051407
|[[Moodle 2.5.7 release notes|Release Notes]]
|
|-
!Moodle 2.5.8
|8 September 2014
|2013051408
|[[Moodle 2.5.8 release notes|Release Notes]]
|
|-
! Moodle 2.5.9
| 10 November 2014
|2013051409
|[[Moodle 2.5.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.5.x ended May 2014 (12 months).
Bug fixes for security issues in 2.5.x ended 10 November 2014 (18 months).
==Moodle 2.4==
{| class="wikitable"
|-
! Moodle 2.4
|3 December 2012
|2012120300
|[[Moodle 2.4 release notes|Release Notes]]
|[https://docs.moodle.org/24/en/Upgrading_to_Moodle_2.4 Upgrading to 2.4]
|-
! Moodle 2.4.1
|14 January 2013
|2012120301
|[[Moodle 2.4.1 release notes|Release Notes]]
|
|-
!Moodle 2.4.2
|11 March 2013
|2012120302
|[[Moodle 2.4.2 release notes|Release Notes]]
|
|-
!Moodle 2.4.3
|18 March 2013
|2012120303
|[[Moodle 2.4.3 release notes|Release Notes]]
|
|-
!Moodle 2.4.4
|14 May 2013
|2012120304
|[[Moodle 2.4.4 release notes|Release Notes]]
|
|-
!Moodle 2.4.5
|8 July 2013
|2012120305
|[[Moodle 2.4.5 release notes|Release Notes]]
|
|-
!Moodle 2.4.6
|9 September 2013
|2012120306
|[[Moodle 2.4.6 release notes|Release Notes]]
|
|-
!Moodle 2.4.7
|11 November 2013
|2012120307
| [[Moodle 2.4.7 release notes|Release Notes]]
|
|-
! Moodle 2.4.8
|13 January 2014
|2012120308
|[[Moodle 2.4.8 release notes|Release Notes]]
|
|-
!Moodle 2.4.9
|10 March 2014
|2012120309
|[[Moodle 2.4.9 release notes|Release Notes]]
|
|-
!Moodle 2.4.10
|12 May 2014
|2012120310
| [[Moodle 2.4.10 release notes|Release Notes]]
|
|-
!Moodle 2.4.11
|14 July 2014
|2012120311
|[[Moodle 2.4.11 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.4.x ended December 2013 (12 months).
Bug fixes for security issues in 2.4.x ended June 2014 (18 months).
==Moodle 2.3==
{| class="wikitable"
|-
!Moodle 2.3
|25 June 2012
|2012062500
|[[Moodle 2.3 release notes|Release Notes]]
| [https://docs.moodle.org/23/en/Upgrading_to_Moodle_2.3 Upgrading to 2.3]
|-
!Moodle 2.3.1
|9 July 2012
|2012062501
|[[Moodle 2.3.1 release notes|Release Notes]]
|
|-
! Moodle 2.3.2
|10 September 2012
|2012062502
|[[Moodle 2.3.2 release notes|Release Notes]]
|
|-
!Moodle 2.3.3
|12 November 2012
|2012062503
|[[Moodle 2.3.3 release notes|Release Notes]]
|
|-
! Moodle 2.3.4
|14 January 2013
|2012062504
|[[Moodle 2.3.4 release notes|Release Notes]]
|
|-
!Moodle 2.3.5
|11 March 2013
|2012062505
|[[Moodle 2.3.5 release notes|Release Notes]]
|
|-
!Moodle 2.3.6
|18 March 2013
|2012062506
|[[Moodle 2.3.6 release notes|Release Notes]]
|
|-
!Moodle 2.3.7
|14 May 2013
|2012062507
|[[Moodle 2.3.7 release notes|Release Notes]]
|
|-
!Moodle 2.3.8
|8 July 2013
|2012062508
|[[Moodle 2.3.8 release notes|Release Notes]]
|
|-
!Moodle 2.3.9
|9 September 2013
|2012062509
|[[Moodle 2.3.9 release notes|Release Notes]]
|
|-
! Moodle 2.3.10
|11 November 2013
|2012062510
|[[Moodle 2.3.10 release notes|Release Notes]]
|
|-
!Moodle 2.3.11
|13 January 2014
|2012062511
|[[Moodle 2.3.11 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.3.x ended June 2013 (12 months).
Bug fixes for security issues in 2.3.x ended December 2013 (18 months).
==Moodle 2.2==
{| class="wikitable"
|-
! Moodle 2.2
|5 December 2011
|2011120500
|[[Moodle 2.2 release notes|Release Notes]]
|[https://docs.moodle.org/22/en/Upgrading_to_Moodle_2.2 Upgrading to 2.2]
|-
!Moodle 2.2.1
|9 January 2012
|2011120501
|[[Moodle 2.2.1 release notes|Release Notes]]
|
|-
!Moodle 2.2.2
|12 March 2012
|2011120502
|[[Moodle 2.2.2 release notes|Release Notes]]
|
|-
!Moodle 2.2.3
|14 May 2012
|2011120503
|[[Moodle 2.2.3 release notes|Release Notes]]
|
|-
! Moodle 2.2.4
|9 July 2012
|2011120504
|[[Moodle 2.2.4 release notes|Release Notes]]
|
|-
!Moodle 2.2.5
|10 September 2012
|2011120505
|[[Moodle 2.2.5 release notes|Release Notes]]
|
|-
!Moodle 2.2.6
|12 November 2012
|2011120506
| [[Moodle 2.2.6 release notes|Release Notes]]
|
|-
! Moodle 2.2.7
|14 January 2013
|2011120507
|[[Moodle 2.2.7 release notes|Release Notes]]
|
|-
!Moodle 2.2.8
|11 March 2013
|2011120508
|[[Moodle 2.2.8 release notes|Release Notes]]
|
|-
!Moodle 2.2.9
|18 March 2013
|2011120509
|[[Moodle 2.2.9 release notes|Release Notes]]
|
|-
!Moodle 2.2.10
|14 May 2013
| 2011120510
|[[Moodle 2.2.10 release notes|Release Notes]]
|
|-
!Moodle 2.2.11
|8 July 2013
|2011120511
|[[Moodle 2.2.11 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.2.x ended December 2012 (12 months).
Bug fixes for security issues in 2.2.x ended June 2013 (18 months).
==Moodle 2.1==
{| class="wikitable"
|-
!Moodle 2.1
| 1 July 2011
|2011070100
|[[Moodle 2.1 release notes|Release Notes]]
|[https://docs.moodle.org/21/en/Upgrading_to_Moodle_2.1 Upgrading to 2.1]
|-
! Moodle 2.1.1
|1 August 2011
|2011070101
| [[Moodle 2.1.1 release notes|Release Notes]]
|
|-
!Moodle 2.1.2
|10 October 2011
|2011070102
|[[Moodle 2.1.2 release notes|Release Notes]]
|
|-
!Moodle 2.1.3
|28 November 2011
|2011070103
|[[Moodle 2.1.3 release notes|Release Notes]]
|
|-
!Moodle 2.1.4
|9 January 2012
|2011070104
|[[Moodle 2.1.4 release notes|Release Notes]]
|
|-
!Moodle 2.1.5
|12 March 2012
|2011070105
|[[Moodle 2.1.5 release notes|Release Notes]]
|
|-
!Moodle 2.1.6
|14 May 2012
|2011070106
|[[Moodle 2.1.6 release notes|Release Notes]]
|
|-
! Moodle 2.1.7
|9 July 2012
|2011070107
|[[Moodle 2.1.7 release notes|Release Notes]]
|
|-
!Moodle 2.1.8
|10 September 2012
|2011070108
|[[Moodle 2.1.8 release notes|Release Notes]]
|
|-
!Moodle 2.1.9
|12 November 2012
|2011070109
|[[Moodle 2.1.9 release notes|Release Notes]]
|
|-
!Moodle 2.1.10
|14 January 2013
|2011070110
|[[Moodle 2.1.10 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.1.x ended June 2012 (12 months).
Bug fixes for security issues in 2.1.x ended December 2012 (18 months).
==Moodle 2.0==
{| class="wikitable"
|-
!Moodle 2.0
|24 November 2010
|2010112400
| [[Moodle 2.0 release notes|Release Notes]]
|[https://docs.moodle.org/20/en/Upgrading_to_Moodle_2.0 Upgrading to 2.0]
|-
!Moodle 2.0.1
|25 December 2010
|2010122500
|[[Moodle 2.0.1 release notes|Release Notes]]
|
|-
!Moodle 2.0.2
|21 February 2011
|2011022100
|[[Moodle 2.0.2 release notes|Release Notes]]
|
|-
!Moodle 2.0.3
|5 May 2011
|2011033003
|[[Moodle 2.0.3 release notes|Release Notes]]
|
|-
! Moodle 2.0.4
|1 August 2011
|2011033004
| [[Moodle 2.0.4 release notes|Release Notes]]
|
|-
!Moodle 2.0.5
|10 October 2011
|2011033005
|[[Moodle 2.0.5 release notes|Release Notes]]
|
|-
!Moodle 2.0.6
|28 November 2011
|2011033006
|[[Moodle 2.0.6 release notes|Release Notes]]
|
|-
!Moodle 2.0.7
|9 January 2012
|2011033007
|[[Moodle 2.0.7 release notes|Release Notes]]
|
|-
!Moodle 2.0.8
|12 March 2012
|2011033008
|[[Moodle 2.0.8 release notes|Release Notes]]
|
|-
!Moodle 2.0.9
|14 May 2012
|2011033009
|[[Moodle 2.0.9 release notes|Release Notes]]
|
|-
!Moodle 2.0.10
|9 July 2012
|2011033010
|[[Moodle 2.0.10 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.0.x ended December 2011 (12 months).
Bug fixes for security issues in 2.0.x ended June 2012 (18 months).
==Moodle 1.9==
{| class="wikitable"
|-
!Moodle 1.9
|3 March 2008
|2007101509
|[[Moodle 1.9 release notes|Release Notes]]
|[https://docs.moodle.org/19/en/Upgrading_to_Moodle_1.9 Upgrading to 1.9]
|-
!Moodle 1.9.1
|15 May 2008
| 2007101512
|[[Moodle 1.9.1 release notes|Release Notes]]
|
|-
! Moodle 1.9.2
|11 July 2008
|2007101520
|[[Moodle 1.9.2 release notes|Release Notes]]
|
|-
!Moodle 1.9.3
|15 October 2008
|2007101530
|[[Moodle 1.9.3 release notes|Release Notes]]
|
|-
!Moodle 1.9.4
|28 January 2009
|2007101540
|[[Moodle 1.9.4 release notes|Release Notes]]
|
|-
!Moodle 1.9.5
|13 May 2009
|2007101550
|[[Moodle 1.9.5 release notes|Release Notes]]
|
|-
!Moodle 1.9.6
|21 October 2009
|2007101560
|[[Moodle 1.9.6 release notes|Release Notes]]
|
|-
!Moodle 1.9.7
|25 November 2009
|2007101570
|[[Moodle 1.9.7 release notes|Release Notes]]
|
|-
!Moodle 1.9.8
|25 March 2010
|2007101580.00
|[[Moodle 1.9.8 release notes|Release Notes]]
|
|-
! Moodle 1.9.9
| 8 June 2010
| 2007101590.00
| [[Moodle 1.9.9 release notes|Release Notes]]
|
|-
!Moodle 1.9.10
|25 October 2010
|2007101591.00
|
[[Moodle 1.9.10 release notes|Release Notes]]
|
|-
!Moodle 1.9.11
|21 February 2011
|2007101591.02
|[[Moodle 1.9.11 release notes|Release Notes]]
|
|-
! Moodle 1.9.12
|10 May 2011
|2007101591.03
|[[Moodle 1.9.12 release notes|Release Notes]]
|
|-
!Moodle 1.9.13
|1 August 2011
|2007101591.04
|[[Moodle 1.9.13 release notes|Release Notes]]
|
|-
!Moodle 1.9.14
|10 October 2011
|2007101591.06
|
[[Moodle 1.9.14 release notes|Release Notes]]
|
|-
!Moodle 1.9.15
|28 November 2011
| 2007101591.07
| [[Moodle 1.9.15 release notes|Release Notes]]
|
|-
!Moodle 1.9.16
|9 January 2012
|2007101591.10
|[[Moodle 1.9.16 release notes|Release Notes]]
|
|-
! Moodle 1.9.17
|12 March 2012
|2007101591.12
|[[Moodle 1.9.17 release notes|Release Notes]]
|
|-
!Moodle 1.9.18
|14 May 2012
|2007101591.16
|[[Moodle 1.9.18 release notes|Release Notes]]
|
|-
! Moodle 1.9.19
|9 July 2012
|2007101592.00
|[[Moodle 1.9.19 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 1.9.x has ended June 2011 (3.5 years).
Bug fixes for security issues in 1.9.x by Moodle HQ ended June 2012 (4.5 years).
Bug fixes for security issues in 1.9.19+ branch by [http://catalyst.net.nz Catalyst IT] ended [http://moodle.org/mod/forum/discuss.php?d=199706 Dec 2013] (6 years).
==Moodle 1.8 ==
*[[Moodle 1.8 release notes|Moodle 1.8]] - 30 March 2007
*[[Moodle 1.8.1 release notes|Moodle 1.8.1]] - 14 June 2007
*[[Moodle 1.8.2 release notes|Moodle 1.8.2]] - 8 July 2007
*[[Moodle 1.8.3 release notes|Moodle 1.8.3]] - 11 October 2007
*[[Moodle 1.8.4 release notes|Moodle 1.8.4]] - 11 January 2008
*[[Moodle 1.8.5 release notes|Moodle 1.8.5]] - 8 April 2008
*[[Moodle 1.8.6 release notes|Moodle 1.8.6]] - 11 July 2008
*[[Moodle 1.8.7 release notes|Moodle 1.8.7]] - 15 October 2008
*[[Moodle 1.8.8 release notes|Moodle 1.8.8]] - 28 January 2009
*[[Moodle 1.8.9 release notes|Moodle 1.8.9]] - 15 May 2009
*[[Moodle 1.8.10 release notes|Moodle 1.8.10]] - 26 October 2009
*[[Moodle 1.8.11 release notes|Moodle 1.8.11]] - 25 November 2009
*[[Moodle 1.8.12 release notes|Moodle 1.8.12]] - 27 March 2010
*[[Moodle 1.8.13 release notes|Moodle 1.8.13]] - 8 June 2010
*[[Moodle 1.8.14 release notes|Moodle 1.8.14]] - 3 December 2010
*Support has ended

==Moodle 1.7==
*[[Moodle 1.7 release notes|Moodle 1.7]] - 7 November 2006
*[[Moodle 1.7.1 release notes|Moodle 1.7.1]] - 17 January 2007
*[[Moodle 1.7.2 release notes|Moodle 1.7.2]] - 30 March 2007
*[[Moodle 1.7.3 release notes|Moodle 1.7.3]] - 11 October 2007
*[[Moodle 1.7.4 release notes|Moodle 1.7.4]] - 11 January 2008
*[[Moodle 1.7.5 release notes|Moodle 1.7.5]] - 11 July 2008
*[[Moodle 1.7.6 release notes|Moodle 1.7.6]] - 15 October 2008
*[[Moodle 1.7.7 release notes|Moodle 1.7.7]] - 28 January 2009
*Support has ended
==Moodle 1.6==
*[[Moodle 1.6 release notes|Moodle 1.6]] - 20 June 2006
*[[Moodle 1.6.1 release notes|Moodle 1.6.1]] - 20 July 2006
*[[Moodle 1.6.2 release notes|Moodle 1.6.2]] - 12 September 2006
*[[Moodle 1.6.3 release notes|Moodle 1.6.3]] - 10 October 2006
*[[Moodle 1.6.4 release notes|Moodle 1.6.4]] - 17 January 2007
*[[Moodle 1.6.5 release notes|Moodle 1.6.5]] - 30 March 2007
*Moodle 1.6.6 - 11 January 2008
*Moodle 1.6.7 - 11 July 2008
*[[Moodle 1.6.8 release notes|Moodle 1.6.8]] - 15 October 2008
*[[Moodle 1.6.9 release notes|Moodle 1.6.9]] - 28 January 2009
* Support has ended
==Moodle 1.5==
*[[Moodle 1.5 release notes|Moodle 1.5]] - 5 June 2005
*[[Moodle 1.5.1 release notes|Moodle 1.5.1]] - 8 July 2005
*[[Moodle 1.5.2 release notes|Moodle 1.5.2]] - 16 July 2005
*[[Moodle 1.5.3 release notes|Moodle 1.5.3]] - 11 November 2005
*[[Moodle 1.5.4 release notes|Moodle 1.5.4]] - 21 May 2006
*Support has ended
==Moodle 1.4==
*Moodle 1.4 - 31 August 2004
*Moodle 1.4.1 - 12 September 2004
*Moodle 1.4.2 - 5 November 2004
*Moodle 1.4.3 - 21 December 2004
*Moodle 1.4.4 - 7 March 2005
*[[Moodle 1.4.5 release notes|Moodle 1.4.5]] - 7 May 2005
*Support has ended
==Moodle 1.3==
*Moodle 1.3 - 25 May 2004
* Moodle 1.3.1 - 4 June 2004
*Moodle 1.3.2 - 9 July 2004
*Moodle 1.3.3 - 16 July 2004
* Moodle 1.3.4 - 11 August 2004
*Moodle 1.3.5 - 9 September 2004
*Support has ended
==Moodle 1.2==
*Moodle 1.2 - 20 March 2004
*Moodle 1.2.1 - 25 March 2004
*Support has ended
==Moodle 1.1==
*Moodle 1.1 - 29 August 2003
*Moodle 1.1.1 - 11 September 2003
*Support has ended
== Moodle 1.0==
*Moodle 1.0 - 20 August 2002
*Moodle 1.0.1 - 26 August 2002
*Moodle 1.0.2 - 2 September 2002
*Moodle 1.0.3 - 5 September 2002
*Moodle 1.0.4 - 10 September 2002
*Moodle 1.0.5 - 27 September 2002
* Moodle 1.0.6 - 26 October 2002
::1.0.6.1 - 6 November 2002
::1.0.6.2 - 11 November 2002
::1.0.6.3 - 14 November 2002
::1.0.6.4 - 25 November 2002
*Moodle 1.0.7 - 9 December 2002
*Moodle 1.0.8 - 7 January 2003
*Moodle 1.0.9 - 30 May 2003
*Support has ended
==See also==
*[[Roadmap]] - future versions
*[[Moodle versions]] - an explanation of how our versions work plus version numbers for each release (for $plugin->requires)
[[Category:Release notes]]
[[Category:Core development]]
[[fr:Historique des versions]]
[[es:dev/Historia de las versiones]]
[[de:Versionshistorie]]

Release process

2022-05-04T07:04:36Z

Stronk7: Added link to en_fix issues

== 8 weeks prior ==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Recurring release epics review:
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous deprecation epics are going] and share about them.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Ensure we are running latest/good behat, phpunit and nodejs (npm) versions.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm external testers daily availability from -6w to release (internally with dev manager and then, externally, with contractors). They start in just 2 weeks!
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| - Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249.
- Remind devs:
* To label issues qa_test_required when a new feature/improvement is landing without automated tests. Also add a comment advising exactly what should be covered in the QA test e.g. steps 6-10 in testing instructions.
* The best possible lang strings land at first attempt. Given the proximity of the major release and to facilitate the work of translators and others... the sooner, the better, instead of relying on (late) en_fixes too much.
| Testing Maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| - Create a "Must fix for X.Y" version in the Tracker and adjust the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Set%20integration%20priority%20to%20one/ "TR - Set integration priority to one"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20reopened%20out%20from%20current/ "TR - Move reopened out from current"] jobs in '''all CI servers''' to point to it.
- Apply the following changes to filters and dashboards:
* Edit the [https://tracker.moodle.org/issues/?filter=21363 All "must fix" issues] filter used both in the release dashboard and to detect wrong uses of must-fix issues. Note that, since 3.7, this filter is fully automated and does not need edition (uses regexp to catch all must fix versions).
* Comment about its creation within HQ, to get people applying for it.
* Verify that these filters ([https://tracker.moodle.org/issues/?filter=18596 1], [https://tracker.moodle.org/issues/?filter=18594 2] and [https://tracker.moodle.org/issues/?filter=18861 3]), used in the [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard], are working ok (they should be, automatically based in the filter edited in the previous point).
* Rename [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard] to point to incoming release (QA part of the dashboard will not work yet)
| Integration Team
|}
==7 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze.
| Head of LMS
|-
| 2.
| style="text-align:center" | ✓
|
| Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20qa_test_required%20AND%20status%20%3D%20Closed closed qa_test_required-labelled issues] and create new QA tests as required.
| Testing Maintainer
|-
|}
==6 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| The [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period Continuous Integration] period begins. Warn about it everywhere (telegram, exposed posts...).
Rolling (on demand, beta, rc... all them together with stable weeklies) happens often (Tuesday & Friday are the usual days). All the team is on integration 100% since this week and until the end of continuous.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Create the next "X.Y+1" (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Warn external developers about the impending code freeze in a post to the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Let the community know [[QA testing]] starts in two weeks and how they can participate.
| Community Manager
|}
==5 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Confirm the code freeze by replying to the previous warning in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum].
| Development manager
|-
| 2.
| style="text-align:center" | ✓
|
| This week, once the freeze has happened at 11:00 UTC:
* The [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job has to be disabled.
* Immediately after that, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration] job must be enabled and executed, only once, and all the candidate issues already @ integration will come to the current queue. All them did the freeze.
* Once run, disable the job again to avoid executing it by mistake.
* Once the previous job has ended, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job, in charge of managing the integration queues after freeze, will be enabled (until the end of on-sync). It performs some tasks like moving important (must fix, qa, security...) issues to the current integration queue and also keep if fed by priority when there are few issues remaining. '''Don't forget''' to configure the "releasedate" date to get it automatically holding issues the last week (instead of moving them to current integration) and also processing issues over the on-sync (after release) period.
Irrespectively from any automation, issues can, also, be manually picked for integration until the post-release "On Sync" period ends, usually 2 weeks after release.

Review all the new features and improvements so, everything "unrelated" with the release, is given the "integration_held" label. That means that will be ignored unless there is an [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period unhold request process] started on them.

Dev leaders promptly vote on held issues labelled with unhold_requested label and decide whether they can be allowed to break the freeze.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Prepare a fresh installation of the [http://qa.moodle.net QA site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.
| QA Master Site Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Begin reviewing [https://lang.moodle.org/mod/forum/view.php?id=7 new and changed English language strings] ready for en_fix to be merged 2 weeks prior.
| English fixes lang pack maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| Review standards certifications (Open Badges, LTI, etc) and schedule in recertification to be performed.
| Development Manager
|}
==4 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Start reviewing fixed issues and add the release_notes label to all issues to be listed in the release notes.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Review requirements for adding user tours for new features in the upcoming release (clone of MDL-72783). Review existing tours and remove very old ones (clone of MDL-72781)
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
|
| Beta release (The Moodle release tool - mdlrelease - manages it): Release normal weeklies but with these changes in the master branch being considered all the time, until we are feature complete (can happen @ -4w - ideally - but also later):
* version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Once the beta is available create the "[https://docs.google.com/spreadsheets/d/1TcMJT3o2Cnyq006lmLWrXJeNQQzyNXz2E_Vbc8ff5EE/edit?usp=sharing|Release testing matrix for X.Y.0]" and share it @ HQ & Dev. chat.
* (Optionally) Announce Beta release in forums (ideally once packages are available).
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Clone MDL-72815 for the X.Y release, adding there all the debugging / PHP notices happening in the web server logs while running tests.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
|
| Release candidates release (The Moodle release tool - mdlrelease - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:
* version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-rcZ" (and MOODLE_XY_RCZ as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).
* Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.
* These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&id=1532512
| Plugins Liaison
|-
| 7.
| style="text-align:center" | ✓
|
| Push any plugins to the plugins database which were previously a part of core.
| Plugins Liaison
|-
| 8.
| style="text-align:center" | ✓
|
| Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [[New docs version process]].
| Community Manager
|-
| 9.
| style="text-align:center" | ✓
|
| Create new QA test cycle and post in moodle.org front page news forum about [[QA testing]].
| Testing Maintainer
|-
| 10.
| style="text-align:center" | ✓
|
| Invite community volunteers to start [[QA testing]].
| Community Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Modify [https://tracker.moodle.org/issues/?filter=11824 Current QA cycle filter] to link to the new QA test cycle
| Testing Maintainer
|-
| 12.
| style="text-align:center" | ✓
|
| Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.
| Testing Maintainer
|-
| 13.
| style="text-align:center" | ✓
|
| Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately.
| Development Manager
|-
| 14.
| style="text-align:center" | ✓
|
| Review the [https://tracker.moodle.org/issues/?filter=17705&jql=filter%20%3D%2011701%20AND%20type%20!%3D%20Bug list of features and improvements submitted before code freeze] which are awaiting integration review and decide on related QA tests to be put on hold.
| Development Manager
|}
==3 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Ask developers to begin QA tests marked [https://tracker.moodle.org/issues/?filter=22055 external_skipped] then [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20test_server_required%20 test_server_required tests] and [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20credentials_required credentials_required tests].
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Create new en and de Moodle Docs version wikis.
| Moodle Docs Maintainer
|-
| 3.
| style="text-align:center" | ✓
|
| Go through all points listed under 3 weeks prior in [[New docs version process]].
| Community Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Review issues with labelled with [https://tracker.moodle.org/issues/?filter=11824&jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC dev_docs_required], prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated.
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify how everything is going and, before the end of the week, decide (dev leaders & integrators) if there are real reasons for delaying any release. Whenever a delay is agreed, run the ''"Release delaying process"'' (doc) actions ASAP.

'''Important note:''' ASAP stands for as soon as possible ;-), the delay needs to happen before the last week before release begins (there are flows changing that week requiring the decision and actions to be taken and applied earlier).
| Development Manager
|}
==2 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
|
Check the number of open QA tests. Depending on the amount of work involved, encourage HQ developers to assist from the start of the week or later in the week in order to achieve the target of 100% pass rate by the end of the week.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
|
Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Merge [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc fixes from en_fix] pack and then integrate them.
| AMOS Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Give Partners complete brandable Marketing pack for release including list and description of major new features.
| Marketing Manager
|-
| 5.
| style="text-align:center" | ✓
|
| Label (ui_change) in the Tracker all pending issues having '''noticeable UI modifications''' and track them in the "[https://docs.google.com/spreadsheets/d/18xZf9OgKrndi7CwSTwjwjF_rzGYCWFuGjNNaaDVZDM4/edit?usp=sharing Late landing UI changes]" sheet, in order to have all the associated docs, screenshots, videos under control. The Integration and Documentation people will try to '''keep the sheet updated until release'''.
|Integration Team
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
|
For major releases, use (clone if needed) MDL-72836 to keep the security.txt files in all supported branches updated. For minor releases, also check the security.txt expiry dates in all security supported branches in case known release delays will result in any security.txt expiring before the next release - in that case relevant branches should also be updated.
| Security Officer
|}

==1 week prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Clone MDL-71583 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on the [http://moodle.org/mod/forum/view.php?id=55 General Developer forum] and [https://moodleassociation.org/ MUA website].
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on Twitter and other outlets.
| Marketing Officer
|-
| 7.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Identify security issues that need to be integrated using the [https://tracker.moodle.org/issues/?filter=21712 security issues under integration filter] (includes held, being integrated and ready issues).
* Integrate from provided patches into supported branches (including branches supported only for security issues).
* Ensure security issues are given priority in weekly integration and testing. Note that the --weekly releases to be performed this week are 100% normal and cover the standard (supported) branches. security branches will come as part of the release process later in the week.
| Integration Team
|-
| 8.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Collect security issues into a clone of the [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20level%20is%20not%20EMPTY%20AND%20summary%20~%20%22security%20advisories%22%20ORDER%20BY%20updated%20DESC last advisory in the list] to prepare for release of Security Advisories.
* Determine which security issues will be integrated.
* Request CVE Identifiers by emailing issue descriptions to [mailto:secalert@redhat.com secalert@redhat.com] with a message like... <tt> The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC.</tt> The email subject should include the characters <tt>[vs]</tt>. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available (since 2015 we request identifiers from redhat and not from distros).
* Post security issues as a reply to the "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Release notes tasks:
* Review and complete the [[Releases|release notes]], making sure that issues have easily understandable summaries. Aim to have the release notes mostly complete on the Wednesday before release, and fully complete on the Friday, to give translators time to translate them.
* Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
| Development Manager
|-
| 10.
| style="text-align:center" | ✓
|
| Review the following issues:
* Check on the [https://tracker.moodle.org/issues/?filter=21363 "Must fix for X.Y version"]. Filter out unrealistic issues.
* Check on the [https://tracker.moodle.org/issues/?filter=22350 "Bug issues held last week before release"]. Consider to request the unholding of release related/blocker ones.
| Development Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Upgrade moodle.org to beta release
|
|-
| 12.
| style="text-align:center" | ✓
|
| Prepare pull requests for CI Repositories:
* MR1: Create a new version, with unit tests, in Jobs repository ([https://git.in.moodle.com/integration/nightlyjobs/merge_requests/24 see example from 3.11 release])
* MR2: Create a new symlink for the version in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/41 see example from 3.11 release])
* MR3: Configure CIs to skip language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/35 see example from 3.10 release])
* MR4: Configure CIs to stop skipping language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository for after on-sync ([https://github.com/moodlehq/moodle-ci-runner/pull/40 see example from 3.10 release]) -- Note: This change should be based on the previous and only applied when the lang packs corresponding to the version being released are available.
| Integration Team
|-
| 13.
| style="text-align:center" | ✓
|
| Go through all points listed under 1 week prior in [[New docs version process]].
| Community Manager
|-
|}
==Releasing==
===Packaging===
This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Check list:
* Make sure there are no real blockers introduced in the last weekly (install / upgrade ...).
* Confirm that the latest [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc en_fix changes]have been generated and integrated.
* Verify that [https://tracker.moodle.org/issues/?jql=text%20~%20%22%2BPrepare%20%2Bsecurity%20%2Badvisories%20%2Bfriends%22%20ORDER%20BY%20updated%20DESC all security issues] have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify all unit tests and integration tests have passed (check all current CI servers in use).
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Verify QA tests have passed.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Timing prerequisites (don't continue with the process if not within the time window!):
# Latest weeklies before the minor/major releases must be done (moodle-package-extract-and-postprocess email should confirm this has happened around 09:00 Australia/Perth).
# Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).
(in practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). Breaking any of these rules will require manual operation in the server, forcing repackaging and releasing.

Follow the "mdlrelease" steps:
* Run the '''prerelease.sh''' script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg, travis changes (only for majors)... Triple verify all changes are correct! (can use the --show option to inspect them). Follow the on-screen instructions.
* Push changes to integration.git (but tags).
For major releases, only when a new STABLE branch has been created:
* Run the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
* Push changes to integration.git - note this will lead to the "versions checker" failing for master, no problem, it will be fixed by the 1st cloned issue at #12 below).
* Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY stable branch.
* Update the old CI server(s) by cloning all the "master" jobs to a new "MXY" view (trick: do it down-top, way easier). Don't forget to re-chain the jobs properly.
** Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE.
** Configure the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
** Run all them.
* Update the new CI infrastructure:
** MR1: Merge pull request for new version in [https://git.in.moodle.com/integration/nightlyjobs CI Jobs Repository]
** MR2: Merge pull request for symlink in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
** MR3: Merge pull request for skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
** Clone all the "B - master" jobs to a new "B - XY" view (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20view/ maintenance job] to perform the operation).
Both with minors and majors, continue with the "mdlrelease" steps:
* Once CI servers have ended and all jobs have passed, '''push tags''' and run the '''release.sh''' script to apply the changes to moodle.git.
* If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
* Don't forget the "[https://github.com/moodlehq/mdlrelease/#after-the-release After the release]" tasks.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "git repos updated & tagged" message on the [https://partners.moodle.com/mod/forum/view.php?id=810 Partner forum]
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| In the [https://github.com/moodlehq/moodle-performance-comparison performance comparison repository], set the new release commit hash as $basecommit in the master branch and create a new MOODLE_XY_STABLE branch from it. ([https://github.com/moodlehq/moodle-performance-comparison/commit/7c875f03e52641f69674235a8947131d77691299 example]). Also, apply it to the current performance testing infrastructure.
| Integration Team
|-
| 7.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email).
| Integration Team
|-
| 8.
| style="text-align:center" | ✓
|
|
* Create new windows packager script (cloning the current master one and configuring it).
* Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Push it. Next time the plugin is deployed (normally 1 week after release, aprox.) the stats will start showing the new branch statistics.
| Integration Team
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| In the Tracker...
* Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Plugins project].
* Archive all versions but the ones being released, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
* Remove from all screens the custom fields belonging to 100% unsupported branches.
For major releases only:
* Release and archive the [https://tracker.moodle.org/issues/?jql=affectedVersion%20~%20%22must%20fix%20for*%22%20OR%20fixVersion%20~%20%22must%20fix%20for*%22 "Must fix for X.Y" versions], it must be empty to do so.
| Integration Team
|-
| 10.
| style="text-align:center" | ✓
|
|
* Create the new "Pull X.Y Branch" and "Pull X.Y Diff URL" custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Re-index Tracker.
* In the CI server edit the [http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ "Bulk precheck issues"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(awaiting_integration)/ "Pre-launch DEV jobs (awaiting_integration)"], [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(list_of_mdls)/ "Pre-launch DEV jobs (list_of_mdsl)"] and [https://ci.moodle.org/view/Tracker/job/STR%20-%20Bulk%20pre-launch%20SDEV%20jobs%20(list_of_mdls)/ "Pre-launch SDEV jobs (list_of_mdsl)"] jobs to make them meet the new "Pull X.Y Branch" field created. At the same time, remove from those jobs any branch belonging to 100% unsupported branches.
* Edit the "Tracker - CI - Check marked as integrated" job ([https://ci.moodle.org/view/Tracker/job/TR%20-%20Check%20marked%20as%20integrated/ link]) to configure the development branches (devbranches) (39, 310, 311, 400...) actually active. Normally only the branch corresponding to master, but also accepts a comma separated list when under parallel development ("310,400" or "311,400" for example). Ordered by planned release date.
* Check/configure (again, this may be has been already executed few steps above) the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
| Integration Team
|-
| 11.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| In the Tracker...
For major releases only:
* Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.
* Adjust the [https://tracker.moodle.org/issues/?filter=17528 Latest regressions] filter (requires login).
For all releases:
* Verify how the "X.Y regressions" versions [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(versionMatches(%22.*regressions%22)) are going] (requires login) and ping Development Managers about. Package and archive them once empty.
| Integration Team
|-
| 12.
| style="text-align:center" | ✓
|
| Clone MDL-74509 and MDL-74510, to be resolved ASAP.
| Integration Team
|-
| 13.
| style="text-align:center" | ✓
|
|
* Create the new MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security repo (branching from the just created upstream MOODLE_XY_STABLE branch).
* Cherry pick any security commit present in the security repository's master branch to the new MOODLE_XY_STABLE branch (note that normally there should not be any, see point #1 check list above).
* Verify the new security jobs exist for the new branch and check it's working in all servers, keeping only enabled the public one.
| Integration Team
|-
| 14.
| style="text-align:center" | ✓
|
| Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 )
| Integration Team
|}
===Release day===
Usually on Monday
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| The execution of "moodle-package-extract-and-postprocess X" script may be needed if the releases '''are not going to be published on Monday''' but another weekday (X is the weekday, (1-7) starting in Monday).
By default it happens automatically around 09:00 AM Perth/Australia time (check emails then).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify release status, download pages and windows packages.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Notify all registered sys admins, including security notes with CVE identifiers, using the [http://lists.moodle.org/ mailing list server].
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
|
| Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]
| Head of LMS
|-
| 7.
|
| style="text-align:center" | ✓
| Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]
| Development Manager
|-
| 8.
| style="text-align:center" | ✓
|
| New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period.
| AMOS Maintainer
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify, 24h after tagging, that https://moodle.org/dev/contributions.php has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!
| Integration Team
|-
| 10.
| style="text-align:center" | ✓
|
| For en and de Moodle Docs, update default redirects and enable email notifications.
| Moodle Docs Maintainer
|-
| 11.
| style="text-align:center" | ✓
|
| Go through all points listed under Day of release in [[New docs version process]].
| Community Manager
|-
| 12.
| style="text-align:center" | ✓
|
|
* Decide the "Full demo", "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar]. They will be -7w, -5w and -4w before release date respectively.
* Update the "Full demo", "Code freeze", "QA begins" and Release dates on the [[Roadmap]] page.
* Add events to the HQ calendar for next Major release 6-months cycle according to [[Process#Sprints|the cycle plan]]: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
* Notify the Community Manager of new dates to be added to the moodle.org calendar.
| Development Manager
|-
| 13.
| style="text-align:center" | ✓
| style="text-align:center" |
| Add calendar events in the [https://moodle.org/calendar moodle.org calendar] for coming Major and Minor releases up to the next Major release.
| Community Manager
|-
| 14.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Update release schedule image on [[Releases#Version_support|Releases page]]
| Development Manager
|-
| 15.
| style="text-align:center" | ✓
|
| Important: This must be done '''once it's already release day @ UTC''' (aka, after Australia/Perth 08:00) or the '''queues manage with hold them again''' because it's still "last week before release".
The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed '''only''' [https://tracker.moodle.org/issues/?jql=filter%3D13669%20AND%20type%20in%20(bug%2C%20task%2C%20Sub-task) from '''bug issues''' awaiting integration]; they correspond to last-week bugs that were held because of them being unrelated with the release. Now they can be processed, under on-sync rules. Standard message will be used to explain the un-hold.
| Integration Team
|}
==1 week after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).
For major releases, within the on-sync period, master packages will be generated using the prerelease.sh script (--type on-sync). That guarantees XY_STABLE and master versions are kept the same. The last week, when leaving the on-sync period, master package will be generated normally (implicit --type weekly), so versions will diverge and dev can continue separately from that point.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Update the version.php in git to be X.Y.Z+ during the next weekly integration process
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].) Add note to top of relevant version page about security support.
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
|| Security Officer
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Notify about publications of CVE using form: https://cveform.mitre.org/
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
|
| Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
|
|-
| 7.
| style="text-align:center" | ✓
|
| '''Deprecations:'''
* Create the next deprecation epic (for X.Y+1+2y) similar to MDL-74579 and add standard issues to it:
** Final deprecation of lib/deprecatedlib.php (like MDL-74580)
** Removal of deprecated Behat steps (like MDL-74581)
** Removal of strings (like MDL-74582) and
** Removal of renamed classes (MDL-74583).
The issue can be based/cloned on the previous one and linked ("has to be done after") with it.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous deprecation epics are going] and share about them.

'''Libraries:'''
* Create the next third party libraries epic for X.Y+1, similar to MDL-73715. The issue should refer to the list of [[Moodle libraries credits]]. The issue can be based/cloned on the previous one and linked ("has to be done after") with it. '''Drag/link opened issues from the previous one''', avoiding leaving unfinished stuff.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20(summary%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20OR%20summary%20~%20%22Review%20third-party%20libraries%20for%20upgrade%22)%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|}
==2 weeks after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Once the "On Sync" period ends:
* Confirm that versions (XY_STABLE and master) diverged properly the last on-sync week. If not, proceed to it by manually bumping master the version to the current date @ integration.git.
* Disable the "[https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous"] job. It has served us well.
* The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed from all issues awaiting integration, so they will be, automatically (see next point), be moved to the current integration queue. Send an "unholding + rebase" message to all those issues.
* Enable the "[https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal"] job. It will control the queues over the coming months, until the next freeze.
* In the [https://ci.moodle.org/ Jenkins CI server] enable all the jobs corresponding to the new branch (B-XYZ view) that were created on packaging day.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| The discussion about environmental requirements for next X.Y+1 major release (MDL-71747) will end and the issue will be resolved '''immediately'''. A new issue, about the requirements for nextthe -next X.Y+2 major release wil,l be created at the same time by cloning the previous one and dragging any non-resolved detail (due date = 3w after release).
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Ensure [https://download.moodle.org/langpack/X.Y+1/ Language pack for master (X.Y+1)] is available and merge the pull request MR4 for stop skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Ensure release retrospectives are held for each of the LMS teams and results are actioned.
| Development Manager / Head of LMS
|}
==1 month after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Remove, in CI servers, all the jobs and views corresponding to branches which support has ended completely. (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Remove%20all%20jobs%20from%20view/ maintenance job] to perform the operation).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Upgrade all the Moodle CI sites to recent major release by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm that there isn't any remaining [https://tracker.moodle.org/issues/?filter=13669 integration_held] issue from latest release, proceeding to uhhold them immediately. Note that there may exist [https://tracker.moodle.org/issues/?filter=13669&jql=project%20%3D%20MDL%20AND%20labels%20in%20(integration_held)%20ORDER%20BY%20%22Integration%20priority%22%20DESC%2C%20priority%20DESC%2C%20votes%20DESC%2C%20%22Last%20comment%20date%22%20ASC other "held" issues], unrelated with latest release. This process step does not affect them.
| Integration Team
|}
==See also==
* [[Deprecation|Deprecation process]]
[[Category:Processes|Release process]]
[[Category:Release notes|Release process]]

Backup 2.0 - Converters review 2011-04

2022-05-03T19:05:58Z

Stronk7:

[[Backup 2.0|Backup 2.0]] > [[Backup 2.0 - Provide upwards compatibility of Moodle 1.9.x backups|Backup 1.9 => 2.x main page]] > Review 2011-04
{{Template:WillNotMigrate}}{{Template:Backup 2.0}}{{Moodle_2.1}}

This page summarizes the results of the review performed (on April 2011) over the code available at https://github.com/mrmark/moodle related to the implementation of a general solution for the creation and support of moodle restore converters and its first implementation as one Moodle 1.9 => 2.x converter.

=== References ===

* MDL-22414 - the main tracker issue for this task.
* [[Backup 2.0 - Provide upwards compatibility of Moodle 1.9.x backups|Backup 1.9 => 2.x article]] in Moodle Docs.
* [http://tracker.moodle.org/secure/attachment/23241/Moodle1.9to2.0Restore.pdf PDF with initial implementation plan].
* [https://github.com/mrmark/moodle/compare/master...converters_wip Development branch changes]

=== Nomenclature ===

* The review results are shown below as one list of numbered points, briefly explained, with link to corresponding MDL-xxxx (subtask of MDL-22414), where any discussion / agreement / coding should happen.
* All the MDL-xxxx issue created will begin with R04xx to note they have been ignited as part of this review process and the point they correspond to.
* Each point below includes one short "status" message in order to know the immediate actions that must be performed on it.
* New points can be added to the review as long as discussion / agreement happens, if necessary.

=== Global summary ===

* Overall, all code seems to be in correct places and be correct code.
* The main infrastructure parts (base/plan/moodle1 converters and plan/task/step architectures) are ok, though their APIs would need some improvements detailed below.
* There are a lot of stuff missing / todo. Files, users, enrolments, plugins, tricky activities, comments, grades...
* We need to push-push-push (4 weeks to freeze!).

=== The list ===

==== Related to integration with restore_controller & general behavior ====

* <strike>R0401</strike>: status: fixed (MDL-27376) Right now, the to_moodle2_format() performs instantiation of all available converters + simple loop to get the conversions to perform. Instead, it should be possible to use exclusively static methods, returning origin format, target format and cost of the conversion, and then finding the best path or so. Note this is trivial right now but can be a useful general approach if new converters arrive (core and 3rd part).

* <strike>R0402</strike>: status: fixed (MDL-27377) The can_convert() function can be static too, passing tempdir as param. Also, the same function (or another one, mandatory) should check if all the PHP/server requirements are satisfied or no (some converters can need extra stuff available in order to be able to perform conversions).

* <strike>R0403</strike>: status: fixed. After each conversion, the original source directory is deleted and replaced by the converted one. This makes things complex to trace or perform repeated conversions and also, doesn't observe the $CFG->keeptempdirectoriesonbackup completely. We should be able to keep temp stuff undeleted if desired and, perhaps too, be able to instruct the restore controller about tempdir changes.

* <strike>R0404</strike>: status: fixed. Exceptions: It needs to be decided if we are going to use own converter_exception/s or restore_exception/s and use them constantly along all the code base.

* R0405: status: to code (MDL-27379). Logging: Converters stuff must inherit / use restore_controller logging facilities.

==== Related to the converters/moodle1 infrastructure ====

* <strike>R0406</strike>: status: fixed. All the parser / processor / path_elelement stuff is part of the abstract plan_converter. That stuff should be moved to moodle1_converter as far as it is highly dependent / tidied with the conversion particularities.

* <strike>R0407</strike>: status: refused by David. About converters, should class names and file names match, i.e. converter.class.php => moodle1_converter.class.php

* <strike>R0408</strike>: status: fixed. On restore, we have both after_restore() methods available in steps (executed when the step execution ends) and in tasks (executed when the whole plan execution ends). Do we need this duality in plan_converter, or is it enough with current one. Right now it seems that we are using a lot these methods to do the work, and process_xxx() should be used instead (together with next point).

* <strike>R0409</strike>: status: fixed. Since some weeks ago the notify_path_start/end() methods are available in the xml processor, should we start using them to call some stuff in converter, able to dispatch to start_xxxx() and end_xxxx() methods in the converter steps. It would help a lot with both starting/closing XML tags, creating and closing xml files, or any other pre/post stuff needing to be executed at certain stages.

* <strike>R0410</strike>: status: fixed. The deprecated/new/renamed elements / mutate_datum stuff. Perhaps it should be moved from steps to path_elements instead, so each path element autocontains the basic transformations to be performed on data and they are applied automatically. It seems a better place for that definitions. Or, alternatively, we'll need deprecated/new/renamed/mutate_xxxx() methods, one for each path.

* <strike>R0411</strike>: status: fixed. After looking current uses of the xml writer, it seems clear that we need some extra methods, able to print one tag completely, push/pop last open tag and other commodities in order to make coding easier.

* <strike>R0412</strike>: status: fixed. The "trick" in the parser about dynamically modify /MOD paths seems ok (I cannot imagine another way to implement it). Similar magic will be needed for blocks and surely, the start/end implementation above will need a similar way to handle/dispatch processing.

* <strike>R0413</strike>: status: fixed. Some raw accesses to the backup_ids_temp DB stuff must be modified to use helper functions. Also, the use of the table in get_context() can be really slow (text comparison). Look for some alternative.

* <strike>R0414</strike>: status: fixed. The convert_file() method uses the backup_ids_temp to get sequential fileid values. It should be enough (completely safe), to use one static (in memory) generator instead. No concurrence problems at all IMO.

* R0415: status: to code (MDL-27626, MDL-27452). Support for plugins is a must as far as at least qtypes require it. Note that question types are going to suffer one major revamp on Moodle 2.1, so their final architecture is unknown right now (different from both 1.9 and 2.0).

* R0416: status: to code (tiny detail). In current moodle1_conversion, original_site_identifier should be generated only if there is one original identifier. Right now it saves one "?" that can lead to wrong results detecting same sites.

==== Related to coding in general ====

* <strike>R0417</strike>: status: done. Copyright messages are required on each new file. It must be the standard one with GPL3 msg and MR/Mark/whatever copyright.

* R0418: status: to code. We should have as many tests as possible, specially testing all the infrastructure stuff, in order to guarantee it continues working as expected after any refactor / modification. Right now it's practically inexistent.

* <strike>R0419</strike>: status: the workflow established. We need to keep the main repo for all the project "converters_wip" in sync (merged) with current moodle.git master branch in order to ensure stuff will land properly (conflicts-free) and converters will be able to use any new feature / improvement available.

==== Related to pending & tricky areas ====

* R0420: status: to code. There are a lot of areas which coding hasn't been ignited yet (surely to pending work in the list above, don't worry). Here there is a brief ordered list, annotating the ones that will be really tricky:
** Users and enrollments: All the users with their complete information must be saved to new users.xml file and each process_xxx() method must, continuously, be annotating needed uses in order to generate proper inforef.xml files. Enrolments will be all moved to manual ones (this needs confirmation).
** Workshop activity: Completely revamped in 2.0. It has proper subplugins. Upgrade code needs to be deeply analyzed and XML differences too to know how to implement it. (contact: David).
** Wiki activity: Also brand new in 2.0. Upgrade needs analysis and XML differences too. (contact: Dongsheng).
** Resource activity: Split into file/folder/page/url activities. The structure is simple (no user data) but the split makes it really tricky. Also very file-intensive. Upgrade code needs analysis and XML differences (contact: Petr).
** Files: 1.9 files can had site/course files (apart from the ones "owned" by the module @ moddata). They must be annotated and moved to new files.xml & storage. There is some code already but is not used in the general converter helper stuff (should be moodle1 converter specific instead?).
** Gradebook: There are important differences between how 1.9 and 2.0 backup information is handled. Scales / outcomes / grade items need annotation in inforef.xml files and also there are new xml files designed to store specifically grades (categories, items, grades...) information. Need analysis. (contact: Andrew).

====After review, organization====

This section will be used to annotate any agreement / conclusion / organization for the next weeks in case the Tracker isn't enough to do so. Feel free to use it, beloved colleagues, always using the R04xx nomenclature for referencing exact stuff, plz.

=== See also ===

* Go back to [[Backup 2.0|Backup 2.0]] > [[Backup 2.0 - Provide upwards compatibility of Moodle 1.9.x backups|Backup 1.9 => 2.x main page]].

Backup 2.0 multiple formats

2022-05-03T19:05:25Z

Stronk7:

{{Template:WillNotMigrate}}{{Template:Backup 2.0}}{{Work in progress}}{{Moodle_2.0}}

One of the major goals of the [[Backup 2.0|Moodle 2.0 backup]] development is to be able to support multiple formats, both on export (backup) and import (restore), all them handled from core backup/restore code in a central and unified way.

This document explains how those formats will work and interact with Moodle, defining responsibilities and data flow between each part.

== Basic Concepts ==

Moodle 2.0 has one unique, '''documented''', valid XML format. Details about it can be found in the [[Backup 2.0 XML format|Backup 2.0 XML format]] page. <font color="red">(note the page doesn't exist yet because it's one of the parts being researched in the next weeks)</font> This will be the '''M20-BCK''' format. It's highly possible that this format will end being noticeably different from current (monolithic) format used in Moodle 1.9, although internal structures will remain pretty similar.

Also, there is one unique, '''undocumented''' (but easily readable and understandable because it's basically one DB dump) XML format used before Moodle 2.0, let's call it the '''M19-BCK''' (from Moodle 1.9) format. It's an important format because we need to guarantee that any M19-BCK file will be properly restored in Moodle 2.0.

And then there are various formats, let's call them '''3RD-BCK''' (3rd part backup formats) that should provide Moodle with extra backup / restore abilities. Notorious examples of these formats are: Blackboard 5.5, Blackboard 6.0 (see [http://cvs.moodle.org/moodle/backup/bb/?pathrev=MOODLE_19_STABLE cvs] to see how they are working in Moodle 1.x), or the new [http://www.imsglobal.org/cc/index.html IMS CC] format. In any case, all them will work in the same way under Moodle 2.0, so let's put them under the "3RD-BCK" umbrella.

== Restore Data Flow ==

Here it's one general overview of how those multiple formats are supported on restore. It handles M20-BCK backups (in blue, main restore process) and both 3RD-BCK and M19-BCK formats (in green, handling other formats sub-process).

[[Image:RestoreFormatsActivityDiagram.png|640px]]

([[Media:RestoreFormatsActivityDiagram.dia|original file available here]] - editable with [http://projects.gnome.org/dia Dia])

== Backup Data Flow ==

[[Category:Backup]]

Backup 2.0 - Provide upwards compatibility of Moodle 1.9.x backups

2022-05-03T19:03:53Z

Stronk7:

{{Template:WillNotMigrate}}{{obsolete}}

While the [[Backup 2.0 multiple formats|Backup 2.0 multiple formats]] document describes how different formats will be supported by the restore process in Moodle 2.0, it's going to be a highly complex task to perform the transformation of Moodle 1.9.x backups into the new, improved, Moodle 2.x backup format.

Too many things have changed between both versions to be able to achieve this easily. Surely it's computable (as long as upgrade is being able to apply the correct logic, so restore will) but it is going to be handled as a separate development that will allow us to 1) be centered in the 2.0 backup/restore and 2) be free (both in mind and implementation) from any 1.9.x XML format dependency.

=== Goals and basis ===

* The main goal is to create one '''conversion''' tool, able to get any Moodle 1.9 backup file and convert it to one Moodle 2.0 backup file. The tool '''will not perform any modification''' in the Moodle instance where it is being executed (i.e.the tool won't import anything). Once the conversion has finished, the standard Moodle 2.0 restore functionality will perform its job.
* The tool will get one already-uncompressed directory containing one Moodle 1.9 backup file and will create all the needed stuff in the same directory.
* The tool will have one unique entry point to perform the conversion and will be able to be invoked from within Moodle 2.0 (restore, performing conversion on the fly) or standalone (from CLI interface of any sort of batch processing).
* The tool will be built using as much infrastructure from Moodle 2.0 as possible (xml processors, plugins, core stuff, logging, debugging...) and will be full OOP (and php, of course).
* Ideally the conversion will happen in only 1-pass of xml parsing.
* The tool will be licensed under GPL3 or later and bundled with future releases of Moodle.

=== Introduction ===

Before any further analysis is highly recommended to:

* Know as much as possible about the Moodle 2.0 backup infrastructure. Reading the [[Backup 2.0 general architecture| general architecture page]], looking at all the stuff available under the backup/moodle2 directories (each plugin has its own) and understanding how information flows and is stored.
* Pay special attention and understand these parts of the Moodle 2.0 backup infrastructure:
** XML parser: In charge of reading all the XML file and dispatching pieces to different processors (backup/util/xml/parser).
** XML writer: In charge of writing XML files (util/xml/xml_writer.class.php and util/xml/output)
** Chained loggers: To output any information about the process (backup/util/loggers).
** Temporary tables, to store transient information if needed.

==== Physical differences ====

After reading the [[Backup 2.0 general architecture| general architecture page]], it's clear that there are huge differences between the XML used in Moodle 1.9 backups and their Moodle 2.0 counterparts. Let's dissect them briefly:

* We have changed from one unique monolithic '''moodle.xml''' file to a multiple xml files (and directories) alternative.
* The course, each section and each activity has its own directory.
* There are some top-level XML files (groups, users, files, questions, roles, scales...) acting as "containers" of information referenced from any course/section/activity (by their inforef.xml files).
* We have moved from uppercase tags to lowercase everywhere
* We are using XML attributes for some pieces of information (mainly ids).
* When possible (modules mainly) the old XML-tree structure has been observed.

==== Logical differences ====

A lot of things have changed from Moodle 1.9 to Moodle 2.0, causing a lot of modifications in the DB schema and, as backup is highly dependent of that (it's basically one representation of the DB), the information present in the physical xml files above has changed in a noticeable way too.

One good exercise is to create one, more or less, complete test course, backup it in Moodle 1.9, upgrade the site to Moodle 2.0 and backup it again. That way you'll see where each bit of information has ended in the new format. Also is a good task, in order to understand the changes, to read all the db/upgrade.php scripts present in Moodle 2.0. They show all the modifications performed along the time.

At this point it's important to avoid get stressed, yes, there are many differences and tons of modifications, some of them really complex. But good news is that, if the upgrade.php scripts have been able to perform the change then, for sure, it is computable and the conversion tool will be able to do the same.

Back to the logical differences, there are some of them needing special attention since day 0 (now):

* '''files:''' Under Moodle 1.9, files were stored both in the named "course files" directory (one physical directory) and also under the "moddata" directory (files belonging to modules, like forum attachments, assignment submissions...). Under Moodle 2.0, all the files are physically stored into one file pool (a really cryptic hash-based storage solution) with one logical store in DB, with contexts, components, file areas, hashes and items. The conversion tool will need one sort of "file conversion tool" able to handle any transformation from the old to the new approach, used everywhere.
* '''roles and enrolments:''' Moodle 1.9 enrolments were, simply, some role assignments performed at course level. This has been changed to a more powerful (dual) structure of both role assignments and proper enrollment-plugins. The conversion toll will need to do some "assumptions" in order to convert this information. Also it's important to note that, while in Moodle 1.9 backups the complete roles were being sent to XML (with all their capabilities and friends), this doesn't' happen anymore in Moodle 2.0 (where we only store basic information about them).
* '''contexts:''' Under Moodle 1.9, the use of contexts (the course, each activity, each user is one, unique context) was really limited (basically only used for roles and capabilities. Under Moodle 2.0, there are way more information based on contexts (files, comments, ratings, filters, blocks...). Hence we'll need to assign one context for each component in the backup to be able to associate information to it along the conversion.
* '''categories and questions:''' while the internal representation is pretty similar, now they are handled via standard plugins backup & restore in Moodle 2.0 (see question/type/xxxx/backup/moodle2) so some extra information (extra xml-levels) is required. The tool also should be handling the conversion in a plugin way, allowing other 3rd-part question types conversions to be implemented.
* '''blocks:''' 90% of blocks haven't any special DB representation nor need especial processing, but the rest (see, for example, the html block or the rss_client one) need custom conversion. So the tool must allow conversion of blocks also in a plugin way.
* '''activities:''' This is the most important part, where all the (educational POV) information resides. Of course, it must work in a plugin way. Here we'll find activities really easy to convert, because the only noticeable change has been their conversion to the new "files" (commented above). For example, the choice, glossary, forum... modules are good candidates to start with. But there are also some activities that have been completely rewritten / modified since Moodle 1.9. And they will be, without doubts, the most difficult ones to be handled by the conversion tool. Let's see some of them:
** '''resource:''' Under Moodle 1.9 all we had were types of resources (page, directory...) but all them being types of the (unique) resource module. Under Moodle 2.0, the the module has been split into different modules, each one with its own DB representation and unique features (file, folder, page and url). This split will need to be detected and handled specially by the conversion tool.
** '''wiki:''' Completely rewritten from scratch. Will need important changes both in the xml representation (100% different DB structure) and special process of all the contents (to translate from the old ewiki dialect to the new html implementation). Not to talk about binary contents that will also need special handling.
** '''workshop:''' Also completely rewritten from scratch. Will need important changes in the xml representation, use of subplugins and special process of some contents.

=== Overall process ===

Here there is one ordered list that could serve as technical/development roadmap for the analysis and implementation of the Moodle 1.9 conversion tool. Surely some (practically all) the points below can be split into smaller tasks in order to allow work to advance in parallel. Ideally all them should have one representation as subtasks of MDL-22414. Each task has one alphanumeric code to be used as reference in the future:

* '''A''': Preliminary Tasks
** '''A1''': Initial report (this document)
** '''A2''': Organization / roles / actors involved
** '''A3''': Initial timeline specification
** '''A4''': Documentation / research / learn
** '''A5''': Testing use cases, QA specifications
* '''B''': Infrastructure Tasks
** '''B1''': XML Parser
** '''B2''': Conversion dispatcher
** '''B3''': XML writer
** '''B4''': Support for plugins (questions, blocks, modules...)
** '''B5''': Support for subplugins (workshop, assignments...)
** '''B6''': Integration with Moodle 2.0 restore, logging, output...
** '''B7''': Progress review / discuss / adjust / timeline
* '''C''': Conversion Development Tasks
** '''C1''': Globals (files / users / groups / scales / outcomes / roles / gradebook ...)
** '''C2''': Course level information
** '''C3''': Section level information
** '''C4''': Activity level information
** '''C5''': Commons (comments / completion / filters / grades / roles /logs ...)

===Followups===

* [[Backup 2.0 - Converters review 2011-04|Review April 2011]]
* [[Backup 1.9 conversion for developers]]

===See also===

* MDL-22414 - the main tracker issue for this task

Backup 2.0 - Improve XML parsing

2022-05-03T19:03:40Z

Stronk7:

{{Template:WillNotMigrate}}{{obsolete}}

[[Backup 2.0]] -> Improve XML parsing

== Summary ==

Current (Moodle 1.x) restore uses too much memory parsing some "parts" of the XML information. We need to change current approach to one providing optimal memory usage and acceptable throughput. In this page you'll find the different alternatives researched, with their strengths and weaknesses. Finally one solution will be provided in order to be implemented in new Moodle 2.0 backup & restore. Also, if possible, some changes will be performed in Moodle 1.9 in order to achieve better results and solve bugs like MDL-14302, MDL-15489, MDL-9838...).

== Research ==

Below, you will find some information about different methods used to perform the XML parsing of one 12.5MB file, corresponding to one real quiz module with only 788 attempts and 20115 states (answers). It has been proved to be the problematic "part" in one production server using current Moodle 1.9.x (the file isn't available here for privacy matters, obviously).

Each method, in order to be considered valid must fulfil these basic objectives:

* '''Parse''' the XML file.
* '''Provide one in-memory object''' with all the needed info in order to be processed later by the corresponding restore plugin. ''Discussion of this point moved to the [[Development talk:Backup 2.0 - Improve XML parsing|talk page]]''.

For each method, some common information bits are provided (to allow comparisons later).

* '''name''': mnemonic to easily reference each method later in comments.
* '''file size''': the size of the original XML file being parsed.
* '''memory''': max memory used by PHP in the execution (provided by [http://php.net/memory_get_peak_usage memory_get_peak_usage()]).
* '''time''': time required to perform the parsing to memory (measured in seconds).
* '''data size''': size of the in-memory generated object (final result of the execution).
* '''data format''': specifications of the in-memory generated object (xmlize compatible, custom...).

=== Table of Results ===

This table summarises the raw results obtained running each method, providing links to details about each of them.

{| border="1" align="center"
|-
! Method !! File size !! Memory !! Time !! Data size !! Format
|-
| [[#Method 0: Current behaviour (xmlize)|Method 0: Current behaviour (xmlize)]] || 12.5MB || 311.3MB || 4.8 seconds || 14MB || [[#XMLize format|xmlize]]
|-
| [[#Method 1: SimpleXML parsing + conversion to xmlize format|Method 1: SimpleXML parsing + conversion to xmlize format]] || 12.5MB || 165.8MB || 5.2 seconds || 14MB || [[#XMLize format|xmlize]]
|-
| [[#Method 2: Method 2: SimpleXML parsing, no conversion|Method 2: Method 2: SimpleXML parsing, no conversion]] || 12.5MB || 36.5MB || 0.5 seconds || 8.5MB || [[#SimpleXML format|simplexml]]
|-
| [[#Method 3: Custom SAX parser + conversion to xmlize format|Method 3: Custom SAX parser + conversion to xmlize format]] || 12.5MB || 158.3MB || 47.5 seconds || 14MB || [[#XMLize format|xmlize]]
|-
| [[#Method 4: Custom SAX parser + conversion to xmlize-reduced format|Method 4: Custom SAX parser + conversion to xmlize-reduced format]] || 12.5MB || 72MB || 51.9 seconds || 7.7MB || [[#XMLize-reduced format|xmlize-reduced]]
|-
| [[#Method 5: Custom SAX parser + conversion to custom (simple) format|Method 5: Custom SAX parser + conversion to custom (simple) format ]] || 12.5MB || 64.5MB || 15.1 seconds || 5.4MB || [[#Custom-simple format|custom-simple]]
|}

* Temp Note: To avoid forgetting to talk about :
** Improve4memory and improve4speed
** SimpleXML in core (possibility to provide transformation to xmlize for easier contrib code upgrade of backup/restore.
** Split moodle.xml into multiple files (one for each current "TODO" - part in Moodle 1.9 + 1 per module). Some of this has been worked out/tested in MDL-18468 showing important speed benefits.
** With that split performed it will be easier to support different "envelopes" for the same modules (section backup/course backup/1 activity backup...).
** Analyse the possibility to, in a declarative way, be able to define the whole backup & restore process. One XML to specify the whole thing would be amazing... prospect possibilities. Different from install.xml for sure (just in case somebody is thinking about that) (see [[Development talk:Backup 2.0|talk page]]).
::''Eloy, declarative is good, but please not XML. We need an machine-readable format that developers understand. Let's use a PHP API. Defining databases with XML that can only be edited with the built in editor sucks. We should not repeat that choice.''--[[User:Tim Hunt|Tim Hunt]] 04:53, 8 March 2009 (CDT)
:::''Tim, I don't get the point. What exactly sucks? What is a PHP API? I think XML is the way, 100%'' --[[User:Eloy Lafuente (stronk7)|Eloy Lafuente (stronk7)]] 07:23, 8 March 2009 (CDT)

::::OK, easy example, when you have to edit an XMLDB file by hand becuase the stupid XMLDB editor is buggy, you find yourself editing stuff like
<FIELD NAME="questiondecimalpoints" TYPE="int" LENGTH="4" NOTNULL="true" UNSIGNED="false" DEFAULT="-2" SEQUENCE="false" ENUM="false" COMMENT="The number of decimal digits to use when displaying question grades. -1 = use decimalpoints, otherwise a separate setting." PREVIOUS="decimalpoints" NEXT="review"/>
::::In particular, when you are trying to edit the previous and next links (which are completely unnecessary, separate rant) your editor is scrolled so far over to the right that you cannot actually see which field you are editing the prev and next attributes of. That is my point. XML is a horrible format to edit by hand.
::::Instead, I would rather work with a PHP API, for example the admin settings API. That is also more flexible. With XML, you can only do the things that the XML lets you do. With PHP, where necessary, you can write PHP code to do anything necessary, in the admin settings case, that may mean making a new settings subclass, or writing some code to compute a default value to feed to a setting constructor. For backup and restore, we will need that sort of flexibility I think.--[[User:Tim Hunt|Tim Hunt]] 01:30, 10 March 2009 (UTC)

** Allow modules to request "sub-parts" of the whole module.xml file. While we can accept each module as a whole (an load it straight to memory) some modules (quiz) are big enough to make this approach to cause problems (see MDL-15489). Should be able to request "different sub-parts" using some simple mini-API. (quiz example: "giveme the quiz module data", or "iterate over the attempts in a nice loop"...). (see [[Development talk:Backup 2.0 - Improve XML parsing|talk page]]).
** Modules implementing own parser?
** Backport or analyse some interim solution for 1.9 quizzes.

=== The alternatives analysed ===

Here each of the alternatives is analysed and compared

==== Method 0: Current behaviour (xmlize) ====

'''Summary''': file size: 12.5MB, memory: 311.3MB, time: 4.8 seconds, data size: 14MB, data format: xmlize format

==== Method 1: SimpleXML parsing + conversion to xmlize format ====

'''Summary''': file size: 12.5MB, memory: 165.8MB, time: 5.2 seconds, ata size: 14MB, data format: xmlize format

==== Method 2: SimpleXML parsing, no conversion (use simplexml as final object) ====

'''Summary''': file size: 12.5MB, memory: 36.5MB, time: 0.5 seconds, data size: 8.5MB, data format: simplexml format

==== Method 3: Custom SAX parser + conversion to xmlize format ====

'''Summary''': file size: 12.5MB, memory: 158.3MB, time: 47.5 seconds, data size: 14MB, data format: xmlize format

==== Method 4: Custom SAX parser + conversion to xmlize-reduced format ====

'''Summary''': file size: 12.5MB, memory: 72MB, time: 51.9 seconds, data size: 7.7MB, data format: xmlize-reduced format

==== Method 5: Custom SAX parser + conversion to custom (simple) format ====

'''Summary''': file size: 12.5MB, memory: 64.5MB, time: 15.1 seconds, data size: 5.4MB, data format: custom simple format

== Formats ==

In this section there are some explanations about the different object formats generated by the different methods:

=== XMLize format ===

=== SimpleXML format ===

=== XMLize-reduced format ===

=== Custom-simple format ===

== Code ==

Here its' the code used for the different parsing methods commented above:

=== Method 0: Current behaviour ===

<syntaxhighlight lang="php">
$contents = file_get_contents('moodle.xml');
$data = xmlize($contents);
</syntaxhighlight>

Backup 2.0 known problems

2022-05-03T19:03:29Z

Stronk7:

{{Template:WillNotMigrate}}{{obsolete}}

* '''[[Backup 2.0 - Improve XML parsing|Improve XML parsing]]''': One of the major bottlenecks in backup and, especially, in restore reliability under Moodle 1.x has been the large amount of memory needed to handle those operations (see bugs like MDL-14302, MDL-15489, MDL-9838... and many others). While the whole XML file (moodle.xml) is parsed in a [http://en.wikipedia.org/wiki/Simple_API_for_XML SAX] way (hence, "streamed" and requiring small amounts of memory), we use to group some XML contents into "parts" in order to delegate the operations over those "parts" to different plugins (modules, blocks...). And problems arrive when some of those "parts" are big enough and processing them with the [http://php.net/xml_parse_into_struct xml_parse_into_struct()] function and the [http://www.hansanderson.com/php/xml/ xmlize] library uses exaggerated amounts of memory (for example, to process a 12.5MB file requires 311MB of memory, crazy!). So we need to switch to an alternate method to parse those "parts" using much less memory and to build the corresponding in-memory object with one acceptable throughput (speed).

* '''[[Backup 2.0 - Provide upwards compatibility of Moodle 1.9.x backups|Upwards compatibility of Moodle 1.9.x backups]]''': While the [[Backup 2.0 multiple formats|Backup 2.0 multiple formats]] document describes how different formats will be supported by the restore process in Moodle 2.0, it's going to be a highly complex task to perform the transformation of Moodle 1.9.x backups into the new, improved, Moodle 2.x backup format. Too many things have changed between both versions to be able to achieve this easily. Surely it's computable (as long as upgrade is being able to apply the correct logic, so restore will) but it is going to be handled as a separate development that will allow us to 1) be centred in the 2.0 backup/restore and 2) be free (both in mind and implementation) from any 1.9.x XML format dependency.

Backup 2.0 general architecture

2022-05-03T19:03:21Z

Stronk7:

{{Template:WillNotMigrate}}{{obsolete}}

This page tries to explain briefly all the rationale behind [[Backup 2.0]]. It isn't a complete and exhaustive description of the whole thing, but a summary showing the main concepts involved.

== Nomenclature ==

When talking about backup, there are some basic terms that it's better to have clearly defined. Here they are:

* '''Backup (or restore) Type''': Simply, what is being handled, and, at the time of writing this, can be: 1 activity, 1 section or 1 course.
* '''Backup Format''': The "physical" representation of the information to be handled and its organization in one transferable file. The main format is, of course, the "moodle2" format (the one that guarantees the max data to be preserved when moving Moodle contents), with others in the pipeline, like the "imscc" format and friends...
* '''Interactivity''': To determine if the process, once launched, requires user interaction or not. Basically an interactive backup/restore is needed in order to give the user a UI to adjust all the settings (options) before the process is launched.
* '''Execution:''': To determine if the execution of the process is immediate or delayed (scheduled?). Has implications in the output of the process, logging and others.
* '''Backup Mode''': Can be considered like "purposes" of the backup, and based on them, various options will be defined and locked. Think on them like some sort of presets or hardcoded rules altering the settings and process.
* '''Backup Defaults''': Or how settings are configured initially, each time a backup/restore is requested. They are defined for each (backup) '''Type''' and '''Format''' and are altered depending on the '''Mode''' selected.
* '''Backup UI''': The front-end displayed to the user in '''Interactive''' backups, allowing him/her to configure the backup settings. This includes any feedback from the backup system '''before''' the execution process is started. Strongly form-based.
* '''Backup Output''': The front-end displayed to the user in '''Interactive''' and '''Immediate''' backups showing information '''after''' the process starts, showing any information about the different steps being executed, final status...

== Backup ==

=== The components ===

These are the main components involved in backup and their main responsibilities in the process:

* '''Backup Controller''': ([http://cvs.moodle.org/moodle/backup/controller/ cvs]) It's the main object in the life of one backup operation. It contains all the information needed in order to be able to execute a backup successfully (you can see some more details in the next section). From the complete specs of the backup (type, mode, execution, interactivity, source...), including all the settings, logging, output options and also the whole backup plan to be executed and various steps that any backup must fulfil (load defaults, ui invocation, apply security constraints...). Everything happens in / is done by the backup controller. One important feature is that it '''must''' be 100% serializable, so all their elements (before process execution) must be also, serializable. This guarantees we can delay execution, safely storing the whole controller in DB while we '''avoid completely''' using sessions for backup transient information.

* '''Backup Loggers''': ([http://cvs.moodle.org/moodle/backup/util/loggers/ cvs]) Typical loggers chain able to log information to various places (DB, file, error_log...). With typical logging levels and so on. Should be configurable globally from admin options. Each backup controller has one chain of loggers instantiated.

* '''Backup Destinations''' ([http://cvs.moodle.org/moodle/backup/util/destinations/ cvs]) (not implemented yet!): The basic idea about backup destinations is to be able to send the final backup file to/over a variety of systems. For example, in backups of Moodle = HUB, we could be sending the backup file to the corresponding Moodle HUB, or to other repositories, or by email, or direct download... or any combination of these. For now, they only will be able to send the backup files to different file areas within Moodle, or perhaps they won't be used at all initially. To be decided.

* '''Backup Settings''': ([http://cvs.moodle.org/moodle/backup/util/settings/ cvs]) Anything altering backup behaviour must be considered to be one setting. No matter if it has visual representation in the UI or not, or if can be configured by the user or not. It's a setting. And other components in backup will rely on setting values to conditionally perform different actions. Note that each setting has one level (root, course, section, activity) and they follow somehow the observer pattern so relations and dependencies between them can be specified easily (and UI must respect them).

* '''Backup UI''': ([http://cvs.moodle.org/moodle/backup/util/ui/ cvs]) (not implemented yet!): All the stuff that, once all the settings have been created and pre-defined (observing defaults, security and dependencies), will organize them in one usable front-end, allowing the user to interact with them, changing the final behaviour of the process.

* '''Backup Output''': ([http://cvs.moodle.org/moodle/backup/util/output/ cvs]) In charge of show information about the process, this singleton can receive requests from the backup loggers and/ or by direct invocation. Current implementation is pretty simple (just prints one list of messages, but could be extended to support progress bars and /or other commodities).

* '''Backup Structure''': ([http://cvs.moodle.org/moodle/backup/util/structure/ cvs]) The base component on top of which all the rest of backup is built. Implements one simple PHP API allowing to define (virtually) any structure suitable to be sent to xml, fetch any information (using the visitor pattern to recursively process the whole tree) from iterator and perform other operations in a transparent and consistent way. In three words, ''"the heart of backup"'' (well, they are four).

* '''Backup Plan''': ([http://cvs.moodle.org/moodle/backup/util/plan/ cvs] and [http://cvs.moodle.org/moodle/backup/moodle2/ cvs2]) The execution plan, dependent of the Type and Format of the backup. Split into tasks, each one having one or more steps. Note there are two types of steps: '''execution steps''' that only execute (custom) php code, used for anything not being XML output and '''structure steps''' that, using the "backup structure" component, are used basically to generate XML output. Note they are spread out in the moodle code, so each block and activity, for each format available, will have its own plans, tasks and steps. Also in three words, ''"backup's skeleton"'' (grrr, they are two now).

* '''Other components''': Last, some more components that are good to know about, all them being non-instantiable classes with static execution of methods:
** Backup checks: ([http://cvs.moodle.org/moodle/backup/util/checks/ cvs]) Various fixed checks performed by the controller. Security being the most important.
** Backup dbops: ([http://cvs.moodle.org/moodle/backup/util/dbops/ cvs]) Operations involving DB access must go here, not 100%, but at least to avoid "spaghetti code" in above (critical) components.
** Backup helper: ([http://cvs.moodle.org/moodle/backup/util/helper/ cvs]) Classes and methods not being part of other components but being used along the backup process. Some iterator implementations to help backup structures, some functions used more than 1 time...
** Backup factories: ([http://cvs.moodle.org/moodle/backup/util/factories/ cvs]) Some methods in charge of, dynamically, instantiate different objects along the backup process. Mainly supporting backup plans and tasks.
** Backup interfaces: ([http://cvs.moodle.org/moodle/backup/util/interfaces/ cvs]) Very basic interfaces to enforce the implementation of some methods in order to achieve functionalities in a consistent way (checksum-able, process-able....).
** Backup xml-writer: ([http://cvs.moodle.org/moodle/backup/util/xml/ cvs]) Very low level XML writer implementation, with error detection, support for memory/file output, dynamic contents transformations. Used extensively in the process to output all the XML contents.
** ... (note there are some more components, but they don't seem to be important enough to be introduced here).

=== The process ===

Any backup will go through the following steps:

# Backup controller instantiation, that automatically
## Performs various checks, prepare loggers, destinations and other components
## Load the backup plan (so settings become available)
## Apply defaults to settings (based in $CFG config options and backup type/format/mode)
## Apply security constraints to settings (modifying settings if necessary)
# If the backup is interactive, looping over the next steps until finished:
## Save / load the controller as necessary (to make it persistent along multiple requests).
## Show UI (observing settings status, values and dependencies)
## Process UI changes
## Re-apply security constraints to settings (with error if something is violated)
# Finish UI if was used (interactive)
# Save the controller if execution delayed (cron will get it later - once implemented)
# Execute controller plan (so everything will be generated)

So, just as an example for the impatient people, literally following the steps above, and knowing that the UI implementation and other bits are still missing, here it's your first course backup (just replace the XXs and execute it). Please ignore any output in browser / command line.

<syntaxhighlight lang="php">
<?php

require_once('config.php');
require_once($CFG->dirroot . '/backup/util/includes/backup_includes.php');

$course = XX; // id of the course to backup
$user = XX; // id of the user performing the backup

$bc = new backup_controller(backup::TYPE_1COURSE, $course, backup::FORMAT_MOODLE,
backup::INTERACTIVE_YES, backup::MODE_GENERAL, $user);
$bc->finish_ui();
$bc->execute_plan();
$bc->get_results();
</syntaxhighlight>

You should end with one directory under $CFG->dataroot/temp/backup having the complete backup contents within it. Time to take a look to it.

=== The results ===

'''Temp note''': First of all, did I say that your execution above should be performed in one course having some forum(s)? As far as right now, forum is the only activity with backup implemented... it's a good recommendation. ;-) In the other side, all blocks, filters, comments, ratings, role assignments and overrides ... are fully supported, so use them here and there.

'''Temp note2''': There are some missing bits in the explanations below. More noticeable are questions and their categories and complete gradebook information. Will be added once decided and implemented.

This section tries to summarize the final results of one "moodle2" format backup. As listed in the requirements of the project, we are moving from one '''"monolithic"''' moodle.xml file to one multi-file format, '''better structured and easier to be handled''' by restore. At the same time, while contents will be practically the same (as far as the xml generated) continues being one structured "database dump" one of the main visually differences is that we have, finally, moved to '''lowercase tag names''' (Moodle 1.x used to have everything uppercase).

Also, we have introduced some '''new "references" files''' will provide information about which part of the backup is using which instances of some elements so, on restore, if we are restoring one course partially, only the "used" files / groups / users / scales ... will be restored. This was one of the major design limits in Moodle 1.x backup, where those items were restored always completely and not selectively based in that extra "usage" information.

From an organizational point of view, folders follow the schema of available Backup Types (see above). So, in the backup generated file we are going to find, always, one of more of this folders:

* '''course''': (present only in 1 course backups). Will contain information about the course (course.xml), role uses (assignments and overrides), comments, filters, logs and, of course, blocks (we comment about them below) and the corresponding "references" (inforef.xml) file, pointing about uses of some key components, as explained above.
* '''sections''' (present in 1 course and 1 section backups). Will contain '''one directory for each section''' included in backup (numbered with the section->id). Each section will contain information about the section (section.xml) and its corresponding "references" file (just referencing file uses).
* '''activities''' (present in all backups). Will contain '''one directory for each activity''' included in backup (numbered with the cm->id). Each activity will contain information about the activity (''activityname''.xml), its module characteristics (module.xml), role uses, filter, comments, user completion, logs, activity grade items...) and, once more, blocks and the corresponding references file.

Special mention is necessary for the "blocks" directory (present under each course / activity dir). As far a blocks are 1st class citizens in Moodleland, they can have a lot of information associated so they have their own space in backups. It will be '''one directory for each block belonging to that''' course/activity (numbered with block_instance->id). Each block directory will contain information about the block (block.xml), optionally information about the DB related to the block (''blockname''.xml), roles, comments and the corresponding references file.

Finally we have to talk about the backup root directory and what we can find there:

* '''moodle_backup.xml''': it's the root file in the backup. It contains information about the backup itself: versions, details, summary of contents and full list of settings, as configured on backup. We can consider it like the "map" that shows/describes the whole backup and it will be highly useful in the restore process.

* '''files.xml''' and '''"files"''' directory. It contains '''all''' the files used in the backup process, no matter of which course/section/activity is using them. Its internal structure is kinda similar to current moodle file storage structure, although this could diverge (safely) in the future. Of course, it's important to comment that we have all those "reference" (inforef.xml) files spread along the course/section/activity/block directories above so it will be '''easy to pick''' the needed on restore.

* '''other files''' (users, roles, scales, groups, outcomes...). All these follow the same pattern as the files.xml file above, as far as all them '''are merely "stores"''' of all the information used by any backup part. Once more, reference files will point to the required ones on restore.

That is!

Backup 2.0 drop in ideas

2022-05-03T19:03:11Z

Stronk7:

{{Template:WillNotMigrate}}{{Template:Backup 2.0}}This page collects all the ideas collected/suggested by the Community, related to [[Backup 2.0|Backup 2.0]] along the last months. They are distilled/discussed with detail in the [[Backup 2.0 requirements|requirements]] page in order to get a comprehensible list to be fulfilled in the development process. Here it's the original raw list (just numbered for easier reference):

# Enable Backup and restore of a Course and it's related meta courses IN ONE HIT to save on adminstration time.
# Support incremental backups & restore.
# Support 1-activity backup.
# Backup/restore one topic only (not just one activity) --[[User:Samuli Karevaara|Samuli Karevaara]] 21:29, 5 March 2009 (CST)
# Support anonymisation of personal data on backup.
# Separate process and progress. ''(Perhaps [http://cvs.moodle.org/moodle/lib/weblib.php?r1=1.1214&r2=1.1215 these classes I wrote] can help)--[[User:Tim Hunt|Tim Hunt]] 19:41, 1 March 2009 (CST)''
# XML format doesn't need to be radical different (IMO).
# Support restore of old (1.9 only?) backups.
# Hook in backup & restore to [[Backup 2.0 multiple formats|intercept & support other formats (BB, IMS-CC...)]]
# One code base both for manual and scheduled backup
# Scheduled restore
# Fix restore so that one can also select to restore course settings (they are currently backed up, but not restored in any restore function.)
# Fileless export/import (aka fix import function so that one can choose to import blocks, course settings, etc. in addition to resources/activities)
# Export/import over mnet
# OOP.
# Secure (don't handle non-allowed data, user matching on restore, salted passwords..)
# Safe (some sort of "rollback" on failure - requires to have everything annotated somewhere - backup_ids or so).
# file-less backups - if you have separate backups, import/export etc.
# Allow to backup one category of courses (at the same time, one zip per course). MDL-17187
# Allow to mark courses to be excluded from scheduled backup manually.
# Avoid anti-timeout output when not running from browser. MDL-17282
# Review related caps, cleaning them and adding missing bits, improving sec. consistency.
# Log all backups (both manual and scheduled). Improve logging in general.
# Separate each module's portion of XML into its own namespace.
# Use the namespaces to allow each module the option of validating it's XML content before processing.
# Roll dates: on restore or import, allow instructor to input a start date, and roll all assignment, quiz, etc. dates forward based on the new start date.
# Backup would need to be called when publish a course on the community hub ([https://docs.moodle.org/en/Community_hub#Publish_course course template])
# Metadata... to be included in backup/restore... something like: [[Metadata]]
# Allow backup of roles with permissions, assigns and overrides. MDL-17081

'''Note:''' list items marked with ✔ have been analysed/added as development [[Backup 2.0 requirements|requirements]].

Backup 2.0 requirements

2022-05-03T19:02:58Z

Stronk7:

{{Template:WillNotMigrate}}{{obsolete}}

This page shows the analysis/justification/decision for all the [[Backup 2.0 drop in ideas|drop in ideas]] detected/suggested along the last months mashed up with the main goals of the project. While pinpointing all the requirements of the new Backup 2.0, also we'll be defining the main list of tasks to fulfil them.

== RQ01: ==

'''Enable Backup and restore of a Course and it's related meta courses IN ONE HIT to save on adminstration time'''

Meta courses are out in Moodle 2.0 and their functionality will be, somehow, replaced my the new [[Cohorts | Cohorts]] (a.k.a. site-wide groups). In any case, and as a general rule, any backup / restore operation involving more that one course is not backup / restore responsibility (i.e. the functionality is not built in there) but responsibility of newly scripts using the new backup API to do those "multiple operations".

== RQ02: ==

'''Support incremental backups & restore'''

This has been a requirement since long time ago (see various discussions in the Forums). Anyway it seems that, at the end, the only way to accomplish this with certain degree of success is to use '''external tools''' to calculate the differences between two backup files and apply them in order to build the necessary final backup file to be restored. The alternative approach, to make the functionality to be available under Moodle would require time/hast stamping near all information and keeping big logs of each backup file in order to selectively know what needs to be exported / imported. Not viable.

So, from the backup / restore perspective, there is '''nothing to do''' but to provide information in one format that makes those "external tools" to be able to handle information properly. With the current changes already performed in the backup format (where information is highly splited, that should be far easier than under Moodle 1.9).

== RQ03: ==

'''Support 1-activity backup'''

Supported!

== RQ04: ==

'''Support 1-section backup (topic/week)'''

Supported!

== RQ05: ==

'''Support anonymisation of personal data on backup'''

Supported! Right now it's limited to anonymize user information bits (name, email...) and related info (preferences, tags, personal files...) to be exported. There are two points that could be improved:

* Improvements to the anonymizer (MDL-22158): Make information to "look" better, using random names and so on.
* Be more intrusive (NOBUG): Also anonymize (replace) file submissions and friends by "template-blank" files.

== RQ06: ==

'''Separate process and progress'''

This is one of the primary goals of the new subsystem. Already have two well defined points where visualization can happen (conditionally). The backup / restore UI (MDL-22142 - previous to process). And the output process (MDL-22144 - handled by output singleton). Both used only if necessary and not interfering the process itself at all. Also, logging (MDL-22143) has been separated from process and delegated to proper loggers. Finally, heartbeat information (MDL-22143 - needed to avoid browser timeouts) is also performed transparently by the process and developer doesn't need to do it manually any more.

== RQ07: ==

'''XML format doesn't need to be radical different'''

While the original idea (at early Moodle 2.0 planning stages) was to keep the Backup 2.0 format as similar as possible with 1.x format, finally some core changes (new [[File API|File API]]...), other requirements (like 1-activity, 1-section backups, see above...) and the need to modernize a bit the old format (uppercase, not using attributes...), have produced this original thoughts to change. So Moodle 2.0 will debut one new format, split along multiple files for easier reference / manipulation.

Note that contents will be basically the same, as far as contents are just "DB dumps". They just will be more organized along different files. See the [[Backup 2.0 general architecture|general architecture]] page for more information about the new format.

== RQ08: ==

'''Support restore of old (1.9 only?) backups'''

This is a '''must''' requirements and will be developed once Moodle 2.0 <==> 2.0 backup / restore is completely working. It will use the mechanism described at [[Backup 2.0 multiple formats|backup multiple formats]] so the format will be intercepted and converted. In any case it's going to be a really complex task, due to the deep changes performed in Moodle 2 (new modules, files...) and is, by itself, one separated project which codebase won't interfere at all with Moodle 2.0 backup / restore (although will be executed as part of it normally).

== RQ09: ==

'''Hook in backup & restore to intercept & [[Backup 2.0 multiple formats|support other formats]]'''

Backup will allow the generation of backup files in different formats. This is supported from core, so once the corresponding backup controller is instantiated and the corresponding format specified, everything (settings, ui, plan, tasks and steps) will be performed accordingly with that backup format.

In the other side, restore will detect as soon as possible the format of the file, performing the necessary conversions to transform the original format detected into one suitable Moodle 2.0 backup format.

== RQ10: ==

'''One code base both for manual and scheduled backup'''

Process will be unique. This is 100% mandatory. Another thing is the "scheduled" bit of those backups and their "iterative" (multiple) characteristic. Both are out from backup process responsibilities (see [[#RQ01:|RQ01]] above). One script / cron combination will provide such functionalities while using core backup API for each of the target courses when necessary.

== RQ11: ==

'''Scheduled restore'''

== RQ12: ==

'''Fix restore so that one can also select to restore course settings'''

== RQ13: ==

'''Fileless export/import'''

== RQ14: ==

'''Export/import over mnet'''

== RQ15: ==

'''OOP'''

== RQ16: ==

'''Secure'''

== RQ17: ==

'''Safe'''

== RQ18: ==

'''file-less backups - if you have separate backups, import/export etc.'''

== RQ19: ==

'''Allow to backup one category of courses. MDL-17187'''

== RQ20: ==

'''Allow to mark courses to be excluded from scheduled backup manually'''

== RQ21: ==

'''Avoid anti-timeout output when not running from browser. MDL-17282'''

== RQ22: ==

'''Review related caps, cleaning them and adding missing bits, improving sec. consistency'''

== RQ23: ==

'''Log all backups (both manual and scheduled). Improve logging in general'''

== RQ24: ==

'''Separate each module's portion of XML into its own namespace'''

== RQ25: ==

'''Use the namespaces to allow each module the option of validating it's XML content before processing'''

== RQ26: ==

'''Roll dates'''

== RQ27: ==

'''Backup would need to be called when publish a course on the community hub'''

== RQ28: ==

'''Metadata... to be included in backup/restore. Something like [[Metadata]]'''

== RQ29: ==

'''Allow backup of roles with permissions, assigns and overrides. MDL-17081'''

Backup 2.0 overview

2022-05-03T19:02:47Z

Stronk7:

{{Template:WillNotMigrate}}{{obsolete}}

== Non-functional requirements ==

* Change format dramatically, splitting current monolithic moodle.xml into smaller pieces (1xplugin, 1xusers, 1xroles, 1x...). Working in experimental way since 1.9, proved to be great for speed (saves ~20 repeated parsings of the whole file). No dependencies from previous stuff at all.
* Change the current "xmlize" approach when restoring files to one new progressive_parser instead. Each part of restore will decide how it wants to receive the information and who is in charge of processing it. Great for memory.
* Allow 1-activity, 1-section and 1-course backup. Use different shells/envelopes for any type of backup, keeping the "content" the same.
* Unify all multiple backup variations (course backup, course export, silent backup, scheduled backup) into a single codebase. Same for multiple restore.
* Backup and restore execution function (only ONE function, the executor!!) will be "blind": They won't perform decisions based on (changing) roles/capabilities/configuration settings any more. One master "backup_director" object will direct them once the object has performed all validations and ensured the process is executable. That director will handle/decide/instruct the executor about output/logging and everything else.
* Store complete information about any backup/restore performed in the site. This will include all the information for the the director (array-serialised) and the results of the executor. And obviously all the logged info cached when running.
* Important UI changes:
** UI won't make any processes! (like pre-calculating, or post-checks and friends). It will be completely separate from the "director" and the "executor".
** Complete site/user defaults
** View the backup/restore form in "course" organisation (inline? nah for 2.0 IMO) instead of grouped by activity mode. Surely over multiple configuration "steps".
** Bunch of new detail-options (restore section descriptions, overwrite course settings..., usually requested).
* Reuse code like crazy. Some things like the "id-remapping" on restore, the logs output, the "flush" output and so on will be central and any point of restore will be able to request that "services" or "utilities" when desired in a easy way (mini PHP-API to define things in a declarative way VS one/multiple helpful backup/restore "utilities" classes).

== Preliminary notes ==

=== Splitting information ===

* All the existing/required caps define behaviour for each one.
* All the zones and splitter.
* Files backup/ restore.
* 1.9 => 2.0 transformations.
* Shells, separate structure and activities/blocks.
* Backup by "context". Each "context"(or inner items) will have:
** users
** groups
** files
** logs
** blocks
** role definitions
** role assignments
** role overrides
** completion info
** conditional info
** comments
** tags
** questions and categories
** gradebook: scales/outcomes and "activity grade items".
** gradebook: agregations/calculations and categories.
** filters
** metadata
** messages
** events
** blogs
(alternatively, all these parts can be found at the end of the backup file, globally for all contexts)

=== CZ Hackfest thoughts ===

* Need stamps for users (perhaps not because of MDL-16658) and roles (like question/categories ones) to guarantee uniqueness.
* Need to decide about backup file names (moving from .zip to .xxx). Multiple extensions or prefixed info to "tell more" about the backup type.
* 1.9 => 2.0 restore:
** Really complex, needs to mimic all current logic in upgrade.php scripts:
*** xml transformations --> relatively easy
*** files migration (course and moddata)
*** wiki, resources, workshop transformations (complex)
*** incoming question bank changes.
*** surely other stuff (comments, messages, blogs)
** Possible solutions:
*** How:
**** Reuse as much as possible code from upgrade scripts. Not everything is re-usable (bulk changes).
**** Re-implement all the logic in restore.
**** Forgetting about it
*** When:
**** In one step, so Moodle 2.0 will natively-on-the-fly be able to process 1.9 files. Impossible!
**** Keep it within Moodle, so conversion will be executed transparently immediately before restore (in the original plan at [[Backup 2.0 multiple formats]].
**** Completely separate utility, so files need to be transformed before being accepted by restore.
**** Never
*** Where:
**** Restore everything into some duplicate tables in order to do the conversion there.
**** Do that into memory/some specialised tables not duplicating anything.
**** Nowhere
* Scheduled backups (it's just a "timed" backup iterator). Do we want it to continue being part of Moodle or have a separate utility. Using moodle cron or its own one?
* Incremental backup/restore. Is also a external thing. We provide constant "content" by separating envelopes and content, but all the "diff", "patch" stuff is no related with Moodle at all.
* Structures over course level. They are a pain. Can lead to non-restorable courses or differently-behaviour courses.
* ... more ideas/things..

Backup 2.0

2022-05-03T19:02:34Z

Stronk7:

{{Template:WillNotMigrate}}{{Template:Backup 2.0}}{{Moodle_2.0}}__NOTOC__{{Work in progress}}
== Summary & Objectives ==
The backup & restore functionality has been present since Moodle 1.1 (29 August 2003, more than six years ago!) and, although it has been continuously improved and renewed, the core has remained basically the same.

Many things have evolved since then both in Moodle and PHP-land so this project is an attempt to rework the backup & restore functionality in order to achieve these goals:

* '''Modernise''' the code base, using actual PHP/DB techniques: OOP, exceptions, temporary DB tables, transactions... aiming to reduce the current ''"spaghetti code"'' in various places.
* '''Unify''' current developments, so all backup alternatives (manual, export, silent, scheduled...) will be executed by the same code base (also for restore/import of course).
* '''Improve''' the process, making it more reliable, being able to pre-detect wrong situations, rollback (if possible) to previous states, and apply any possible benefit both for speed (some interim in-memory caches) and memory (better parsing techniques).
* Improve '''Security''', so the Moodle permissions structure will be 100% respected and any user data disclosure will be avoided, of course, whilst giving the admins the flexibility to change default behaviours by configuring them in a standard way.
* '''New features''' requested from the Community will be added. Things like fine grained control of various restore parts, the ability to backup not only course structures, but sections or individual activities, anonymised backups and so on will début with Moodle 2.0. See the [[Backup 2.0 requirements|requirements]] section for more info.

== Implementation plan ==

META bug in the Tracker: MDL-21432

Release process

2022-04-30T18:08:54Z

Stronk7: Moving the requirements issue to point 2 (and removing the, not needed anymore, behat-extension point. Add point about to ensure all new jobs @ CIs are enabled.

== 8 weeks prior ==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Recurring release epics review:
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous deprecation epics are going] and share about them.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Ensure we are running latest/good behat, phpunit and nodejs (npm) versions.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm external testers daily availability from -6w to release (internally with dev manager and then, externally, with contractors). They start in just 2 weeks!
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| - Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249.
- Remind devs:
* To label issues qa_test_required when a new feature/improvement is landing without automated tests. Also add a comment advising exactly what should be covered in the QA test e.g. steps 6-10 in testing instructions.
* The best possible lang strings land at first attempt. Given the proximity of the major release and to facilitate the work of translators and others... the sooner, the better, instead of relying on (late) en_fixes too much.
| Testing Maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| - Create a "Must fix for X.Y" version in the Tracker and adjust the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Set%20integration%20priority%20to%20one/ "TR - Set integration priority to one"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20reopened%20out%20from%20current/ "TR - Move reopened out from current"] jobs in '''all CI servers''' to point to it.
- Apply the following changes to filters and dashboards:
* Edit the [https://tracker.moodle.org/issues/?filter=21363 All "must fix" issues] filter used both in the release dashboard and to detect wrong uses of must-fix issues. Note that, since 3.7, this filter is fully automated and does not need edition (uses regexp to catch all must fix versions).
* Comment about its creation within HQ, to get people applying for it.
* Verify that these filters ([https://tracker.moodle.org/issues/?filter=18596 1], [https://tracker.moodle.org/issues/?filter=18594 2] and [https://tracker.moodle.org/issues/?filter=18861 3]), used in the [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard], are working ok (they should be, automatically based in the filter edited in the previous point).
* Rename [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard] to point to incoming release (QA part of the dashboard will not work yet)
| Integration Team
|}
==7 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze.
| Head of LMS
|-
| 2.
| style="text-align:center" | ✓
|
| Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20qa_test_required%20AND%20status%20%3D%20Closed closed qa_test_required-labelled issues] and create new QA tests as required.
| Testing Maintainer
|-
|}
==6 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| The [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period Continuous Integration] period begins. Warn about it everywhere (telegram, exposed posts...).
Rolling (on demand, beta, rc... all them together with stable weeklies) happens often (Tuesday & Friday are the usual days). All the team is on integration 100% since this week and until the end of continuous.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Create the next "X.Y+1" (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Warn external developers about the impending code freeze in a post to the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Let the community know [[QA testing]] starts in two weeks and how they can participate.
| Community Manager
|}
==5 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Confirm the code freeze by replying to the previous warning in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum].
| Development manager
|-
| 2.
| style="text-align:center" | ✓
|
| This week, once the freeze has happened at 11:00 UTC:
* The [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job has to be disabled.
* Immediately after that, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration] job must be enabled and executed, only once, and all the candidate issues already @ integration will come to the current queue. All them did the freeze.
* Once run, disable the job again to avoid executing it by mistake.
* Once the previous job has ended, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job, in charge of managing the integration queues after freeze, will be enabled (until the end of on-sync). It performs some tasks like moving important (must fix, qa, security...) issues to the current integration queue and also keep if fed by priority when there are few issues remaining. '''Don't forget''' to configure the "releasedate" date to get it automatically holding issues the last week (instead of moving them to current integration) and also processing issues over the on-sync (after release) period.
Irrespectively from any automation, issues can, also, be manually picked for integration until the post-release "On Sync" period ends, usually 2 weeks after release.

Review all the new features and improvements so, everything "unrelated" with the release, is given the "integration_held" label. That means that will be ignored unless there is an [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period unhold request process] started on them.

Dev leaders promptly vote on held issues labelled with unhold_requested label and decide whether they can be allowed to break the freeze.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Prepare a fresh installation of the [http://qa.moodle.net QA site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.
| QA Master Site Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Begin reviewing [https://lang.moodle.org/mod/forum/view.php?id=7 new and changed English language strings] ready for en_fix to be merged 2 weeks prior.
| English fixes lang pack maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| Review standards certifications (Open Badges, LTI, etc) and schedule in recertification to be performed.
| Development Manager
|}
==4 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Start reviewing fixed issues and add the release_notes label to all issues to be listed in the release notes.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Review requirements for adding user tours for new features in the upcoming release (clone of MDL-72783). Review existing tours and remove very old ones (clone of MDL-72781)
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
|
| Beta release (The Moodle release tool - mdlrelease - manages it): Release normal weeklies but with these changes in the master branch being considered all the time, until we are feature complete (can happen @ -4w - ideally - but also later):
* version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Once the beta is available create the "[https://docs.google.com/spreadsheets/d/1TcMJT3o2Cnyq006lmLWrXJeNQQzyNXz2E_Vbc8ff5EE/edit?usp=sharing|Release testing matrix for X.Y.0]" and share it @ HQ & Dev. chat.
* (Optionally) Announce Beta release in forums (ideally once packages are available).
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Clone MDL-72815 for the X.Y release, adding there all the debugging / PHP notices happening in the web server logs while running tests.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
|
| Release candidates release (The Moodle release tool - mdlrelease - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:
* version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-rcZ" (and MOODLE_XY_RCZ as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).
* Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.
* These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&id=1532512
| Plugins Liaison
|-
| 7.
| style="text-align:center" | ✓
|
| Push any plugins to the plugins database which were previously a part of core.
| Plugins Liaison
|-
| 8.
| style="text-align:center" | ✓
|
| Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [[New docs version process]].
| Community Manager
|-
| 9.
| style="text-align:center" | ✓
|
| Create new QA test cycle and post in moodle.org front page news forum about [[QA testing]].
| Testing Maintainer
|-
| 10.
| style="text-align:center" | ✓
|
| Invite community volunteers to start [[QA testing]].
| Community Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Modify [https://tracker.moodle.org/issues/?filter=11824 Current QA cycle filter] to link to the new QA test cycle
| Testing Maintainer
|-
| 12.
| style="text-align:center" | ✓
|
| Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.
| Testing Maintainer
|-
| 13.
| style="text-align:center" | ✓
|
| Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately.
| Development Manager
|-
| 14.
| style="text-align:center" | ✓
|
| Review the [https://tracker.moodle.org/issues/?filter=17705&jql=filter%20%3D%2011701%20AND%20type%20!%3D%20Bug list of features and improvements submitted before code freeze] which are awaiting integration review and decide on related QA tests to be put on hold.
| Development Manager
|}
==3 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Ask developers to begin QA tests marked [https://tracker.moodle.org/issues/?filter=22055 external_skipped] then [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20test_server_required%20 test_server_required tests] and [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20credentials_required credentials_required tests].
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Create new en and de Moodle Docs version wikis.
| Moodle Docs Maintainer
|-
| 3.
| style="text-align:center" | ✓
|
| Go through all points listed under 3 weeks prior in [[New docs version process]].
| Community Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Review issues with labelled with [https://tracker.moodle.org/issues/?filter=11824&jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC dev_docs_required], prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated.
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify how everything is going and, before the end of the week, decide (dev leaders & integrators) if there are real reasons for delaying any release. Whenever a delay is agreed, run the ''"Release delaying process"'' (doc) actions ASAP.

'''Important note:''' ASAP stands for as soon as possible ;-), the delay needs to happen before the last week before release begins (there are flows changing that week requiring the decision and actions to be taken and applied earlier).
| Development Manager
|}
==2 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
|
Check the number of open QA tests. Depending on the amount of work involved, encourage HQ developers to assist from the start of the week or later in the week in order to achieve the target of 100% pass rate by the end of the week.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
|
Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Merge fixes from en_fix pack and then integrate them.
| AMOS Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Give Partners complete brandable Marketing pack for release including list and description of major new features.
| Marketing Manager
|-
| 5.
| style="text-align:center" | ✓
|
| Label (ui_change) in the Tracker all pending issues having '''noticeable UI modifications''' and track them in the "[https://docs.google.com/spreadsheets/d/18xZf9OgKrndi7CwSTwjwjF_rzGYCWFuGjNNaaDVZDM4/edit?usp=sharing Late landing UI changes]" sheet, in order to have all the associated docs, screenshots, videos under control. The Integration and Documentation people will try to '''keep the sheet updated until release'''.
|Integration Team
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
|
For major releases, use (clone if needed) MDL-72836 to keep the security.txt files in all supported branches updated. For minor releases, also check the security.txt expiry dates in all security supported branches in case known release delays will result in any security.txt expiring before the next release - in that case relevant branches should also be updated.
| Security Officer
|}
==1 week prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Clone MDL-71583 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on the [http://moodle.org/mod/forum/view.php?id=55 General Developer forum] and [https://moodleassociation.org/ MUA website].
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on Twitter and other outlets.
| Marketing Officer
|-
| 7.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Identify security issues that need to be integrated using the [https://tracker.moodle.org/issues/?filter=21712 security issues under integration filter] (includes held, being integrated and ready issues).
* Integrate from provided patches into supported branches (including branches supported only for security issues).
* Ensure security issues are given priority in weekly integration and testing. Note that the --weekly releases to be performed this week are 100% normal and cover the standard (supported) branches. security branches will come as part of the release process later in the week.
| Integration Team
|-
| 8.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Collect security issues into a clone of the [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20level%20is%20not%20EMPTY%20AND%20summary%20~%20%22security%20advisories%22%20ORDER%20BY%20updated%20DESC last advisory in the list] to prepare for release of Security Advisories.
* Determine which security issues will be integrated.
* Request CVE Identifiers by emailing issue descriptions to [mailto:secalert@redhat.com secalert@redhat.com] with a message like... <tt> The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC.</tt> The email subject should include the characters <tt>[vs]</tt>. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available (since 2015 we request identifiers from redhat and not from distros).
* Post security issues as a reply to the "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Release notes tasks:
* Review and complete the [[Releases|release notes]], making sure that issues have easily understandable summaries. Aim to have the release notes mostly complete on the Wednesday before release, and fully complete on the Friday, to give translators time to translate them.
* Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
| Development Manager
|-
| 10.
| style="text-align:center" | ✓
|
| Review the following issues:
* Check on the [https://tracker.moodle.org/issues/?filter=21363 "Must fix for X.Y version"]. Filter out unrealistic issues.
* Check on the [https://tracker.moodle.org/issues/?filter=22350 "Bug issues held last week before release"]. Consider to request the unholding of release related/blocker ones.
| Development Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Upgrade moodle.org to beta release
|
|-
| 12.
| style="text-align:center" | ✓
|
| Prepare pull requests for CI Repositories:
* MR1: Create a new version, with unit tests, in Jobs repository ([https://git.in.moodle.com/integration/nightlyjobs/merge_requests/24 see example from 3.11 release])
* MR2: Create a new symlink for the version in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/41 see example from 3.11 release])
* MR3: Configure CIs to skip language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/35 see example from 3.10 release])
* MR4: Configure CIs to stop skipping language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository for after on-sync ([https://github.com/moodlehq/moodle-ci-runner/pull/40 see example from 3.10 release]) -- Note: This change should be based on the previous and only applied when the lang packs corresponding to the version being released are available.
| Integration Team
|-
| 13.
| style="text-align:center" | ✓
|
| Go through all points listed under 1 week prior in [[New docs version process]].
| Community Manager
|-
|}
==Releasing==
===Packaging===
This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Check list:
* Make sure there are no real blockers introduced in the last weekly (install / upgrade ...).
* Confirm that the latest [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc en_fix changes]have been generated and integrated.
* Verify that [https://tracker.moodle.org/issues/?jql=text%20~%20%22%2BPrepare%20%2Bsecurity%20%2Badvisories%20%2Bfriends%22%20ORDER%20BY%20updated%20DESC all security issues] have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify all unit tests and integration tests have passed (check all current CI servers in use).
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Verify QA tests have passed.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Timing prerequisites (don't continue with the process if not within the time window!):
# Latest weeklies before the minor/major releases must be done (moodle-package-extract-and-postprocess email should confirm this has happened around 09:00 Australia/Perth).
# Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).
(in practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). Breaking any of these rules will require manual operation in the server, forcing repackaging and releasing.

Follow the "mdlrelease" steps:
* Run the '''prerelease.sh''' script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg, travis changes (only for majors)... Triple verify all changes are correct! (can use the --show option to inspect them). Follow the on-screen instructions.
* Push changes to integration.git (but tags).
For major releases, only when a new STABLE branch has been created:
* Run the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
* Push changes to integration.git - note this will lead to the "versions checker" failing for master, no problem, it will be fixed by the 1st cloned issue at #12 below).
* Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY stable branch.
* Update the old CI server(s) by cloning all the "master" jobs to a new "MXY" view (trick: do it down-top, way easier). Don't forget to re-chain the jobs properly.
** Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE.
** Configure the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
** Run all them.
* Update the new CI infrastructure:
** MR1: Merge pull request for new version in [https://git.in.moodle.com/integration/nightlyjobs CI Jobs Repository]
** MR2: Merge pull request for symlink in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
** MR3: Merge pull request for skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
** Clone all the "B - master" jobs to a new "B - XY" view (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20view/ maintenance job] to perform the operation).
Both with minors and majors, continue with the "mdlrelease" steps:
* Once CI servers have ended and all jobs have passed, '''push tags''' and run the '''release.sh''' script to apply the changes to moodle.git.
* If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
* Don't forget the "[https://github.com/moodlehq/mdlrelease/#after-the-release After the release]" tasks.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "git repos updated & tagged" message on the [https://partners.moodle.com/mod/forum/view.php?id=810 Partner forum]
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| In the [https://github.com/moodlehq/moodle-performance-comparison performance comparison repository], set the new release commit hash as $basecommit in the master branch and create a new MOODLE_XY_STABLE branch from it. ([https://github.com/moodlehq/moodle-performance-comparison/commit/7c875f03e52641f69674235a8947131d77691299 example]). Also, apply it to the current performance testing infrastructure.
| Integration Team
|-
| 7.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email).
| Integration Team
|-
| 8.
| style="text-align:center" | ✓
|
|
* Create new windows packager script (cloning the current master one and configuring it).
* Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Push it. Next time the plugin is deployed (normally 1 week after release, aprox.) the stats will start showing the new branch statistics.
| Integration Team
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| In the Tracker...
* Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Plugins project].
* Archive all versions but the ones being released, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
* Remove from all screens the custom fields belonging to 100% unsupported branches.
For major releases only:
* Release and archive the [https://tracker.moodle.org/issues/?jql=affectedVersion%20~%20%22must%20fix%20for*%22%20OR%20fixVersion%20~%20%22must%20fix%20for*%22 "Must fix for X.Y" versions], it must be empty to do so.
| Integration Team
|-
| 10.
| style="text-align:center" | ✓
|
|
* Create the new "Pull X.Y Branch" and "Pull X.Y Diff URL" custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Re-index Tracker.
* In the CI server edit the [http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ "Bulk precheck issues"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(awaiting_integration)/ "Pre-launch DEV jobs (awaiting_integration)"], [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(list_of_mdls)/ "Pre-launch DEV jobs (list_of_mdsl)"] and [https://ci.moodle.org/view/Tracker/job/STR%20-%20Bulk%20pre-launch%20SDEV%20jobs%20(list_of_mdls)/ "Pre-launch SDEV jobs (list_of_mdsl)"] jobs to make them meet the new "Pull X.Y Branch" field created. At the same time, remove from those jobs any branch belonging to 100% unsupported branches.
* Edit the "Tracker - CI - Check marked as integrated" job ([https://ci.moodle.org/view/Tracker/job/TR%20-%20Check%20marked%20as%20integrated/ link]) to configure the development branches (devbranches) (39, 310, 311, 400...) actually active. Normally only the branch corresponding to master, but also accepts a comma separated list when under parallel development ("310,400" or "311,400" for example). Ordered by planned release date.
* Check/configure (again, this may be has been already executed few steps above) the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
| Integration Team
|-
| 11.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| In the Tracker...
For major releases only:
* Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.
* Adjust the [https://tracker.moodle.org/issues/?filter=17528 Latest regressions] filter (requires login).
For all releases:
* Verify how the "X.Y regressions" versions [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(versionMatches(%22.*regressions%22)) are going] (requires login) and ping Development Managers about. Package and archive them once empty.
| Integration Team
|-
| 12.
| style="text-align:center" | ✓
|
| Clone MDL-74509 and MDL-74510, to be resolved ASAP.
| Integration Team
|-
| 13.
| style="text-align:center" | ✓
|
|
* Create the new MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security repo (branching from the just created upstream MOODLE_XY_STABLE branch).
* Cherry pick any security commit present in the security repository's master branch to the new MOODLE_XY_STABLE branch (note that normally there should not be any, see point #1 check list above).
* Verify the new security jobs exist for the new branch and check it's working in all servers, keeping only enabled the public one.
| Integration Team
|-
| 14.
| style="text-align:center" | ✓
|
| Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 )
| Integration Team
|}
===Release day===
Usually on Monday
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| The execution of "moodle-package-extract-and-postprocess X" script may be needed if the releases '''are not going to be published on Monday''' but another weekday (X is the weekday, (1-7) starting in Monday).
By default it happens automatically around 09:00 AM Perth/Australia time (check emails then).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify release status, download pages and windows packages.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Notify all registered sys admins, including security notes with CVE identifiers, using the [http://lists.moodle.org/ mailing list server].
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
|
| Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]
| Head of LMS
|-
| 7.
|
| style="text-align:center" | ✓
| Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]
| Development Manager
|-
| 8.
| style="text-align:center" | ✓
|
| New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period.
| AMOS Maintainer
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify, 24h after tagging, that https://moodle.org/dev/contributions.php has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!
| Integration Team
|-
| 10.
| style="text-align:center" | ✓
|
| For en and de Moodle Docs, update default redirects and enable email notifications.
| Moodle Docs Maintainer
|-
| 11.
| style="text-align:center" | ✓
|
| Go through all points listed under Day of release in [[New docs version process]].
| Community Manager
|-
| 12.
| style="text-align:center" | ✓
|
|
* Decide the "Full demo", "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar]. They will be -7w, -5w and -4w before release date respectively.
* Update the "Full demo", "Code freeze", "QA begins" and Release dates on the [[Roadmap]] page.
* Add events to the HQ calendar for next Major release 6-months cycle according to [[Process#Sprints|the cycle plan]]: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
* Notify the Community Manager of new dates to be added to the moodle.org calendar.
| Development Manager
|-
| 13.
| style="text-align:center" | ✓
| style="text-align:center" |
| Add calendar events in the [https://moodle.org/calendar moodle.org calendar] for coming Major and Minor releases up to the next Major release.
| Community Manager
|-
| 14.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Update release schedule image on [[Releases#Version_support|Releases page]]
| Development Manager
|-
| 15.
| style="text-align:center" | ✓
|
| Important: This must be done '''once it's already release day @ UTC''' (aka, after Australia/Perth 08:00) or the '''queues manage with hold them again''' because it's still "last week before release".
The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed '''only''' [https://tracker.moodle.org/issues/?jql=filter%3D13669%20AND%20type%20in%20(bug%2C%20task%2C%20Sub-task) from '''bug issues''' awaiting integration]; they correspond to last-week bugs that were held because of them being unrelated with the release. Now they can be processed, under on-sync rules. Standard message will be used to explain the un-hold.
| Integration Team
|}
==1 week after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).
For major releases, within the on-sync period, master packages will be generated using the prerelease.sh script (--type on-sync). That guarantees XY_STABLE and master versions are kept the same. The last week, when leaving the on-sync period, master package will be generated normally (implicit --type weekly), so versions will diverge and dev can continue separately from that point.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Update the version.php in git to be X.Y.Z+ during the next weekly integration process
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].) Add note to top of relevant version page about security support.
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
|| Security Officer
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Notify about publications of CVE using form: https://cveform.mitre.org/
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
|
| Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
|
|-
| 7.
| style="text-align:center" | ✓
|
| '''Deprecations:'''
* Create the next deprecation epic (for X.Y+1+2y) similar to MDL-74579 and add standard issues to it:
** Final deprecation of lib/deprecatedlib.php (like MDL-74580)
** Removal of deprecated Behat steps (like MDL-74581)
** Removal of strings (like MDL-74582) and
** Removal of renamed classes (MDL-74583).
The issue can be based/cloned on the previous one and linked ("has to be done after") with it.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous deprecation epics are going] and share about them.

'''Libraries:'''
* Create the next third party libraries epic for X.Y+1, similar to MDL-73715. The issue should refer to the list of [[Moodle libraries credits]]. The issue can be based/cloned on the previous one and linked ("has to be done after") with it. '''Drag/link opened issues from the previous one''', avoiding leaving unfinished stuff.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20(summary%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20OR%20summary%20~%20%22Review%20third-party%20libraries%20for%20upgrade%22)%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|}
==2 weeks after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Once the "On Sync" period ends:
* Confirm that versions (XY_STABLE and master) diverged properly the last on-sync week. If not, proceed to it by manually bumping master the version to currentthe date @ integration.git.
* Disable the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job. It has served us well.
* The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed from all issues awaiting integration, so they will be, automatically (see next point), be moved to current integration. Send a "unnholding + rebase" message to all those issues.
* Enable the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job. It will control the queues over coming months, until nextthe freeze.
* In the [https://ci.moodle.org/ Jenkins CI server] enable all the jobs corresponding to the new branch (B-XYZ view) that were created on packaging day.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| The discussion about environmental requirements for next X.Y+1 major release (MDL-71747) will end and the issue will be resolved '''immediately'''. A new issue, about the requirements for nextthe -next X.Y+2 major release wil,l be created at the same time by cloning the previous one and dragging any non-resolved detail (due date = 3w after release).
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Ensure [https://download.moodle.org/langpack/X.Y+1/ Language pack for master (X.Y+1)] is available and merge the pull request MR4 for stop skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Ensure release retrospectives are held for each of the LMS teams and results are actioned.
| Development Manager / Head of LMS
|}

==1 month after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Remove, in CI servers, all the jobs and views corresponding to branches which support has ended completely. (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Remove%20all%20jobs%20from%20view/ maintenance job] to perform the operation).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Upgrade all the Moodle CI sites to recent major release by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm that there isn't any remaining [https://tracker.moodle.org/issues/?filter=13669 integration_held] issue from latest release, proceeding to uhhold them immediately. Note that there may exist [https://tracker.moodle.org/issues/?filter=13669&jql=project%20%3D%20MDL%20AND%20labels%20in%20(integration_held)%20ORDER%20BY%20%22Integration%20priority%22%20DESC%2C%20priority%20DESC%2C%20votes%20DESC%2C%20%22Last%20comment%20date%22%20ASC other "held" issues], unrelated with latest release. This process step does not affect them.
| Integration Team
|}
==See also==
* [[Deprecation|Deprecation process]]
[[Category:Processes|Release process]]
[[Category:Release notes|Release process]]

Release process

2022-04-27T08:02:36Z

Stronk7: reordering a little bit, so things happen in correct order

== 8 weeks prior ==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Recurring release epics review:
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous deprecation epics are going] and share about them.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Ensure we are running latest/good behat, phpunit and nodejs (npm) versions.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm external testers daily availability from -6w to release (internally with dev manager and then, externally, with contractors). They start in just 2 weeks!
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| - Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249.
- Remind devs:
* To label issues qa_test_required when a new feature/improvement is landing without automated tests. Also add a comment advising exactly what should be covered in the QA test e.g. steps 6-10 in testing instructions.
* The best possible lang strings land at first attempt. Given the proximity of the major release and to facilitate the work of translators and others... the sooner, the better, instead of relying on (late) en_fixes too much.
| Testing Maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| - Create a "Must fix for X.Y" version in the Tracker and adjust the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Set%20integration%20priority%20to%20one/ "TR - Set integration priority to one"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20reopened%20out%20from%20current/ "TR - Move reopened out from current"] jobs in '''all CI servers''' to point to it.
- Apply the following changes to filters and dashboards:
* Edit the [https://tracker.moodle.org/issues/?filter=21363 All "must fix" issues] filter used both in the release dashboard and to detect wrong uses of must-fix issues. Note that, since 3.7, this filter is fully automated and does not need edition (uses regexp to catch all must fix versions).
* Comment about its creation within HQ, to get people applying for it.
* Verify that these filters ([https://tracker.moodle.org/issues/?filter=18596 1], [https://tracker.moodle.org/issues/?filter=18594 2] and [https://tracker.moodle.org/issues/?filter=18861 3]), used in the [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard], are working ok (they should be, automatically based in the filter edited in the previous point).
* Rename [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard] to point to incoming release (QA part of the dashboard will not work yet)
| Integration Team
|}
==7 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze.
| Head of LMS
|-
| 2.
| style="text-align:center" | ✓
|
| Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20qa_test_required%20AND%20status%20%3D%20Closed closed qa_test_required-labelled issues] and create new QA tests as required.
| Testing Maintainer
|-
|}
==6 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| The [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period Continuous Integration] period begins. Warn about it everywhere (telegram, exposed posts...).
Rolling (on demand, beta, rc... all them together with stable weeklies) happens often (Tuesday & Friday are the usual days). All the team is on integration 100% since this week and until the end of continuous.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Create the next "X.Y+1" (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Warn external developers about the impending code freeze in a post to the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Let the community know [[QA testing]] starts in two weeks and how they can participate.
| Community Manager
|}
==5 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Confirm the code freeze by replying to the previous warning in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum].
| Development manager
|-
| 2.
| style="text-align:center" | ✓
|
| This week, once the freeze has happened at 11:00 UTC:
* The [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job has to be disabled.
* Immediately after that, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration] job must be enabled and executed, only once, and all the candidate issues already @ integration will come to the current queue. All them did the freeze.
* Once run, disable the job again to avoid executing it by mistake.
* Once the previous job has ended, the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job, in charge of managing the integration queues after freeze, will be enabled (until the end of on-sync). It performs some tasks like moving important (must fix, qa, security...) issues to the current integration queue and also keep if fed by priority when there are few issues remaining. '''Don't forget''' to configure the "releasedate" date to get it automatically holding issues the last week (instead of moving them to current integration) and also processing issues over the on-sync (after release) period.
Irrespectively from any automation, issues can, also, be manually picked for integration until the post-release "On Sync" period ends, usually 2 weeks after release.

Review all the new features and improvements so, everything "unrelated" with the release, is given the "integration_held" label. That means that will be ignored unless there is an [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period unhold request process] started on them.

Dev leaders promptly vote on held issues labelled with unhold_requested label and decide whether they can be allowed to break the freeze.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Prepare a fresh installation of the [http://qa.moodle.net QA site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.
| QA Master Site Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Begin reviewing [https://lang.moodle.org/mod/forum/view.php?id=7 new and changed English language strings] ready for en_fix to be merged 2 weeks prior.
| English fixes lang pack maintainer
|-
| 5.
| style="text-align:center" | ✓
|
| Review standards certifications (Open Badges, LTI, etc) and schedule in recertification to be performed.
| Development Manager
|}
==4 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Start reviewing fixed issues and add the release_notes label to all issues to be listed in the release notes.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Review requirements for adding user tours for new features in the upcoming release (clone of MDL-72783). Review existing tours and remove very old ones (clone of MDL-72781)
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
|
| Beta release (The Moodle release tool - mdlrelease - manages it): Release normal weeklies but with these changes in the master branch being considered all the time, until we are feature complete (can happen @ -4w - ideally - but also later):
* version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Once the beta is available create the "[https://docs.google.com/spreadsheets/d/1TcMJT3o2Cnyq006lmLWrXJeNQQzyNXz2E_Vbc8ff5EE/edit?usp=sharing|Release testing matrix for X.Y.0]" and share it @ HQ & Dev. chat.
* (Optionally) Announce Beta release in forums (ideally once packages are available).
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Clone MDL-72815 for the X.Y release, adding there all the debugging / PHP notices happening in the web server logs while running tests.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
|
| Release candidates release (The Moodle release tool - mdlrelease - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:
* version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'
* tag git repo with: "vX.Y.0-rcZ" (and MOODLE_XY_RCZ as description and CVS tag)
* Automatic: Confirm packages are available under download.moodle.org (and windows).
* Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).
* Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.
* These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&id=1532512
| Plugins Liaison
|-
| 7.
| style="text-align:center" | ✓
|
| Push any plugins to the plugins database which were previously a part of core.
| Plugins Liaison
|-
| 8.
| style="text-align:center" | ✓
|
| Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [[New docs version process]].
| Community Manager
|-
| 9.
| style="text-align:center" | ✓
|
| Create new QA test cycle and post in moodle.org front page news forum about [[QA testing]].
| Testing Maintainer
|-
| 10.
| style="text-align:center" | ✓
|
| Invite community volunteers to start [[QA testing]].
| Community Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Modify [https://tracker.moodle.org/issues/?filter=11824 Current QA cycle filter] to link to the new QA test cycle
| Testing Maintainer
|-
| 12.
| style="text-align:center" | ✓
|
| Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.
| Testing Maintainer
|-
| 13.
| style="text-align:center" | ✓
|
| Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately.
| Development Manager
|-
| 14.
| style="text-align:center" | ✓
|
| Review the [https://tracker.moodle.org/issues/?filter=17705&jql=filter%20%3D%2011701%20AND%20type%20!%3D%20Bug list of features and improvements submitted before code freeze] which are awaiting integration review and decide on related QA tests to be put on hold.
| Development Manager
|}
==3 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Ask developers to begin QA tests marked [https://tracker.moodle.org/issues/?filter=22055 external_skipped] then [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20test_server_required%20 test_server_required tests] and [https://tracker.moodle.org/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20credentials_required credentials_required tests].
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
| Create new en and de Moodle Docs version wikis.
| Moodle Docs Maintainer
|-
| 3.
| style="text-align:center" | ✓
|
| Go through all points listed under 3 weeks prior in [[New docs version process]].
| Community Manager
|-
| 4.
| style="text-align:center" | ✓
|
| Review issues with labelled with [https://tracker.moodle.org/issues/?filter=11824&jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC dev_docs_required], prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated.
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify how everything is going and, before the end of the week, decide (dev leaders & integrators) if there are real reasons for delaying any release. Whenever a delay is agreed, run the ''"Release delaying process"'' (doc) actions ASAP.

'''Important note:''' ASAP stands for as soon as possible ;-), the delay needs to happen before the last week before release begins (there are flows changing that week requiring the decision and actions to be taken and applied earlier).
| Development Manager
|}
==2 weeks prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
|
Check the number of open QA tests. Depending on the amount of work involved, encourage HQ developers to assist from the start of the week or later in the week in order to achieve the target of 100% pass rate by the end of the week.
| Development Manager
|-
| 2.
| style="text-align:center" | ✓
|
|
Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net
| Development Manager
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Merge fixes from en_fix pack and then integrate them.
| AMOS Maintainer
|-
| 4.
| style="text-align:center" | ✓
|
| Give Partners complete brandable Marketing pack for release including list and description of major new features.
| Marketing Manager
|-
| 5.
| style="text-align:center" | ✓
|
| Label (ui_change) in the Tracker all pending issues having '''noticeable UI modifications''' and track them in the "[https://docs.google.com/spreadsheets/d/18xZf9OgKrndi7CwSTwjwjF_rzGYCWFuGjNNaaDVZDM4/edit?usp=sharing Late landing UI changes]" sheet, in order to have all the associated docs, screenshots, videos under control. The Integration and Documentation people will try to '''keep the sheet updated until release'''.
|Integration Team
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
|
For major releases, use (clone if needed) MDL-72836 to keep the security.txt files in all supported branches updated. For minor releases, also check the security.txt expiry dates in all security supported branches in case known release delays will result in any security.txt expiring before the next release - in that case relevant branches should also be updated.
| Security Officer
|}
==1 week prior==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Clone MDL-71583 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on the [http://moodle.org/mod/forum/view.php?id=55 General Developer forum] and [https://moodleassociation.org/ MUA website].
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "Heads-up" message on Twitter and other outlets.
| Marketing Officer
|-
| 7.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Identify security issues that need to be integrated using the [https://tracker.moodle.org/issues/?filter=21712 security issues under integration filter] (includes held, being integrated and ready issues).
* Integrate from provided patches into supported branches (including branches supported only for security issues).
* Ensure security issues are given priority in weekly integration and testing. Note that the --weekly releases to be performed this week are 100% normal and cover the standard (supported) branches. security branches will come as part of the release process later in the week.
| Integration Team
|-
| 8.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Collect security issues into a clone of the [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20level%20is%20not%20EMPTY%20AND%20summary%20~%20%22security%20advisories%22%20ORDER%20BY%20updated%20DESC last advisory in the list] to prepare for release of Security Advisories.
* Determine which security issues will be integrated.
* Request CVE Identifiers by emailing issue descriptions to [mailto:secalert@redhat.com secalert@redhat.com] with a message like... <tt> The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC.</tt> The email subject should include the characters <tt>[vs]</tt>. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available (since 2015 we request identifiers from redhat and not from distros).
* Post security issues as a reply to the "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| Security Officer
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Release notes tasks:
* Review and complete the [[Releases|release notes]], making sure that issues have easily understandable summaries. Aim to have the release notes mostly complete on the Wednesday before release, and fully complete on the Friday, to give translators time to translate them.
* Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
| Development Manager
|-
| 10.
| style="text-align:center" | ✓
|
| Review the following issues:
* Check on the [https://tracker.moodle.org/issues/?filter=21363 "Must fix for X.Y version"]. Filter out unrealistic issues.
* Check on the [https://tracker.moodle.org/issues/?filter=22350 "Bug issues held last week before release"]. Consider to request the unholding of release related/blocker ones.
| Development Manager
|-
| 11.
| style="text-align:center" | ✓
|
| Upgrade moodle.org to beta release
|
|-
| 12.
| style="text-align:center" | ✓
|
| Prepare pull requests for CI Repositories:
* MR1: Create a new version, with unit tests, in Jobs repository ([https://git.in.moodle.com/integration/nightlyjobs/merge_requests/24 see example from 3.11 release])
* MR2: Create a new symlink for the version in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/41 see example from 3.11 release])
* MR3: Configure CIs to skip language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/pull/35 see example from 3.10 release])
* MR4: Configure CIs to stop skipping language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository for after on-sync ([https://github.com/moodlehq/moodle-ci-runner/pull/40 see example from 3.10 release]) -- Note: This change should be based on the previous and only applied when the lang packs corresponding to the version being released are available.
| Integration Team
|-
| 13.
| style="text-align:center" | ✓
|
| Go through all points listed under 1 week prior in [[New docs version process]].
| Community Manager
|-
|}
==Releasing==
===Packaging===
This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Check list:
* Make sure there are no real blockers introduced in the last weekly (install / upgrade ...).
* Confirm that the latest [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc en_fix changes]have been generated and integrated.
* Verify that [https://tracker.moodle.org/issues/?jql=text%20~%20%22%2BPrepare%20%2Bsecurity%20%2Badvisories%20%2Bfriends%22%20ORDER%20BY%20updated%20DESC all security issues] have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify all unit tests and integration tests have passed (check all current CI servers in use).
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Verify QA tests have passed.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Timing prerequisites (don't continue with the process if not within the time window!):
# Latest weeklies before the minor/major releases must be done (moodle-package-extract-and-postprocess email should confirm this has happened around 09:00 Australia/Perth).
# Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).
(in practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). Breaking any of these rules will require manual operation in the server, forcing repackaging and releasing.

Follow the "mdlrelease" steps:
* Run the '''prerelease.sh''' script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg, travis changes (only for majors)... Triple verify all changes are correct! (can use the --show option to inspect them). Follow the on-screen instructions.
* Push changes to integration.git (but tags).
For major releases, only when a new STABLE branch has been created:
* Run the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
* Push changes to integration.git - note this will lead to the "versions checker" failing for master, no problem, it will be fixed by the 1st cloned issue at #12 below).
* Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY stable branch.
* Update the old CI server(s) by cloning all the "master" jobs to a new "MXY" view (trick: do it down-top, way easier). Don't forget to re-chain the jobs properly.
** Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE.
** Configure the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
** Run all them.
* Update the new CI infrastructure:
** MR1: Merge pull request for new version in [https://git.in.moodle.com/integration/nightlyjobs CI Jobs Repository]
** MR2: Merge pull request for symlink in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
** MR3: Merge pull request for skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
** Clone all the "B - master" jobs to a new "B - XY" view (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20view/ maintenance job] to perform the operation).
Both with minors and majors, continue with the "mdlrelease" steps:
* Once CI servers have ended and all jobs have passed, '''push tags''' and run the '''release.sh''' script to apply the changes to moodle.git.
* If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
* Don't forget the "[https://github.com/moodlehq/mdlrelease/#after-the-release After the release]" tasks.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Post a "git repos updated & tagged" message on the [https://partners.moodle.com/mod/forum/view.php?id=810 Partner forum]
| Integration Team
|-
| 6.
| style="text-align:center" | ✓
|
| In the [https://github.com/moodlehq/moodle-performance-comparison performance comparison repository], set the new release commit hash as $basecommit in the master branch and create a new MOODLE_XY_STABLE branch from it. ([https://github.com/moodlehq/moodle-performance-comparison/commit/7c875f03e52641f69674235a8947131d77691299 example]). Also, apply it to the current performance testing infrastructure.
| Integration Team
|-
| 7.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email).
| Integration Team
|-
| 8.
| style="text-align:center" | ✓
|
|
* Create new windows packager script (cloning the current master one and configuring it).
* Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Push it. Next time the plugin is deployed (normally 1 week after release, aprox.) the stats will start showing the new branch statistics.
| Integration Team
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| In the Tracker...
* Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Plugins project].
* Archive all versions but the ones being released, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
* Remove from all screens the custom fields belonging to 100% unsupported branches.
For major releases only:
* Release and archive the [https://tracker.moodle.org/issues/?jql=affectedVersion%20~%20%22must%20fix%20for*%22%20OR%20fixVersion%20~%20%22must%20fix%20for*%22 "Must fix for X.Y" versions], it must be empty to do so.
| Integration Team
|-
| 10.
| style="text-align:center" | ✓
|
|
* Create the new "Pull X.Y Branch" and "Pull X.Y Diff URL" custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Re-index Tracker.
* In the CI server edit the [http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ "Bulk precheck issues"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(awaiting_integration)/ "Pre-launch DEV jobs (awaiting_integration)"], [https://ci.moodle.org/view/Tracker/job/TR%20-%20Bulk%20pre-launch%20DEV%20jobs%20(list_of_mdls)/ "Pre-launch DEV jobs (list_of_mdsl)"] and [https://ci.moodle.org/view/Tracker/job/STR%20-%20Bulk%20pre-launch%20SDEV%20jobs%20(list_of_mdls)/ "Pre-launch SDEV jobs (list_of_mdsl)"] jobs to make them meet the new "Pull X.Y Branch" field created. At the same time, remove from those jobs any branch belonging to 100% unsupported branches.
* Edit the "Tracker - CI - Check marked as integrated" job ([https://ci.moodle.org/view/Tracker/job/TR%20-%20Check%20marked%20as%20integrated/ link]) to configure the development branches (devbranches) (39, 310, 311, 400...) actually active. Normally only the branch corresponding to master, but also accepts a comma separated list when under parallel development ("310,400" or "311,400" for example). Ordered by planned release date.
* Check/configure (again, this may be has been already executed few steps above) the "05. Check version.php files" jobs both for the involved branches (XY and master) to define the interval of versions allowed in each.
| Integration Team
|-
| 11.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| In the Tracker...
For major releases only:
* Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.
* Adjust the [https://tracker.moodle.org/issues/?filter=17528 Latest regressions] filter (requires login).
For all releases:
* Verify how the "X.Y regressions" versions [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(versionMatches(%22.*regressions%22)) are going] (requires login) and ping Development Managers about. Package and archive them once empty.
| Integration Team
|-
| 12.
| style="text-align:center" | ✓
|
| Clone MDL-74509 and MDL-74510, to be resolved ASAP.
| Integration Team
|-
| 13.
| style="text-align:center" | ✓
|
|
* Create the new MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security repo (branching from the just created upstream MOODLE_XY_STABLE branch).
* Cherry pick any security commit present in the security repository's master branch to the new MOODLE_XY_STABLE branch (note that normally there should not be any, see point #1 check list above).
* Verify the new security jobs exist for the new branch and check it's working in all servers, keeping only enabled the public one.
| Integration Team
|-
| 14.
| style="text-align:center" | ✓
|
| Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 )
| Integration Team
|}
===Release day===
Usually on Monday
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| The execution of "moodle-package-extract-and-postprocess X" script may be needed if the releases '''are not going to be published on Monday''' but another weekday (X is the weekday, (1-7) starting in Monday).
By default it happens automatically around 09:00 AM Perth/Australia time (check emails then).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify release status, download pages and windows packages.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.
| Integration Team
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Notify all registered sys admins, including security notes with CVE identifiers, using the [http://lists.moodle.org/ mailing list server].
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
|
| Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]
| Head of LMS
|-
| 7.
|
| style="text-align:center" | ✓
| Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]
| Development Manager
|-
| 8.
| style="text-align:center" | ✓
|
| New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period.
| AMOS Maintainer
|-
| 9.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Verify, 24h after tagging, that https://moodle.org/dev/contributions.php has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!
| Integration Team
|-
| 10.
| style="text-align:center" | ✓
|
| For en and de Moodle Docs, update default redirects and enable email notifications.
| Moodle Docs Maintainer
|-
| 11.
| style="text-align:center" | ✓
|
| Go through all points listed under Day of release in [[New docs version process]].
| Community Manager
|-
| 12.
| style="text-align:center" | ✓
|
|
* Decide the "Full demo", "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar]. They will be -7w, -5w and -4w before release date respectively.
* Update the "Full demo", "Code freeze", "QA begins" and Release dates on the [[Roadmap]] page.
* Add events to the HQ calendar for next Major release 6-months cycle according to [[Process#Sprints|the cycle plan]]: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
* Notify the Community Manager of new dates to be added to the moodle.org calendar.
| Development Manager
|-
| 13.
| style="text-align:center" | ✓
| style="text-align:center" |
| Add calendar events in the [https://moodle.org/calendar moodle.org calendar] for coming Major and Minor releases up to the next Major release.
| Community Manager
|-
| 14.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Update release schedule image on [[Releases#Version_support|Releases page]]
| Development Manager
|-
| 15.
| style="text-align:center" | ✓
|
| Important: This must be done '''once it's already release day @ UTC''' (aka, after Australia/Perth 08:00) or the '''queues manage with hold them again''' because it's still "last week before release".
The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed '''only''' [https://tracker.moodle.org/issues/?jql=filter%3D13669%20AND%20type%20in%20(bug%2C%20task%2C%20Sub-task) from '''bug issues''' awaiting integration]; they correspond to last-week bugs that were held because of them being unrelated with the release. Now they can be processed, under on-sync rules. Standard message will be used to explain the un-hold.
| Integration Team
|}
==1 week after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).
For major releases, within the on-sync period, master packages will be generated using the prerelease.sh script (--type on-sync). That guarantees XY_STABLE and master versions are kept the same. The last week, when leaving the on-sync period, master package will be generated normally (implicit --type weekly), so versions will diverge and dev can continue separately from that point.
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Update the version.php in git to be X.Y.Z+ during the next weekly integration process
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].) Add note to top of relevant version page about security support.
| Development Manager
|-
| 4.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
|| Security Officer
|-
| 5.
| style="text-align:center" | ✓
| style="text-align:center" | ✓
| Notify about publications of CVE using form: https://cveform.mitre.org/
| Security Officer
|-
| 6.
| style="text-align:center" | ✓
|
| Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
|
|-
| 7.
| style="text-align:center" | ✓
|
| '''Deprecations:'''
* Create the next deprecation epic (for X.Y+1+2y) similar to MDL-74579 and add standard issues to it:
** Final deprecation of lib/deprecatedlib.php (like MDL-74580)
** Removal of deprecated Behat steps (like MDL-74581)
** Removal of strings (like MDL-74582) and
** Removal of renamed classes (MDL-74583).
The issue can be based/cloned on the previous one and linked ("has to be done after") with it.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous deprecation epics are going] and share about them.

'''Libraries:'''
* Create the next third party libraries epic for X.Y+1, similar to MDL-73715. The issue should refer to the list of [[Moodle libraries credits]]. The issue can be based/cloned on the previous one and linked ("has to be done after") with it. '''Drag/link opened issues from the previous one''', avoiding leaving unfinished stuff.
* Review [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20(summary%20~%20%22Review%20third%20party%20libraries%20for%20new%20versions%22%20OR%20summary%20~%20%22Review%20third-party%20libraries%20for%20upgrade%22)%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous library review epics are going] and share about them.
| Integration Team
|}
==2 weeks after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Once the "On Sync" period ends:
* Confirm that versions (XY_STABLE and master) diverged properly the last on-sync week. If not, proceed to it by manually bumping master version to currentdate @ integration.git.
* Disable the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20continuous/ Manage queues on continuous] job. It has served us well.
* The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed from all issues awaiting integration, so they will be, automatically (see next point), be moved to current integration. Send a "unholding + rebase" message to all those issues.
* Enable the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Manage%20queues%20on%20normal/ Manage queues on normal] job. It will control the queues over coming months, until next freeze.
* The discussion about environmental requirements for next X.Y+1 major release (MDL-70594) will end and the issue will be resolved '''immediately'''. A new issue, about the requirements for next-next X.Y+2 major release will be created at the same time by cloning the previous one and dragging any non-resolved detail (due date = 3w after release).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| In https://github.com/moodlehq/moodle-behat-extension project:
* For the new stable version:
*# Create a MOODLE_XY_STABLE branch from master
* For master:
*# Add a 3.X(Y+1).0 tag for the new release in the master branch (first number is the major behat release, currently 3.x).
*# Clone MDL-70192, implement, and send it to integration.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Ensure [https://download.moodle.org/langpack/X.Y+1/ Language pack for master (X.Y+1)] is available and merge the pull request MR4 for stop skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
| Integration Team
|-
| 4.
| style="text-align:center" | ✓
|
| Ensure release retrospectives are held for each of the LMS teams and results are actioned.
| Development Manager / Head of LMS
|}

==1 month after==
{| class="table table-striped table-bordered"
|-
! style="width:20px" | #
! style="width:20px" | Major
! style="width:20px" | Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Remove, in CI servers, all the jobs and views corresponding to branches which support has ended completely. (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Remove%20all%20jobs%20from%20view/ maintenance job] to perform the operation).
| Integration Team
|-
| 2.
| style="text-align:center" | ✓
|
| Upgrade all the Moodle CI sites to recent major release by configuring the "Moodle CI Auto Upgrade" job in all them.
| Integration Team
|-
| 3.
| style="text-align:center" | ✓
|
| Confirm that there isn't any remaining [https://tracker.moodle.org/issues/?filter=13669 integration_held] issue from latest release, proceeding to uhhold them immediately. Note that there may exist [https://tracker.moodle.org/issues/?filter=13669&jql=project%20%3D%20MDL%20AND%20labels%20in%20(integration_held)%20ORDER%20BY%20%22Integration%20priority%22%20DESC%2C%20priority%20DESC%2C%20votes%20DESC%2C%20%22Last%20comment%20date%22%20ASC other "held" issues], unrelated with latest release. This process step does not affect them.
| Integration Team
|}
==See also==
* [[Deprecation|Deprecation process]]
[[Category:Processes|Release process]]
[[Category:Release notes|Release process]]

Moodle 4.0 release notes

2022-04-19T03:11:28Z

Stronk7: Moodle 4.0.0 released

{{Template:Migrated|newDocId=/docs/release-notes}}
[[Releases]] > {{FULLPAGENAME}}

Release date: 19 April 2022

Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%224.0%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 4.0].

If you are upgrading from a previous version, please see [[:en:Upgrading|Upgrading]] in the user docs.
==Server requirements==
These are just the minimum supported versions. We recommend keeping all of your software and operating systems up-to-date.
* Moodle upgrade: Moodle 3.6 or later
* PHP version: minimum PHP 7.3.0 ''Note: minimum PHP version has increased since Moodle 3.10''. PHP 7.4.x is supported too. [[Moodle and PHP|PHP 8.0 support]] is being implemented (see MDL-70745) and '''not ready for production''' yet.
* PHP extension '''sodium''' is recommended. It will be required in Moodle 4.2. For further details, see [https://docs.moodle.org/311/en/Environment_-_PHP_extension_sodium Environment - PHP extension sodium].
* PHP extension '''exif''' is recommended.
* PHP setting '''max_input_vars''' is recommended to be >= 5000 for PHP 7.x installations. It's a requirement for PHP 8.x installations. For further details, see [https://docs.moodle.org/311/en/Environment_-_max_input_vars Environment - max input vars].
=== Database requirements ===
Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.
{| class="wikitable"
|-
! Database
! Minimum version
! Recommended
|-
| [http://www.postgresql.org/ PostgreSQL]
| 10 (increased since Moodle 3.11)
| Latest
|-
| [http://www.mysql.com/ MySQL]
| 5.7
| Latest
|-
| [https://mariadb.org/ MariaDB]
| 10.2.29
| Latest
|-
| [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]
| 2017 (increased since Moodle 3.10)
| Latest
|-
| [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]
| 11.2
| Latest
|}
==Client requirements==
=== Browser support ===
Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

Desktop:
* Chrome
* Firefox
* Safari
* Edge
''Note: Moodle 4.0 does NOT support Internet Explorer 11.''

Safari 7 and below has known compatibility issues with Moodle 4.0.

Mobile:
* MobileSafari
* Google Chrome
For the best experience and optimum security, we recommend that you keep your browser up to date.
==Major UX improvements==
===Navigation improvements===
* MDL-70208 - Implement frontend functionality for primary navigation
* MDL-70207 - Implement backend functionality for primary navigation
* MDL-70202 - Implement frontend functionality for secondary navigation
* MDL-70198 - Implement backend functionality for secondary navigation
* MDL-70196 - Create a module based navigation bar
* MDL-72352 - Ensure that secondary navigation is backwards compatible
* MDL-73462 - Course and category management secondary and tertiary navigation
* MDL-71977 - Define the secondary navigation nodes that should be always displayed in the more menu in the module context
* MDL-71901 - Allow plugins to define their own secondary nav ordering
* MDL-70844 - Update the secondary navigation view to send site administration information in tab form
* MDL-72396 - Allow easy setting of the active tab for navigation views
* MDL-71912 - Implement tertiary navigation for plugins (also see MDL-71913, MDL-71914 and MDL-71914)
* MDL-73863 - Tertiary navigation in course completion
* MDL-72875 - Add tertiary navigation to the participants page
* MDL-72904 - Add tertiary navigation to the badges pages
* MDL-72873 - Add tertiary navigation to the gradebook
* MDL-72094 - Update the course reports page styling and functionality
* MDL-71083 - Move the user menu in the top bar into the primary navigation menu in the mobile view
* MDL-73393 - Ensure that existing third party themes still work with latest navigation changes
* MDL-71943 - Dynamic (AJAX) tabs in Moodle LMS
* MDL-72090 - Convert course admin pages from link farms to dropdowns
* MDL-72413 - Move the activity modules title, description, and activity completion into a standard module API
* MDL-72736 - Remove section navigation on one section per page
* MDL-72834 - Move the calendar link into the user menu
* MDL-72450 - Remove the next and previous activity links from all activity modules in Boost
* MDL-71148 - Combine both the custom menu & primary navigation renderers
* MDL-71683 - Update language menu to move from the top navigation into the user menu when logged in
* MDL-72005 - Update the context_header in Boost to move the breadcrumb to the top
===Course index===
* MDL-71209 - Create the new course index list
* MDL-72660 - Add activity completion indicators to the course index
* MDL-71228 - Implement drag and drop option for sections and activities in the course index
* MDL-71211 - Keep the status of the course index collapsed and expanded sections per user and course
* MDL-71795 - Course index on activity view page
* MDL-71828 - Implement section links' behaviour in course index
* MDL-71664 - Enable drag & drop from course index to course content and vice versa
* MDL-72463 - Add 'highlighted' label to course index
* MDL-71727 - Sync course index and course content when an element is dragged
* MDL-72897 - Mark the current section in the course index
* MDL-73340 - Open course index by default first time a user access the course
* MDL-73310 - Show the course index on all pages within a course
===Course experience===
* MDL-71037 - Sections are now collapsible for Topics and Weekly course formats
* MDL-71691 - Created a new activity UI component
* MDL-71689 - Improvements to add activity and add section design
* MDL-71663 - Created a new "move" option in the sections and activity cog menu in the course editor
* MDL-71779 - Made 'Add a new topic/week' option client side on Topics and Weekly formats
* MDL-72311 - Proceed straight to course content when creating a new course
* MDL-71863 - Created core_courseformat subsystem
* MDL-72578 - Moved activity UI component to output classes and templates
* MDL-73343 - New quick access to create a new course from My courses page when there is no course available
===My Courses page and overview block===
* MDL-70801 - Implement "My courses" page
* MDL-58579 - Allow searching / filtering of courses in myoverview
* MDL-73231 - Provide option of having My courses as defaulthomepage
===Timeline block===
* MDL-72276 - Update timeline block dropdowns to display current selection
* MDL-72277 - Improve the layout and usability of the items in the timeline block
* MDL-73068 - Only display courses in the timeline block if they contain events
* MDL-72295 - Add text search to the timeline block
* MDL-72594 - Improve displaying of overdue items in the timeline block
* MDL-72603 - Replace timeline block pagination with "show more" lazy loading
* MDL-72543 - Change the display of the event names of the items on the timeline block
===Calendar usability===
* MDL-71817 - Render the calendar in the calendar block in month view
* MDL-72237 - Limit number of events shown per day in calendar month view
* MDL-71810 - Add a current date indicator and make calendar block responsive when switching between small and large views
* MDL-71808 - Move the import calendar form to its own page
* MDL-72045 - Improve help information provided on the calendar export page
* MDL-71790 - Revamp the manage subscriptions page
* MDL-71788 - Make it easier to copy the export URL
* MDL-71775 - Add footer links to the calendar block
* MDL-72810 - Remove 3-month calendar view
===Dashboard===
* MDL-72092 - Arrange blocks between My courses & My dashboard
* MDL-73114 - Display a title in the dashboard page
* MDL-71964 - Welcome message for users
* MDL-73233 - Provide option to disable the Dashboard
* MDL-72116 - Remove some of the default blocks from the Dashboard
===User tours===
* MDL-61674 - Allow user tours to be created using the Atto text editor
* MDL-72385 - Improve and simplify design of user tours
* MDL-71938 - Display number of steps in a user tour
* MDL-72783 - Add new user tours
* MDL-72781 - Remove previous user tours
* MDL-72557 - Implement customisable confirmation button for single step user tours
* MDL-71931 - Update user tours to emit events
===Other usability and user experience improvements===
* MDL-69371 - Redesign the Moodle login page (also see MDL-72928)
* MDL-71457 - Update the Moodle activity icons
* MDL-71963 - Turn confirmation page into modals
* MDL-71965 - New footer
* MDL-71456 - Create page drawers for the block and course index areas
* MDL-72095 - Set a main container width of Boost pages
* MDL-71610 - Move the turn editing on button into the navbar
* MDL-72305 - Show user initials as a placeholder for the user profile picture
* MDL-72278 - Fake blocks now in drawer are made visible on first visit
* MDL-72454 - Removal of back to top link
* MDL-72088 - Update styling across top level pages
* MDL-70888 - Update the layouts in Boost theme
* MDL-71292 - Update the page header and include course image / activity icon
* MDL-73608 - Provide a contact form which sends to the site support email and replace mailto link in footer
* MDL-73935 - Improved flexibility of site support form and consistency of site support info provided in Moodle
* MDL-61564 - Allow multiple cohort selection in cohort enrolment
* MDL-66539 - Better handling of link names and URLs with Atto
* MDL-73797 - Dialogues now have the action button on the right
* MDL-60917 - Add highest ranked results section to global search
* MDL-73917 - Notification preferences page improvements
* MDL-72500 - Easier to find a specific component in event list report
* MDL-32103 - Course completion is instant for activity based completion criteria (single user completions only)
==Other major features==
===Report builder integration (from Moodle Workplace)===
* MDL-70795 - Implement functionality for creating custom reports
* MDL-70794 - Implement functionality for creating system reports
* MDL-72588 - Implement custom report audiences
* MDL-72598 - Implement custom report schedules
* MDL-73598 - Allow Custom Reports to be disabled by site admin
* MDL-72280 - Create "Courses" custom report source
* MDL-73069 - Report condition to limit returned data to current user
* MDL-73180 - Improve definitions of previous/next relative date filters
* MDL-72662 - Implement relative date options in the Reportbuilder date filter
* MDL-72172 - Create "Cohort members" custom report source
* MDL-72962 - Format editable report elements (column, filters, etc)
* MDL-72826 - Custom report option to display unique row values
* MDL-71153 - Convert task logs report to a system report
* MDL-71070 - Convert configuration changes report to a system report
===BigBlueButton integration===
* MDL-70658 - Integrate the BigBlueButton plugin into Moodle LMS
===Quiz and Questions===
* MDL-71516 - Create new plugin type - Qbank (for the full list of qbank plugins added to core, see MDL-70329)
* MDL-71679 - Update mod_quiz for new question bank
* MDL-71636 - Add a columnsortorder settings page
* MDL-71696 - Add question versions
* MDL-72076 - Question bank bulk action UI
* MDL-72553 - Add custom fields to questions
* MDL-52206 - Move "Require passing grade" completion option to core
* MDL-52456 - Add notification message for students after questions have been manually graded
* MDL-71984 - Add logging to quiz auto-save, process_attempt and redo_question
* MDL-73337 - Log editing quizzes in detail
* MDL-73699 - Question status UI/UX update
* MDL-72448 - Add qbank_history to core
* MDL-71614 - Add qbank_previewquestion to core
===Update LTI tool provider feature to support 1.3===
* MDL-69543 - Update tool to support 1.3 OAuth2/OIDC launch flow
* MDL-71371 - Provide upgrade path for 1.1 preconfigured tools
* MDL-72745 - Provide account provisioning options for LTI Advantage launches
* MDL-69547 - Update tool enrolment code so that a user is automatically created and enrolled when launching via 1.3
* MDL-69545 - Update user sync task to support 1.3 messages
* MDL-69544 - Update grade sync task to support 1.3 messages
* MDL-72288 - Update library and model code to support issuer and clientid uniqueness on registrations
* MDL-69862 - Add dynamic registration support to the tool
* MDL-70354 - Return line item information during content selection
===Assignment===
* MDL-68913 - Per attempt timing now available in assignments
===Admin configuration presets===
* MDL-72112 - Integrate admin_presets third-party plugin in Moodle LMS
* MDL-73145 - Add a $CFG setting to define the preset to be installed
* MDL-72114 - Include pre-installed admin presets
* MDL-72113 - Add feature to import/export plugins visibility from Admin presets tool
* MDL-73394 - Store the latest site admin preset applied
===Content bank and H5P===
* MDL-68394 - Integrate mod_h5pactivity with recent activity plugins
* MDL-72099 - Add navigation by contexts in the content bank
* MDL-71885 - Inline editing H5P content for mod_h5pactivity
* MDL-71956 - Inline editing H5P content anywhere
===Badges===
* MDL-72141 - Simplifying the external badge page
===Accessibility improvements===
* MDL-67853 - Remove online-offline options on notifications
* MDL-72078 - Give users an indication that they encountered an editor
* MDL-71604 - Move the screen reader helper button to the first row
* MDL-72896 - Make html_tables responsive by default
==Other Highlights==
===Functional changes===
* MDL-70456 - Add custom user field support to all places that display user identity [0,Minor] Improvement
* MDL-73342 - Disable some blocks by default (such as feedback, RSS and self-completion)
* MDL-70905 - Updated media default width/height to use 16:9
* MDL-72118 - Rename "HTML block" to the more easily understood "Text block"
* MDL-72706 - Change default value of "Hidden sections" course format setting
* MDL-72115 - Rename "Miscellaneous" category to "Category 1"
* MDL-72119 - Make “Enable xxxxx” features consistent (hide menus for disabled features)
===For administrators===
* MDL-71347 - Add a filter to "browse list of users" for date of user account creation
* MDL-72031 - Separate out max_time for audio and video files in Atto/RecordRTC
* MDL-71515 - Improve the test outgoing mail configuration admin page
* MDL-67686 - Add more filters to task log (/admin/tasklogs.php)
* MDL-72984 - Ensure support email address is mandatory
* MDL-73592 - MoodleNet integration now enabled by default
* MDL-71621 - Parent role cannot edit custom fields in child profile
* MDL-73918 - Allow admins to change the page width using custom SCSS
* MDL-71927 - Logs and question attempt history now show time to the second, to help investigate issues
* MDL-71466 - Custom user field support: Admin role screens (check permissions, assign)
* MDL-72619 - Provide admin page to view cache size estimates
* MDL-67822 - New check_database_schema performance check
* MDL-70271 - Dropbox token and Permission Updates
* MDL-58395 - LDAP auth sync now skip and report problematic user accounts
* MDL-72251 - Tasks admin UI now shows time to nearest second
===Mobile===
* MDL-67807 - Return concurrent sessions information to apply concurrent login limit in the mobile app
* MDL-69555 - Make duration of QR login and auto-login time between requests configurable
* MDL-73794 - Update the footer in the mobile view
===Performance===
* MDL-72596 - Caching: Track cache I/O size in perfdebug
* MDL-69088 - Make file cache store purges instant with a safe and async purge
* MDL-68164 - Additional caching of pg_field_type postgres field metadata
* MDL-63983 - Improve the performance of non-contact searches in messaging when site-wide messaging is disabled (default)
* MDL-71014 - Cache the siteidentifier and site contextid in local cache
* MDL-72328 - Add TTL support for Redis caches
* MDL-72837 - Cache API should support versioned data
==Security improvements==
* MDL-56873 - Set more secure defaults for the cURL allow/deny lists
* MDL-66776 - Send notifications when new devices are used to log in into the site
* MDL-71627 - Add check API for anti virus and optionally remove admin notifications
* MDL-71806 - Improved the UX of the Moodle security report
* MDL-71176 - New password and change forms should have autocomplete="new-password"
==For developers==
* MDL-61460 - Introduce the UI components library
* MDL-74229 - Add navigation node keys to allow themers to hide navigation tabs
* MDL-74235 - Rename the icons for activities to allow support of multiple icons for multiple versions
* MDL-74033 - Allow full customisation of the primary navigation
* MDL-72779 - Set more than one value on a persistent at the same time
* MDL-70862 - Implement a new callback to extend gradebook plugininfo
* MDL-72289 - Allow callers to customise the rendered icon of inplace editable elements
* MDL-73347 - Allow themes to define un-addable blocks
* MDL-46778 - Allow use a separate DB configuration (not just prefix) for Behat similar to PHPUnit
* MDL-73270 - Warn where XMLRPC is currently in use
* MDL-67228 - Tool_replace maturity set
===Web service additions and updates===
* MDL-71135 - Create core_course_get_state web service
* MDL-71165 - Create core_course_update_course web service
===Core plugins removed===
* MDL-71473 - Jabber removed as a standard notification plugin
* MDL-58939 - Picasa repository and portfolio removed from core
* MDL-72335 - Tool_health removed from core
* MDL-72615 - Boxnet plugins removed from core
* MDL-72616 - Quiz results block removed from core
* MDL-72348 - Microsoft OneDrive (legacy) repository (repository_skydrive) removed from core
* MDL-72347 - Word censorship filter (filter_censor) removed from core
* MDL-72407 - VideoJS Flash plugin removed from core
* MDL-72042 - Flash animation media player removed from core
* MDL-72041 - WebCT question import format removed from core
* MDL-72517 - Examview question import format removed from core
===Deprecations===
* MDL-53544 - Typo3 library removed
* MDL-72004 - Quiz 4.0 Class renaming and deprecation
* MDL-73756 - Deprecate $modinfo param to completion_info::get_data()
* MDL-65799 - Phase 2 of deprecation of functions in lib/deprecatedlib.php initially deprecated in 3.8
* MDL-71175 - Deprecate some plagiarism functions that are not used, or have replacements
* MDL-66266 - Remove deprecated functions in messages/classes/api.php
* MDL-72098 - deprecate grade_grade::insert method that just calls its parent
* MDL-72433 - Final deprecation of get_grades() in lib/classes/grades_external.php
* MDL-71476 - Remove mysql_engine.php
* MDL-65252 - Final deprecations of forum_count_replies and get_forum_discussion_posts
* MDL-67412 - Remove deprecated functions in lib/setuplib.php
* MDL-65801 - Remove strings deprecated in 3.8
===Component API updates===
* admin/tool/generator/upgrade.txt
* admin/tool/log/upgrade.txt
* admin/tool/mobile/upgrade.txt
* admin/tool/upgrade.txt
* admin/tool/usertours/upgrade.txt
* admin/upgrade.txt
* analytics/upgrade.txt
* auth/shibboleth/upgrade.txt
* availability/upgrade.txt
* backup/upgrade.txt
* badges/upgrade.txt
* blocks/section_links/upgrade.txt
* blocks/tag_youtube/upgrade.txt
* blocks/timeline/upgrade.txt
* blocks/upgrade.txt
* cache/upgrade.txt
* calendar/upgrade.txt
* completion/upgrade.txt
* contentbank/upgrade.txt
* course/format/upgrade.txt
* course/upgrade.txt
* customfield/upgrade.txt
* dataformat/upgrade.txt
* enrol/database/upgrade.txt
* enrol/upgrade.txt
* filter/upgrade.txt
* grade/grading/form/upgrade.txt
* grade/upgrade.txt
* group/upgrade.txt
* h5p/upgrade.txt
* lib/upgrade.txt
* media/upgrade.txt
* message/upgrade.txt
* mod/assign/upgrade.txt
* mod/book/upgrade.txt
* mod/feedback/upgrade.txt
* mod/forum/upgrade.txt
* mod/glossary/upgrade.txt
* mod/h5pactivity/upgrade.txt
* mod/lesson/upgrade.txt
* mod/lti/upgrade.txt
* mod/page/upgrade.txt
* mod/quiz/upgrade.txt
* mod/resource/upgrade.txt
* mod/scorm/upgrade.txt
* mod/upgrade.txt
* mod/url/upgrade.txt
* mod/wiki/upgrade.txt
* mod/workshop/upgrade.txt
* my/upgrade.txt
* payment/upgrade.txt
* plagiarism/upgrade.txt
* portfolio/upgrade.txt
* question/bank/upgrade.txt
* question/behaviour/upgrade.txt
* question/engine/upgrade.txt
* question/format/upgrade.txt
* question/type/multichoice/upgrade.txt
* question/type/upgrade.txt
* question/upgrade.txt
* report/eventlist/upgrade.txt
* report/upgrade.txt
* repository/upgrade.txt
* search/upgrade.txt
* theme/upgrade.txt
* user/upgrade.txt
* webservice/upgrade.txt

==See also==
*[[Moodle 3.11 release notes]]

[[Category:Release notes]]
[[Category:Moodle 4.0]]

[[fr:Notes de version de Moodle 4.0]]
[[es:Notas de Moodle 4.0]]

Releases

2022-04-19T03:05:10Z

Stronk7: (amend dates to planned release dates)

This page lists all official releases of Moodle, grouped by branch in reverse chronological order.
==Version support==
From Moodle 2.6 onwards, the end of support, both general and security, happens the second Monday of May and November, observing the 12, 18... month periods, no matter if the major release date was moved or not.

The most recent [https://en.wikipedia.org/wiki/Long-term_support long-term support release (LTS)] version is Moodle 3.9.
{| class="wikitable" border="1px solid #dee2e6;"
|-
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Version
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Release status
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Initial release
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:rgba(0, 0, 0, 0.05);" | General support ends
! style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" | Security support ends
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 3.9 (LTS)
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#239cae; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 15 June 2020
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 10 May 2021
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 13 November 2023 (ext 6M)
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 3.10
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#239cae; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 9 November 2020
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 8 November 2021
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 9 May 2022
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 3.11
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#f98012; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current stable
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 17 May 2021
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 14 Nov 2022 (ext 6M)
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | 13 Nov 2023 (ext 12M)
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |4.0
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#f98012; padding: .3rem 0.5rem 0.3rem 0.5rem;" | Current stable
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |19 April 2022
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |8 May 2023
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |13 November 2023
|-
|4.1 (LTS)
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#9cbd50; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Future stable
|November 2022
|November 2023
|November 2025
|}
[[Image:releasescurrent.png|alt=Release graph]]

<b>Release graph key:</b>
{| class="wikitable" border="1px solid #dee2e6;"
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#f98012; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Current stables
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" |Currently supported stable releases.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#239cae; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Current security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" | Current release of versions still receiving security-only updates.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#9cbd50; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Future stables
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" |Future point releases receiving bug fixes, as well as security updates.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#316d5e; color:white; adding: .3rem 0.5rem 0.3rem 0.5rem;" |Future security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |Future point releases receiving security-only updates.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#686566; color:white; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Past stables
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: rgba(0, 0, 0, 0.05);" |Previously released versions containing bug fixes, as well as security updates. Updating to a currently supported version is recommended.
|-
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color:#282828; color:white; padding: .3rem 0.5rem 0.3rem 0.5rem;" |Past security
| style="vertical-align: top; border-top: 1px solid #dee2e6; background-color: #FFFFFF" |Previously released versions containing security updates only. Updating to a currently supported version is recommended.
|}
==General release calendar==
These are the target dates for releases. These dates may vary slightly due to unforeseen circumstances.
{| class="wikitable"
|-
!Release type
!Frequency
!Months
|-
|[[Process#Major_release_cycles|Major]] (eg. 3.x)
|6 monthly
|Second Monday of May and November
|-
|[[Process#Stable_maintenance_cycles|Minor]] (Point) (eg. 3.x.y)
| 2 monthly
|Second Monday of July, September, November, March and May.
Third Monday of January.
|}
All releases are preceded by a one week warning. Upcoming release dates can be found in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar] (Note, this is an iCAL link that will try to add the dates to your personal calendar. If you just want to browse the dates online, use [https://calendar.google.com/calendar/embed?src=moodle.com_p4c2oe7hsb77ltaro5qtihb5d4@group.calendar.google.com&pli=1 this link].).

==Moodle 4.0==
{| class="wikitable"
|-
!Moodle 4.0
|19 April 2022
|2022041900
|[[Moodle 4.0 release notes|Release Notes]]
|[https://docs.moodle.org/400/en/Upgrading Upgrading to 4.0]
|}
Bug fixes for general core bugs in 4.0.x will end 8 May 2023 (12 months).
Bug fixes for security issues in 4.0.x will end 13 November 2023 (18 months).

==Moodle 3.11==
{| class="wikitable"
|-
!Moodle 3.11
|17 May 2021
|2021051700
|[[Moodle 3.11 release notes|Release Notes]]
|[https://docs.moodle.org/311/en/Upgrading Upgrading to 3.11]
|-
!Moodle 3.11.1
|12 July 2021
|2021051701
|[[Moodle 3.11.1 release notes|Release Notes]]
|
|-
!Moodle 3.11.2
|29 July 2021
|2021051702
|[[Moodle 3.11.2 release notes|Release Notes]]
|Emergency minor release
|-
! Moodle 3.11.3
|13 September 2021
|2021051703
|[[Moodle 3.11.3 release notes|Release Notes]]
|
|-
! Moodle 3.11.4
|8 November 2021
|2021051704
|[[Moodle 3.11.4 release notes|Release Notes]]
|
|-
! Moodle 3.11.5
|17 January 2022
|2021051705
|[[Moodle 3.11.5 release notes|Release Notes]]
|-
! Moodle 3.11.6
|14 March 2022
|2021051706
|[[Moodle 3.11.6 release notes|Release Notes]]
|}
Bug fixes for general core bugs in 3.11.x will end 14 Nov 2022 (12 months plus 6 months extension).
Bug fixes for security issues in 3.11.x will end 13 Nov 2023 (18 months plus 12 months extension).
==Moodle 3.10==
{| class="wikitable"
|-
! Moodle 3.10
|9 November 2020
|2020110900
|
[[Moodle 3.10 release notes|Release Notes]]
|[https://docs.moodle.org/310/en/Upgrading Upgrading to 3.10]
|-
!Moodle 3.10.1
|18 January 2021
|2020110901
| [[Moodle 3.10.1 release notes|Release Notes]]
|
|-
!Moodle 3.10.2
|8 March 2021
|2020110902
|[[Moodle 3.10.2 release notes|Release Notes]]
|
|-
! Moodle 3.10.3
|25 March 2021
|2020110903
|[[Moodle 3.10.3 release notes|Release Notes]]
|
|-
!Moodle 3.10.4
|10 May 2021
|2020110904
|[[Moodle 3.10.4 release notes|Release Notes]]
|
|-
!Moodle 3.10.5
|12 July 2021
|2020110905
|[[Moodle 3.10.5 release notes|Release Notes]]
|
|-
!Moodle 3.10.6
|29 July 2021
|2020110906
|[[Moodle 3.10.6 release notes|Release Notes]]
|Emergency minor release
|-
! Moodle 3.10.7
|13 September 2021
|2020110907
|[[Moodle 3.10.7 release notes|Release Notes]]
|
|-
!Moodle 3.10.8
|8 November 2021
|2020110908
|[[Moodle 3.10.8 release notes|Release Notes]]
|
|-
!Moodle 3.10.9
|17 January 2022
|2020110909
|[[Moodle 3.10.9 release notes|Release Notes]]
|-
!Moodle 3.10.10
|14 March 2022
|2020110910
|[[Moodle 3.10.10 release notes|Release Notes]]
|}
Bug fixes for general core bugs in 3.10.x ended 8 November 2021 (12 months).
Bug fixes for security issues in 3.10.x will end 9 May 2022 (18 months).
==Moodle 3.9 (LTS)==
{| class="wikitable"
|-
! Moodle 3.9
|15 June 2020
|2020061500
|[[Moodle 3.9 release notes|Release Notes]]
|
[https://docs.moodle.org/39/en/Upgrading Upgrading to 3.9]
|-
!Moodle 3.9.1
|13 July 2020
|2020061501
|[[Moodle 3.9.1 release notes|Release Notes]]
|
|-
!Moodle 3.9.2
|14 September 2020
|2020061502
| [[Moodle 3.9.2 release notes|Release Notes]]
|
|-
!Moodle 3.9.3
|9 November 2020
|2020061503
| [[Moodle 3.9.3 release notes|Release Notes]]
|
|-
!Moodle 3.9.4
|18 January 2021
|2020061504
|[[Moodle 3.9.4 release notes|Release Notes]]
|
|-
!Moodle 3.9.5
|8 March 2021
|2020061505
|[[Moodle 3.9.5 release notes|Release Notes]]
|
|-
!Moodle 3.9.6
|25 March 2021
|2020061506
|[[Moodle 3.9.6 release notes|Release Notes]]
|
|-
!Moodle 3.9.7
|10 May 2021
|2020061507
|[[Moodle 3.9.7 release notes|Release Notes]]
|
|-
! Moodle 3.9.8
|12 July 2021
|2020061508
|[[Moodle 3.9.8 release notes|Release Notes]]
|
|-
!Moodle 3.9.9
|29 July 2021
|2020061509
|[[Moodle 3.9.9 release notes|Release Notes]]
|Emergency minor release
|-
! Moodle 3.9.10
|13 September 2021
|2020061510
|[[Moodle 3.9.10 release notes|Release Notes]]
|
|-
!Moodle 3.9.11
| 8 November 2021
|2020061511
|[[Moodle 3.9.11 release notes|Release Notes]]
|
|-
!Moodle 3.9.12
| 17 January 2022
|2020061512
|[[Moodle 3.9.12 release notes|Release Notes]]
|-
!Moodle 3.9.13
| 14 March 2022
|2020061513
|[[Moodle 3.9.13 release notes|Release Notes]]
|
|}
Bug fixes for general core bugs in 3.9.x ended 10 May 2021 (12 months).
Bug fixes for security issues in 3.9.x will end 13 Nov 2023 (36 months plus 6 months extension).
==Moodle 3.8==
{| class="wikitable"
|-
!Moodle 3.8
|18 November 2019
|2019111800
|[[Moodle 3.8 release notes|Release Notes]]
|
[https://docs.moodle.org/38/en/Upgrading Upgrading to 3.8]
|-
!Moodle 3.8.1
|13 January 2020
|2019111801
|[[Moodle 3.8.1 release notes|Release Notes]]
|
|-
!Moodle 3.8.2
|9 March 2020
|2019111802
|[[Moodle 3.8.2 release notes|Release Notes]]
|
|-
!Moodle 3.8.3
|11 May 2020
|2019111803
|[[Moodle 3.8.3 release notes|Release Notes]]
|
|-
!Moodle 3.8.4
|13 July 2020
|2019111804
|[[Moodle 3.8.4 release notes|Release Notes]]
|
|-
!Moodle 3.8.5
|14 September 2020
|2019111805
| [[Moodle 3.8.5 release notes|Release Notes]]
|
|-
!Moodle 3.8.6
|9 November 2020
|2019111806
| [[Moodle 3.8.6 release notes|Release Notes]]
|
|-
!Moodle 3.8.7
|18 January 2021
|2019111807
|[[Moodle 3.8.7 release notes|Release Notes]]
|
|-
!Moodle 3.8.8
|8 March 2021
|2019111808
|[[Moodle 3.8.8 release notes|Release Notes]]
|
|-
!Moodle 3.8.9
|10 May 2021
|2019111809
|[[Moodle 3.8.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.8.x ended 9 November 2020 (12 months).
Bug fixes for security issues in 3.8.x ended 10 May 2021 (18 months).
==Moodle 3.7==
{| class="wikitable"
|-
!Moodle 3.7
|20 May 2019
|2019052000
|[[Moodle 3.7 release notes|Release Notes]]
|[https://docs.moodle.org/37/en/Upgrading Upgrading to 3.7]
|-
!Moodle 3.7.1
|8 July 2019
|2019052001
|[[Moodle 3.7.1 release notes|Release Notes]]
|
|-
!Moodle 3.7.2
|9 September 2019
|2019052002
|[[Moodle 3.7.2 release notes|Release Notes]]
|
|-
!Moodle 3.7.3
|11 November 2019
|2019052003
| [[Moodle 3.7.3 release notes|Release Notes]]
|
|-
!Moodle 3.7.4
|13 January 2020
|2019052004
|[[Moodle 3.7.4 release notes|Release Notes]]
|
|-
!Moodle 3.7.5
|9 March 2020
|2019052005
|[[Moodle 3.7.5 release notes|Release Notes]]
|
|-
!Moodle 3.7.6
|11 May 2020
|2019052006
|[[Moodle 3.7.6 release notes|Release Notes]]
|
|-
!Moodle 3.7.7
|13 July 2020
|2019052007
|[[Moodle 3.7.7 release notes|Release Notes]]
|
|-
!Moodle 3.7.8
|14 September 2020
|2019052008
| [[Moodle 3.7.8 release notes|Release Notes]]
|
|-
!Moodle 3.7.9
|9 November 2020
|2019052009
|[[Moodle 3.7.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.7.x ended 11 May 2020 (12 months).
Bug fixes for security issues in 3.7.x ended 9 November 2020 (18 months).
==Moodle 3.6==
{| class="wikitable"
|-
!Moodle 3.6
| 3 December 2018
|2018120300
|[[Moodle 3.6 release notes|Release Notes]]
|
[https://docs.moodle.org/36/en/Upgrading Upgrading to 3.6]
|-
!Moodle 3.6.1
|5 December 2018
|2018120301
| [[Moodle 3.6.1 release notes|Release Notes]]
|
|-
! Moodle 3.6.2
|14 January 2019
|2018120302
|[[Moodle 3.6.2 release notes|Release Notes]]
|
|-
!Moodle 3.6.3
|11 March 2019
|2018120303
|[[Moodle 3.6.3 release notes|Release Notes]]
|
|-
!Moodle 3.6.4
|13 May 2019
|2018120304
|[[Moodle 3.6.4 release notes|Release Notes]]
|
|-
!Moodle 3.6.5
|8th July 2019
|2018120305
|[[Moodle 3.6.5 release notes|Release Notes]]
|
|-
!Moodle 3.6.6
|9th September 2019
|2018120306
|[[Moodle 3.6.6 release notes|Release Notes]]
|
|-
!Moodle 3.6.7
| 11th November 2019
|2018120307
|[[Moodle 3.6.7 release notes|Release Notes]]
|
|-
!Moodle 3.6.8
|13th January 2020
|2018120308
|[[Moodle 3.6.8 release notes|Release Notes]]
|
|-
!Moodle 3.6.9
|9th March 2020
|2018120309
| [[Moodle 3.6.9 release notes|Release Notes]]
|
|-
!Moodle 3.6.10
|11th May 2020
|2018120310
|[[Moodle 3.6.10 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.6.x ended 11 November 2019 (12 months).
Bug fixes for security issues in 3.6.x ended 11 May 2020 (18 months).
==Moodle 3.5 (LTS)==
{| class="wikitable"
|-
!Moodle 3.5
|17 May 2018
|2018051700
|[[Moodle 3.5 release notes|Release Notes]]
|[https://docs.moodle.org/35/en/Upgrading Upgrading to 3.5]
|-
! Moodle 3.5.1
|9 July 2018
|2018051701
|[[Moodle 3.5.1 release notes|Release Notes]]
|
|-
!Moodle 3.5.2
|10 September 2018
|2018051702
|[[Moodle 3.5.2 release notes|Release Notes]]
|
|-
!Moodle 3.5.3
|12 November 2018
|2018051703
| [[Moodle 3.5.3 release notes|Release Notes]]
|
|-
! Moodle 3.5.4
|14 January 2019
|2018051704
|[[Moodle 3.5.4 release notes|Release Notes]]
|
|-
!Moodle 3.5.5
|11 March 2019
|2018051705
|[[Moodle 3.5.5 release notes|Release Notes]]
|
|-
!Moodle 3.5.6
|13 May 2019
|2018051706
|[[Moodle 3.5.6 release notes|Release Notes]]
|
|-
!Moodle 3.5.7
|8 July 2019
|2018051707
|[[Moodle 3.5.7 release notes|Release Notes]]
|
|-
!Moodle 3.5.8
|9 September 2019
|2018051708
|[[Moodle 3.5.8 release notes|Release Notes]]
|
|-
!Moodle 3.5.9
|11 November 2019
|2018051709
|[[Moodle 3.5.9 release notes|Release Notes]]
|
|-
!Moodle 3.5.10
|13 January 2020
|2018051710
| [[Moodle 3.5.10 release notes|Release Notes]]
|
|-
!Moodle 3.5.11
|9 March 2020
|2018051711
|[[Moodle 3.5.11 release notes|Release Notes]]
|
|-
!Moodle 3.5.12
|11 May 2020
|2018051712
| [[Moodle 3.5.12 release notes|Release Notes]]
|
|-
!Moodle 3.5.13
|13 July 2020
|2018051713
|[[Moodle 3.5.13 release notes|Release Notes]]
|
|-
!Moodle 3.5.14
| 14 September 2020
|2018051714
|[[Moodle 3.5.14 release notes|Release Notes]]
|
|-
!Moodle 3.5.15
|9 November 2020
|2018051715
|[[Moodle 3.5.15 release notes|Release Notes]]
|
|-
!Moodle 3.5.16
|18 January 2021
|2018051716
| [[Moodle 3.5.16 release notes|Release Notes]]
|
|-
!Moodle 3.5.17
|8 March 2021
| 2018051717
|[[Moodle 3.5.17 release notes|Release Notes]]
|
|-
!Moodle 3.5.18
| 10 May 2021
| 2018051718
|[[Moodle 3.5.18 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.5.x ended May 2019 (12 months).
Bug fixes for security issues in 3.5.x ended 10 May 2021 (36 months).
==Moodle 3.4==
{| class="wikitable"
|-
!Moodle 3.4
|13 November 2017
|2017111300
|[[Moodle 3.4 release notes|Release Notes]]
|
[https://docs.moodle.org/34/en/Upgrading Upgrading to 3.4]
|-
! Moodle 3.4.1
|15 January 2018
|2017111301
|[[Moodle 3.4.1 release notes|Release Notes]]
|
|-
!Moodle 3.4.2
|19 March 2018
|2017111302
|[[Moodle 3.4.2 release notes|Release Notes]]
|
|-
!Moodle 3.4.3
|17 May 2018
|2017111303
|[[Moodle 3.4.3 release notes|Release Notes]]
|
|-
! Moodle 3.4.4
|9 July 2018
|2017111304
|[[Moodle 3.4.4 release notes|Release Notes]]
|
|-
!Moodle 3.4.5
|10 September 2018
|2017111305
|[[Moodle 3.4.5 release notes|Release Notes]]
|
|-
!Moodle 3.4.6
|12 November 2018
|2017111306
| [[Moodle 3.4.6 release notes|Release Notes]]
|
|-
! Moodle 3.4.7
|14 January 2019
|2017111307
|[[Moodle 3.4.7 release notes|Release Notes]]
|
|-
!Moodle 3.4.8
|11 March 2019
|2017111308
|[[Moodle 3.4.8 release notes|Release Notes]]
|
|-
!Moodle 3.4.9
|13 May 2019
|2017111309
| [[Moodle 3.4.9 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.4.x ended 12 November 2018 (12 months).
Bug fixes for security issues in 3.4.x ended 13 May 2019 (18 months).
==Moodle 3.3==
{| class="wikitable"
|-
!Moodle 3.3
|15 May 2017
|2017051500
|[[Moodle 3.3 release notes|Release Notes]]
|
[https://docs.moodle.org/33/en/Upgrading Upgrading to 3.3]
|-
!Moodle 3.3.1
|10 July 2017
|2017051501
|[[Moodle 3.3.1 release notes|Release Notes]]
|
|-
!Moodle 3.3.2
|11 September 2017
|2017051502
|[[Moodle 3.3.2 release notes|Release Notes]]
|
|-
!Moodle 3.3.3
|13 November 2017
|2017051503
| [[Moodle 3.3.3 release notes|Release Notes]]
|
|-
! Moodle 3.3.4
|15 January 2018
|2017051504
|[[Moodle 3.3.4 release notes|Release Notes]]
|
|-
!Moodle 3.3.5
|19 March 2018
|2017051505
|[[Moodle 3.3.5 release notes|Release Notes]]
|
|-
!Moodle 3.3.6
|17 May 2018
|2017051506
|[[Moodle 3.3.6 release notes|Release Notes]]
|
|-
! Moodle 3.3.7
|9 July 2018
|2017051507
|[[Moodle 3.3.7 release notes|Release Notes]]
|
|-
!Moodle 3.3.8
|10 September 2018
|2017051508
|[[Moodle 3.3.8 release notes|Release Notes]]
|
|-
! Moodle 3.3.9
|12 November 2018
|2017051509
|[[Moodle 3.3.9 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.3.x ended 17 May 2018 (12 months).
Bug fixes for security issues in 3.3.x ended 12 November 2018 (18 months).
==Moodle 3.2==
{| class="wikitable"
|-
!Moodle 3.2
| 5 December 2016
|2016120500
|[[Moodle 3.2 release notes|Release Notes]]
|[https://docs.moodle.org/32/en/Upgrading Upgrading to 3.2]
|-
!Moodle 3.2.1
|9 January 2017
|2016120501
|[[Moodle 3.2.1 release notes|Release Notes]]
|
|-
!Moodle 3.2.2
|13 March 2017
|2016120502
|[[Moodle 3.2.2 release notes|Release Notes]]
|
|-
!Moodle 3.2.3
|8 May 2017
|2016120503
|[[Moodle 3.2.3 release notes|Release Notes]]
|
|-
!Moodle 3.2.4
|10 July 2017
|2016120504
|[[Moodle 3.2.4 release notes|Release Notes]]
|
|-
!Moodle 3.2.5
|11 September 2017
|2016120505
|[[Moodle 3.2.5 release notes|Release Notes]]
|
|-
!Moodle 3.2.6
|13 November 2017
|2016120506
| [[Moodle 3.2.6 release notes|Release Notes]]
|
|-
! Moodle 3.2.7
|15 January 2018
|2016120507
|[[Moodle 3.2.7 release notes|Release Notes]]
|
|-
!Moodle 3.2.8
|19 March 2018
|2016120508
|[[Moodle 3.2.8 release notes|Release Notes]]
|
|-
!Moodle 3.2.9
|17 May 2018
|2016120509
| [[Moodle 3.2.9 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 3.2.x ended 13 November 2017 (12 months).
Bug fixes for security issues in 3.2.x ended 17 May 2018 (18 months).
==Moodle 3.1 (LTS)==
{| class="wikitable"
|-
!Moodle 3.1
|23 May 2016
|2016052300
|[[Moodle 3.1 release notes|Release Notes]]
|
[https://docs.moodle.org/31/en/Upgrading Upgrading to 3.1]
|-
!Moodle 3.1.1
|11 July 2016
|2016052301
|[[Moodle 3.1.1 release notes|Release Notes]]
|
|-
!Moodle 3.1.2
|12 September 2016
|2016052302
|[[Moodle 3.1.2 release notes|Release Notes]]
|
|-
!Moodle 3.1.3
|14 November 2016
|2016052303
|[[Moodle 3.1.3 release notes|Release Notes]]
|
|-
!Moodle 3.1.4
|9 January 2017
|2016052304
|[[Moodle 3.1.4 release notes|Release Notes]]
|
|-
!Moodle 3.1.5
|13 March 2017
|2016052305
|[[Moodle 3.1.5 release notes|Release Notes]]
|
|-
!Moodle 3.1.6
|8 May 2017
|2016052306
|[[Moodle 3.1.6 release notes|Release Notes]]
|
|-
!Moodle 3.1.7
|10 July 2017
|2016052307
|[[Moodle 3.1.7 release notes|Release Notes]]
|
|-
!Moodle 3.1.8
|11 September 2017
|2016052308
|[[Moodle 3.1.8 release notes|Release Notes]]
|
|-
!Moodle 3.1.9
|13 November 2017
|2016052309
|[[Moodle 3.1.9 release notes|Release Notes]]
|
|-
!Moodle 3.1.10
|15 January 2018
|2016052310
|[[Moodle 3.1.10 release notes|Release Notes]]
|
|-
! Moodle 3.1.11
|19 March 2018
|2016052311
|[[Moodle 3.1.11 release notes|Release Notes]]
|
|-
!Moodle 3.1.12
|17 May 2018
|2016052312
|[[Moodle 3.1.12 release notes|Release Notes]]
|
|-
!Moodle 3.1.13
|9 July 2018
|2016052313
|[[Moodle 3.1.13 release notes|Release Notes]]
|
|-
!Moodle 3.1.14
|10 September 2018
|2016052314
|[[Moodle 3.1.14 release notes|Release Notes]]
|
|-
! Moodle 3.1.15
|12 November 2018
|2016052315
|[[Moodle 3.1.15 release notes|Release Notes]]
|
|-
!Moodle 3.1.16
|14 January 2019
|2016052316
|[[Moodle 3.1.16 release notes|Release Notes]]
|
|-
! Moodle 3.1.17
|11 March 2019
| 2016052317
|[[Moodle 3.1.17 release notes|Release Notes]]
|
|-
!Moodle 3.1.18
|13 May 2019
|2016052318
|[[Moodle 3.1.18 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.1.x ended 8 May 2017 (12 months).
Bug fixes for security issues in 3.1.x ended 13 May 2019 (36 months).
==Moodle 3.0==
{| class="wikitable"
|-
!Moodle 3.0
|16 November 2015
|2015111600
|[[Moodle 3.0 release notes|Release Notes]]
|[https://docs.moodle.org/30/en/Upgrading Upgrading to 3.0]
|-
!Moodle 3.0.1
|21 December 2015
|2015111601
| [[Moodle 3.0.1 release notes|Release Notes]]
|
|-
! Moodle 3.0.2
|11 January 2016
|2015111602
|[[Moodle 3.0.2 release notes|Release Notes]]
|
|-
!Moodle 3.0.3
|14 March 2016
|2015111603
|[[Moodle 3.0.3 release notes|Release Notes]]
|
|-
!Moodle 3.0.4
|9 May 2016
|2015111604
|[[Moodle 3.0.4 release notes|Release Notes]]
|
|-
!Moodle 3.0.5
|11 July 2016
|2015111605
|[[Moodle 3.0.5 release notes|Release Notes]]
|
|-
!Moodle 3.0.6
|12 September 2016
|2015111606
|[[Moodle 3.0.6 release notes|Release Notes]]
|
|-
!Moodle 3.0.7
|14 November 2016
|2015111607
|[[Moodle 3.0.7 release notes|Release Notes]]
|
|-
!Moodle 3.0.8
|9 January 2017
|2015111608
|[[Moodle 3.0.8 release notes|Release Notes]]
|
|-
!Moodle 3.0.9
|13 March 2017
|2015111609
|[[Moodle 3.0.9 release notes|Release Notes]]
|
|-
!Moodle 3.0.10
|8 May 2017
|2015111610
|[[Moodle 3.0.10 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 3.0.x ended 14 November 2016 (12 months).
Bug fixes for security issues in 3.0.x ended 8 May 2017 (18 months).
==Moodle 2.9==
{| class="wikitable"
|-
!Moodle 2.9
| 11 May 2015
|2015051100
|[[Moodle 2.9 release notes|Release Notes]]
| [https://docs.moodle.org/29/en/Upgrading_to_Moodle_2.9 Upgrading to 2.9]
|-
! Moodle 2.9.1
|6 July 2015
|2015051101
|[[Moodle 2.9.1 release notes|Release Notes]]
|
|-
!Moodle 2.9.2
|14 September 2015
|2015051102
| [[Moodle 2.9.2 release notes|Release Notes]]
|
|-
!Moodle 2.9.3
|9 November 2015
|2015051103
| [[Moodle 2.9.3 release notes|Release Notes]]
|
|-
! Moodle 2.9.4
|11 January 2016
|2015051104
|[[Moodle 2.9.4 release notes|Release Notes]]
|
|-
!Moodle 2.9.5
|14 March 2016
|2015051105
|[[Moodle 2.9.5 release notes|Release Notes]]
|
|-
!Moodle 2.9.6
|9 May 2016
|2015051106
|[[Moodle 2.9.6 release notes|Release Notes]]
|
|-
!Moodle 2.9.7
|11 July 2016
|2015051107
|[[Moodle 2.9.7 release notes|Release Notes]]
|
|-
!Moodle 2.9.8
|12 September 2016
|2015051108
|[[Moodle 2.9.8 release notes|Release Notes]]
|
|-
! Moodle 2.9.9
|14 November 2016
|2015051109
|[[Moodle 2.9.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.9.x ended 9 May 2016 (12 months).
Bug fixes for security issues in 2.9.x ended 14 November 2016 (18 months).
==Moodle 2.8==
{| class="wikitable"
|-
!Moodle 2.8
|10 November 2014
|2014111000
| [[Moodle 2.8 release notes|Release Notes]]
|[https://docs.moodle.org/28/en/Upgrading_to_Moodle_2.8 Upgrading to 2.8]
|-
!Moodle 2.8.1
|13 November 2014
|2014111001
| [[Moodle 2.8.1 release notes|Release Notes]]
|
|-
!Moodle 2.8.2
|12 January 2015
|2014111002
| [[Moodle 2.8.2 release notes|Release Notes]]
|
|-
!Moodle 2.8.3
|2 February 2015
|2014111003
|[[Moodle 2.8.3 release notes|Release Notes]]
|
|-
!Moodle 2.8.4
|9 March 2015
|2014111004
|[[Moodle 2.8.4 release notes|Release Notes]]
|
|-
!Moodle 2.8.5
|10 March 2015
|2014111005
|[[Moodle 2.8.5 release notes|Release Notes]]
|
|-
!Moodle 2.8.6
|11 May 2015
|2014111006
|[[Moodle 2.8.6 release notes|Release Notes]]
|
|-
! Moodle 2.8.7
|6 July 2015
|2014111007
|[[Moodle 2.8.7 release notes|Release Notes]]
|
|-
!Moodle 2.8.8
|14 September 2015
|2014111008
| [[Moodle 2.8.8 release notes|Release Notes]]
|
|-
!Moodle 2.8.9
|9 November 2015
|2014111009
|[[Moodle 2.8.9 release notes|Release Notes]]
|
|-
!Moodle 2.8.10
|11 January 2016
|2014111010
|[[Moodle 2.8.10 release notes|Release Notes]]
|
|-
!Moodle 2.8.11
|14 March 2016
|2014111011
|[[Moodle 2.8.11 release notes|Release Notes]]
|
|-
!Moodle 2.8.12
|9 May 2016
|2014111012
| [[Moodle 2.8.12 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.8.x ended 9 November 2015 (12 months).
Bug fixes for security issues in 2.8.x ended 9 May 2016 (18 months).
==Moodle 2.7 (LTS)==
{| class="wikitable"
|-
!Moodle 2.7
| 12 May 2014
|2014051200
|[[Moodle 2.7 release notes|Release Notes]]
|[https://docs.moodle.org/27/en/Upgrading_to_Moodle_2.7 Upgrading to 2.7]
|-
! Moodle 2.7.1
|14 July 2014
|2014051201
|[[Moodle 2.7.1 release notes|Release Notes]]
|
|-
!Moodle 2.7.2
|8 September 2014
|2014051202
|[[Moodle 2.7.2 release notes|Release Notes]]
|
|-
!Moodle 2.7.3
|10 November 2014
|2014051203
| [[Moodle 2.7.3 release notes|Release Notes]]
|
|-
!Moodle 2.7.4
|12 January 2015
|2014051204
| [[Moodle 2.7.4 release notes|Release Notes]]
|
|-
!Moodle 2.7.5
|2 February 2015
|2014051205
|[[Moodle 2.7.5 release notes|Release Notes]]
|
|-
!Moodle 2.7.6
|9 March 2015
|2014051206
|[[Moodle 2.7.6 release notes|Release Notes]]
|
|-
!Moodle 2.7.7
|10 March 2015
|2014051207
|[[Moodle 2.7.7 release notes|Release Notes]]
|
|-
!Moodle 2.7.8
|11 May 2015
|2014051208
|[[Moodle 2.7.8 release notes|Release Notes]]
|
|-
!Moodle 2.7.9
|6 July 2015
|2014051209
|[[Moodle 2.7.9 release notes|Release Notes]]
|
|-
!Moodle 2.7.10
| 14 September 2015
|2014051210
|[[Moodle 2.7.10 release notes|Release Notes]]
|
|-
!Moodle 2.7.11
|9 November 2015
|2014051211
|[[Moodle 2.7.11 release notes|Release Notes]]
|
|-
!Moodle 2.7.12
|11 January 2016
|2014051212
|[[Moodle 2.7.12 release notes|Release Notes]]
|
|-
!Moodle 2.7.13
|14 March 2016
|2014051213
|[[Moodle 2.7.13 release notes|Release Notes]]
|
|-
!Moodle 2.7.14
|9 May 2016
|2014051214
| [[Moodle 2.7.14 release notes|Release Notes]]
|
|-
!Moodle 2.7.15
|11 July 2016
|2014051215
|[[Moodle 2.7.15 release notes|Release Notes]]
|
|-
!Moodle 2.7.16
|12 September 2016
|2014051216
|[[Moodle 2.7.16 release notes|Release Notes]]
|
|-
!Moodle 2.7.17
|14 November 2016
|2014051217
|[[Moodle 2.7.17 release notes|Release Notes]]
|
|-
!Moodle 2.7.18
|9 January 2017
|2014051218
|[[Moodle 2.7.18 release notes|Release Notes]]
|
|-
!Moodle 2.7.19
|13 March 2017
|2014051219
|[[Moodle 2.7.19 release notes|Release Notes]]
|
|-
!Moodle 2.7.20
|8 May 2017
|2014051220
| [[Moodle 2.7.20 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.7.x ended 11 May 2015 (12 months).
Bug fixes for security issues in 2.7.x ended 8 May 2017 (36 months).
==Moodle 2.6==
{| class="wikitable"
|-
!Moodle 2.6
|18 November 2013
|2013111800
|[[Moodle 2.6 release notes|Release Notes]]
|[https://docs.moodle.org/26/en/Upgrading_to_Moodle_2.6 Upgrading to 2.6]
|-
!Moodle 2.6.1
|13 January 2014
| 2013111801
| [[Moodle 2.6.1 release notes|Release Notes]]
|
|-
!Moodle 2.6.2
|10 March 2014
|2013111802
|[[Moodle 2.6.2 release notes|Release Notes]]
|
|-
!Moodle 2.6.3
|12 May 2014
|2013111803
|[[Moodle 2.6.3 release notes|Release Notes]]
|
|-
!Moodle 2.6.4
|14 July 2014
|2013111804
|[[Moodle 2.6.4 release notes|Release Notes]]
|
|-
!Moodle 2.6.5
|8 September 2014
|2013111805
|[[Moodle 2.6.5 release notes|Release Notes]]
|
|-
!Moodle 2.6.6
|10 November 2014
|2013111806
|[[Moodle 2.6.6 release notes|Release Notes]]
|
|-
!Moodle 2.6.7
|12 January 2015
|2013111807
|[[Moodle 2.6.7 release notes|Release Notes]]
|
|-
! Moodle 2.6.8
|2 February 2015
|2013111808
|[[Moodle 2.6.8 release notes|Release Notes]]
|
|-
! Moodle 2.6.9
|9 March 2015
|2013111809
|[[Moodle 2.6.9 release notes|Release Notes]]
|
|-
!Moodle 2.6.10
|10 March 2015
|2013111810
| [[Moodle 2.6.10 release notes|Release Notes]]
|
|-
!Moodle 2.6.11
|11 May 2015
|2013111811
|[[Moodle 2.6.11 release notes|Release Notes]]
| Support has ended
|}
Bug fixes for general core bugs in 2.6.x ended 10 November 2014 (12 months).
Bug fixes for security issues in 2.6.x ended 11 May 2015 (18 months).
==Moodle 2.5==
{| class="wikitable"
|-
!Moodle 2.5
| 14 May 2013
|2013051400
|[[Moodle 2.5 release notes|Release Notes]]
| [https://docs.moodle.org/25/en/Upgrading_to_Moodle_2.5 Upgrading to 2.5]
|-
! Moodle 2.5.1
|8 July 2013
|2013051401
|[[Moodle 2.5.1 release notes|Release Notes]]
|
|-
!Moodle 2.5.2
|9 September 2013
|2013051402
|[[Moodle 2.5.2 release notes|Release Notes]]
|
|-
!Moodle 2.5.3
|11 November 2013
|2013051403
|[[Moodle 2.5.3 release notes|Release Notes]]
|
|-
!Moodle 2.5.4
|13 January 2014
| 2013051404
| [[Moodle 2.5.4 release notes|Release Notes]]
|
|-
!Moodle 2.5.5
|10 March 2014
|2013051405
|[[Moodle 2.5.5 release notes|Release Notes]]
|
|-
!Moodle 2.5.6
|12 May 2014
|2013051406
|[[Moodle 2.5.6 release notes|Release Notes]]
|
|-
!Moodle 2.5.7
|14 July 2014
|2013051407
|[[Moodle 2.5.7 release notes|Release Notes]]
|
|-
!Moodle 2.5.8
|8 September 2014
|2013051408
|[[Moodle 2.5.8 release notes|Release Notes]]
|
|-
! Moodle 2.5.9
| 10 November 2014
|2013051409
|[[Moodle 2.5.9 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.5.x ended May 2014 (12 months).
Bug fixes for security issues in 2.5.x ended 10 November 2014 (18 months).
==Moodle 2.4==
{| class="wikitable"
|-
! Moodle 2.4
|3 December 2012
|2012120300
|[[Moodle 2.4 release notes|Release Notes]]
|[https://docs.moodle.org/24/en/Upgrading_to_Moodle_2.4 Upgrading to 2.4]
|-
! Moodle 2.4.1
|14 January 2013
|2012120301
|[[Moodle 2.4.1 release notes|Release Notes]]
|
|-
!Moodle 2.4.2
|11 March 2013
|2012120302
|[[Moodle 2.4.2 release notes|Release Notes]]
|
|-
!Moodle 2.4.3
|18 March 2013
|2012120303
|[[Moodle 2.4.3 release notes|Release Notes]]
|
|-
!Moodle 2.4.4
|14 May 2013
|2012120304
|[[Moodle 2.4.4 release notes|Release Notes]]
|
|-
!Moodle 2.4.5
|8 July 2013
|2012120305
|[[Moodle 2.4.5 release notes|Release Notes]]
|
|-
!Moodle 2.4.6
|9 September 2013
|2012120306
|[[Moodle 2.4.6 release notes|Release Notes]]
|
|-
!Moodle 2.4.7
|11 November 2013
|2012120307
| [[Moodle 2.4.7 release notes|Release Notes]]
|
|-
! Moodle 2.4.8
|13 January 2014
|2012120308
|[[Moodle 2.4.8 release notes|Release Notes]]
|
|-
!Moodle 2.4.9
|10 March 2014
|2012120309
|[[Moodle 2.4.9 release notes|Release Notes]]
|
|-
!Moodle 2.4.10
|12 May 2014
|2012120310
| [[Moodle 2.4.10 release notes|Release Notes]]
|
|-
!Moodle 2.4.11
|14 July 2014
|2012120311
|[[Moodle 2.4.11 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.4.x ended December 2013 (12 months).
Bug fixes for security issues in 2.4.x ended June 2014 (18 months).
==Moodle 2.3==
{| class="wikitable"
|-
!Moodle 2.3
|25 June 2012
|2012062500
|[[Moodle 2.3 release notes|Release Notes]]
| [https://docs.moodle.org/23/en/Upgrading_to_Moodle_2.3 Upgrading to 2.3]
|-
!Moodle 2.3.1
|9 July 2012
|2012062501
|[[Moodle 2.3.1 release notes|Release Notes]]
|
|-
! Moodle 2.3.2
|10 September 2012
|2012062502
|[[Moodle 2.3.2 release notes|Release Notes]]
|
|-
!Moodle 2.3.3
|12 November 2012
|2012062503
|[[Moodle 2.3.3 release notes|Release Notes]]
|
|-
! Moodle 2.3.4
|14 January 2013
|2012062504
|[[Moodle 2.3.4 release notes|Release Notes]]
|
|-
!Moodle 2.3.5
|11 March 2013
|2012062505
|[[Moodle 2.3.5 release notes|Release Notes]]
|
|-
!Moodle 2.3.6
|18 March 2013
|2012062506
|[[Moodle 2.3.6 release notes|Release Notes]]
|
|-
!Moodle 2.3.7
|14 May 2013
|2012062507
|[[Moodle 2.3.7 release notes|Release Notes]]
|
|-
!Moodle 2.3.8
|8 July 2013
|2012062508
|[[Moodle 2.3.8 release notes|Release Notes]]
|
|-
!Moodle 2.3.9
|9 September 2013
|2012062509
|[[Moodle 2.3.9 release notes|Release Notes]]
|
|-
! Moodle 2.3.10
|11 November 2013
|2012062510
|[[Moodle 2.3.10 release notes|Release Notes]]
|
|-
!Moodle 2.3.11
|13 January 2014
|2012062511
|[[Moodle 2.3.11 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.3.x ended June 2013 (12 months).
Bug fixes for security issues in 2.3.x ended December 2013 (18 months).
==Moodle 2.2==
{| class="wikitable"
|-
! Moodle 2.2
|5 December 2011
|2011120500
|[[Moodle 2.2 release notes|Release Notes]]
|[https://docs.moodle.org/22/en/Upgrading_to_Moodle_2.2 Upgrading to 2.2]
|-
!Moodle 2.2.1
|9 January 2012
|2011120501
|[[Moodle 2.2.1 release notes|Release Notes]]
|
|-
!Moodle 2.2.2
|12 March 2012
|2011120502
|[[Moodle 2.2.2 release notes|Release Notes]]
|
|-
!Moodle 2.2.3
|14 May 2012
|2011120503
|[[Moodle 2.2.3 release notes|Release Notes]]
|
|-
! Moodle 2.2.4
|9 July 2012
|2011120504
|[[Moodle 2.2.4 release notes|Release Notes]]
|
|-
!Moodle 2.2.5
|10 September 2012
|2011120505
|[[Moodle 2.2.5 release notes|Release Notes]]
|
|-
!Moodle 2.2.6
|12 November 2012
|2011120506
| [[Moodle 2.2.6 release notes|Release Notes]]
|
|-
! Moodle 2.2.7
|14 January 2013
|2011120507
|[[Moodle 2.2.7 release notes|Release Notes]]
|
|-
!Moodle 2.2.8
|11 March 2013
|2011120508
|[[Moodle 2.2.8 release notes|Release Notes]]
|
|-
!Moodle 2.2.9
|18 March 2013
|2011120509
|[[Moodle 2.2.9 release notes|Release Notes]]
|
|-
!Moodle 2.2.10
|14 May 2013
| 2011120510
|[[Moodle 2.2.10 release notes|Release Notes]]
|
|-
!Moodle 2.2.11
|8 July 2013
|2011120511
|[[Moodle 2.2.11 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.2.x ended December 2012 (12 months).
Bug fixes for security issues in 2.2.x ended June 2013 (18 months).
==Moodle 2.1==
{| class="wikitable"
|-
!Moodle 2.1
| 1 July 2011
|2011070100
|[[Moodle 2.1 release notes|Release Notes]]
|[https://docs.moodle.org/21/en/Upgrading_to_Moodle_2.1 Upgrading to 2.1]
|-
! Moodle 2.1.1
|1 August 2011
|2011070101
| [[Moodle 2.1.1 release notes|Release Notes]]
|
|-
!Moodle 2.1.2
|10 October 2011
|2011070102
|[[Moodle 2.1.2 release notes|Release Notes]]
|
|-
!Moodle 2.1.3
|28 November 2011
|2011070103
|[[Moodle 2.1.3 release notes|Release Notes]]
|
|-
!Moodle 2.1.4
|9 January 2012
|2011070104
|[[Moodle 2.1.4 release notes|Release Notes]]
|
|-
!Moodle 2.1.5
|12 March 2012
|2011070105
|[[Moodle 2.1.5 release notes|Release Notes]]
|
|-
!Moodle 2.1.6
|14 May 2012
|2011070106
|[[Moodle 2.1.6 release notes|Release Notes]]
|
|-
! Moodle 2.1.7
|9 July 2012
|2011070107
|[[Moodle 2.1.7 release notes|Release Notes]]
|
|-
!Moodle 2.1.8
|10 September 2012
|2011070108
|[[Moodle 2.1.8 release notes|Release Notes]]
|
|-
!Moodle 2.1.9
|12 November 2012
|2011070109
|[[Moodle 2.1.9 release notes|Release Notes]]
|
|-
!Moodle 2.1.10
|14 January 2013
|2011070110
|[[Moodle 2.1.10 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.1.x ended June 2012 (12 months).
Bug fixes for security issues in 2.1.x ended December 2012 (18 months).
==Moodle 2.0==
{| class="wikitable"
|-
!Moodle 2.0
|24 November 2010
|2010112400
| [[Moodle 2.0 release notes|Release Notes]]
|[https://docs.moodle.org/20/en/Upgrading_to_Moodle_2.0 Upgrading to 2.0]
|-
!Moodle 2.0.1
|25 December 2010
|2010122500
|[[Moodle 2.0.1 release notes|Release Notes]]
|
|-
!Moodle 2.0.2
|21 February 2011
|2011022100
|[[Moodle 2.0.2 release notes|Release Notes]]
|
|-
!Moodle 2.0.3
|5 May 2011
|2011033003
|[[Moodle 2.0.3 release notes|Release Notes]]
|
|-
! Moodle 2.0.4
|1 August 2011
|2011033004
| [[Moodle 2.0.4 release notes|Release Notes]]
|
|-
!Moodle 2.0.5
|10 October 2011
|2011033005
|[[Moodle 2.0.5 release notes|Release Notes]]
|
|-
!Moodle 2.0.6
|28 November 2011
|2011033006
|[[Moodle 2.0.6 release notes|Release Notes]]
|
|-
!Moodle 2.0.7
|9 January 2012
|2011033007
|[[Moodle 2.0.7 release notes|Release Notes]]
|
|-
!Moodle 2.0.8
|12 March 2012
|2011033008
|[[Moodle 2.0.8 release notes|Release Notes]]
|
|-
!Moodle 2.0.9
|14 May 2012
|2011033009
|[[Moodle 2.0.9 release notes|Release Notes]]
|
|-
!Moodle 2.0.10
|9 July 2012
|2011033010
|[[Moodle 2.0.10 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 2.0.x ended December 2011 (12 months).
Bug fixes for security issues in 2.0.x ended June 2012 (18 months).
==Moodle 1.9==
{| class="wikitable"
|-
!Moodle 1.9
|3 March 2008
|2007101509
|[[Moodle 1.9 release notes|Release Notes]]
|[https://docs.moodle.org/19/en/Upgrading_to_Moodle_1.9 Upgrading to 1.9]
|-
!Moodle 1.9.1
|15 May 2008
| 2007101512
|[[Moodle 1.9.1 release notes|Release Notes]]
|
|-
! Moodle 1.9.2
|11 July 2008
|2007101520
|[[Moodle 1.9.2 release notes|Release Notes]]
|
|-
!Moodle 1.9.3
|15 October 2008
|2007101530
|[[Moodle 1.9.3 release notes|Release Notes]]
|
|-
!Moodle 1.9.4
|28 January 2009
|2007101540
|[[Moodle 1.9.4 release notes|Release Notes]]
|
|-
!Moodle 1.9.5
|13 May 2009
|2007101550
|[[Moodle 1.9.5 release notes|Release Notes]]
|
|-
!Moodle 1.9.6
|21 October 2009
|2007101560
|[[Moodle 1.9.6 release notes|Release Notes]]
|
|-
!Moodle 1.9.7
|25 November 2009
|2007101570
|[[Moodle 1.9.7 release notes|Release Notes]]
|
|-
!Moodle 1.9.8
|25 March 2010
|2007101580.00
|[[Moodle 1.9.8 release notes|Release Notes]]
|
|-
! Moodle 1.9.9
| 8 June 2010
| 2007101590.00
| [[Moodle 1.9.9 release notes|Release Notes]]
|
|-
!Moodle 1.9.10
|25 October 2010
|2007101591.00
|
[[Moodle 1.9.10 release notes|Release Notes]]
|
|-
!Moodle 1.9.11
|21 February 2011
|2007101591.02
|[[Moodle 1.9.11 release notes|Release Notes]]
|
|-
! Moodle 1.9.12
|10 May 2011
|2007101591.03
|[[Moodle 1.9.12 release notes|Release Notes]]
|
|-
!Moodle 1.9.13
|1 August 2011
|2007101591.04
|[[Moodle 1.9.13 release notes|Release Notes]]
|
|-
!Moodle 1.9.14
|10 October 2011
|2007101591.06
|
[[Moodle 1.9.14 release notes|Release Notes]]
|
|-
!Moodle 1.9.15
|28 November 2011
| 2007101591.07
| [[Moodle 1.9.15 release notes|Release Notes]]
|
|-
!Moodle 1.9.16
|9 January 2012
|2007101591.10
|[[Moodle 1.9.16 release notes|Release Notes]]
|
|-
! Moodle 1.9.17
|12 March 2012
|2007101591.12
|[[Moodle 1.9.17 release notes|Release Notes]]
|
|-
!Moodle 1.9.18
|14 May 2012
|2007101591.16
|[[Moodle 1.9.18 release notes|Release Notes]]
|
|-
! Moodle 1.9.19
|9 July 2012
|2007101592.00
|[[Moodle 1.9.19 release notes|Release Notes]]
|Support has ended
|}
Bug fixes for general core bugs in 1.9.x has ended June 2011 (3.5 years).
Bug fixes for security issues in 1.9.x by Moodle HQ ended June 2012 (4.5 years).
Bug fixes for security issues in 1.9.19+ branch by [http://catalyst.net.nz Catalyst IT] ended [http://moodle.org/mod/forum/discuss.php?d=199706 Dec 2013] (6 years).
==Moodle 1.8 ==
*[[Moodle 1.8 release notes|Moodle 1.8]] - 30 March 2007
*[[Moodle 1.8.1 release notes|Moodle 1.8.1]] - 14 June 2007
*[[Moodle 1.8.2 release notes|Moodle 1.8.2]] - 8 July 2007
*[[Moodle 1.8.3 release notes|Moodle 1.8.3]] - 11 October 2007
*[[Moodle 1.8.4 release notes|Moodle 1.8.4]] - 11 January 2008
*[[Moodle 1.8.5 release notes|Moodle 1.8.5]] - 8 April 2008
*[[Moodle 1.8.6 release notes|Moodle 1.8.6]] - 11 July 2008
*[[Moodle 1.8.7 release notes|Moodle 1.8.7]] - 15 October 2008
*[[Moodle 1.8.8 release notes|Moodle 1.8.8]] - 28 January 2009
*[[Moodle 1.8.9 release notes|Moodle 1.8.9]] - 15 May 2009
*[[Moodle 1.8.10 release notes|Moodle 1.8.10]] - 26 October 2009
*[[Moodle 1.8.11 release notes|Moodle 1.8.11]] - 25 November 2009
*[[Moodle 1.8.12 release notes|Moodle 1.8.12]] - 27 March 2010
*[[Moodle 1.8.13 release notes|Moodle 1.8.13]] - 8 June 2010
*[[Moodle 1.8.14 release notes|Moodle 1.8.14]] - 3 December 2010
*Support has ended

==Moodle 1.7==
*[[Moodle 1.7 release notes|Moodle 1.7]] - 7 November 2006
*[[Moodle 1.7.1 release notes|Moodle 1.7.1]] - 17 January 2007
*[[Moodle 1.7.2 release notes|Moodle 1.7.2]] - 30 March 2007
*[[Moodle 1.7.3 release notes|Moodle 1.7.3]] - 11 October 2007
*[[Moodle 1.7.4 release notes|Moodle 1.7.4]] - 11 January 2008
*[[Moodle 1.7.5 release notes|Moodle 1.7.5]] - 11 July 2008
*[[Moodle 1.7.6 release notes|Moodle 1.7.6]] - 15 October 2008
*[[Moodle 1.7.7 release notes|Moodle 1.7.7]] - 28 January 2009
*Support has ended
==Moodle 1.6==
*[[Moodle 1.6 release notes|Moodle 1.6]] - 20 June 2006
*[[Moodle 1.6.1 release notes|Moodle 1.6.1]] - 20 July 2006
*[[Moodle 1.6.2 release notes|Moodle 1.6.2]] - 12 September 2006
*[[Moodle 1.6.3 release notes|Moodle 1.6.3]] - 10 October 2006
*[[Moodle 1.6.4 release notes|Moodle 1.6.4]] - 17 January 2007
*[[Moodle 1.6.5 release notes|Moodle 1.6.5]] - 30 March 2007
*Moodle 1.6.6 - 11 January 2008
*Moodle 1.6.7 - 11 July 2008
*[[Moodle 1.6.8 release notes|Moodle 1.6.8]] - 15 October 2008
*[[Moodle 1.6.9 release notes|Moodle 1.6.9]] - 28 January 2009
* Support has ended
==Moodle 1.5==
*[[Moodle 1.5 release notes|Moodle 1.5]] - 5 June 2005
*[[Moodle 1.5.1 release notes|Moodle 1.5.1]] - 8 July 2005
*[[Moodle 1.5.2 release notes|Moodle 1.5.2]] - 16 July 2005
*[[Moodle 1.5.3 release notes|Moodle 1.5.3]] - 11 November 2005
*[[Moodle 1.5.4 release notes|Moodle 1.5.4]] - 21 May 2006
*Support has ended
==Moodle 1.4==
*Moodle 1.4 - 31 August 2004
*Moodle 1.4.1 - 12 September 2004
*Moodle 1.4.2 - 5 November 2004
*Moodle 1.4.3 - 21 December 2004
*Moodle 1.4.4 - 7 March 2005
*[[Moodle 1.4.5 release notes|Moodle 1.4.5]] - 7 May 2005
*Support has ended
==Moodle 1.3==
*Moodle 1.3 - 25 May 2004
* Moodle 1.3.1 - 4 June 2004
*Moodle 1.3.2 - 9 July 2004
*Moodle 1.3.3 - 16 July 2004
* Moodle 1.3.4 - 11 August 2004
*Moodle 1.3.5 - 9 September 2004
*Support has ended
==Moodle 1.2==
*Moodle 1.2 - 20 March 2004
*Moodle 1.2.1 - 25 March 2004
*Support has ended
==Moodle 1.1==
*Moodle 1.1 - 29 August 2003
*Moodle 1.1.1 - 11 September 2003
*Support has ended
== Moodle 1.0==
*Moodle 1.0 - 20 August 2002
*Moodle 1.0.1 - 26 August 2002
*Moodle 1.0.2 - 2 September 2002
*Moodle 1.0.3 - 5 September 2002
*Moodle 1.0.4 - 10 September 2002
*Moodle 1.0.5 - 27 September 2002
* Moodle 1.0.6 - 26 October 2002
::1.0.6.1 - 6 November 2002
::1.0.6.2 - 11 November 2002
::1.0.6.3 - 14 November 2002
::1.0.6.4 - 25 November 2002
*Moodle 1.0.7 - 9 December 2002
*Moodle 1.0.8 - 7 January 2003
*Moodle 1.0.9 - 30 May 2003
*Support has ended
==See also==
*[[Roadmap]] - future versions
*[[Moodle versions]] - an explanation of how our versions work plus version numbers for each release (for $plugin->requires)
[[Category:Release notes]]
[[Category:Core development]]
[[fr:Historique des versions]]
[[es:dev/Historia de las versiones]]
[[de:Versionshistorie]]