This optional environmental check will look if:
- the site is running php72.
- the site has igbinary extension enabled.
- the igbinary extension version is a buggy one >=3.2.2 <= 3.2.4
- the bug is reproducible.
And will warn if all the conditions are met.
* Plugins can now explicitly declare supported and incompatible Moodle
versions in version.php
- $plugin->supported[37,39];
supported takes an array of ascending numbers, that correspond to a
range of branch numbers of supported versions, inclusive. Moodle
versions that are outside of this range will produce a message
notifying at install time, but will allow for installation.
- $plugin->incompatible = 36;
incompatible takes a single int corresponding to the first incompatible
branch. Any Moodle versions including and below this will be prevented
from installing the plugin, and a message will be given when
attempting installation.
These functions were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_fix_config_auth_plugin_names()
- upgrade_fix_config_auth_plugin_defaults()
These functions and setting were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_theme_is_from_family()
- upgrade_find_theme_location()
- linkcoursesectionsupgradescriptwasrun setting
Similarly to how the scheduled tasks work, we now automatically check
and make sure that all the models specified in the component's
db/analytics.php file exist during the installation or upgrade of the
component.
Partially update the API documentation of function
upgrade_plugin_savepoint.
This restores consistency between function parameters and API
documentation; as commit 17da2e6f28 (fix
for MDL-16438) had renamed parameter $dir to $plugin, but not also
applied this change to the API documentation.
Also reword the parameter comment text so that it is more meaningful to
developers: document that the parameter contains the name of the plugin.
Change the API documentation of parameter $type as well so that it is
a) correct, and
b) not in conflict with the API documentation for $plugin.
During a CLI upgrade when there are new settings in core or in
a plugin, the settings are set to the defined defaults
automatically. There is no ouput shown on the CLI about which
new settings have been introduced or what default values the
setting are set to.
This patch outputs the name of the new setting and what the
default value being is set is to the CLI during an upgrade.
Objects and arrays are expanded into a human readable format.
This plugin also makes the function that sets the defaults to
be more robust so it isno longer required to be called multiple
times to ensure all settings are set.
The new setting will allow to host the temporary backup files
into a specific target directory. Defaults to '$CFG->tempdir/backup'.
Calling make_backup_temp_directory() checks that the required sub-directory
will be properly created under the new target directory.
All these functions were used only by deleted upgrade steps
so it's safe to proceed with straight deletion, considering
them internal. Deletion has been documented in corresponding
upgrade.txt files:
- upgrade_mimetypes()
- upgrade_fix_missing_root_folders_draft()
- upgrade_minmaxgrade() and upgrade_minmaxgradestepignored setting
- upgrade_course_tags()
- atto_equation_update_librarygroup4_setting()
- mod_lti_upgrade_custom_separator()
These have been kept because continue being used by restore:
- upgrade_group_members_only()
- upgrade_extra_credit_weightoverride()
- upgrade_calculated_grade_items()
As a result of fixing the auth plugins config storage in MDL-12689, many
settings would be falsely reported as new ones by
admin/upgradesettings.php. We do not want to confuse admins so we try to
reduce the bewilderment by pre-populating the config_plugins table with
default values. This should be done only for disabled auth methods. The
enabled methods have their settings already stored, so reporting actual
new settings for them is valid.
Some auth plugins used to have a mix of the legacy style of plugin names
in config_plugins table (such as 'auth/mnet') and the new correct
style (such as 'auth_mnet'). Attempting to rename the setting plugin via
low level SQL UPDATE could lead to duplicate key violation.
The patch introduces a new helper function to safely migrate the old
settings to the new ones, eventually informing the admin about the
values mismatch.
Unfortunately it has come to light that the version sniffing is just not
reliable at all, operating system vendors backport security patches to
older versions - so in many cases we reporting a problem which is not a
problem. False positives and the solution to self-compile or something
like php will be causing more harm than good.
