Unregistered sites will now display registration form to admins
after every upgrade, including plugin upgrades.
Registration form will not show for sites that are not set to public.
* Use the page title separator constant when displaying the page title
during upgrade and installation.
* No need to display the site name during install when because it hasn't
been set at this point.
While, right now, sites using long (> 10 chars) $CFG->prefix
can continue working (because we still don't have any table
> 28 chars), as soon as some new table with long name is added,
it won't work with PostgreSQL anymore (if the 63 limit is raised).
Hence, this environmental check will verify on both install and
upgrade that the $CFG->prefix is always <= 10 chars.
Sites with longer prefixes will need to rename all their tables
(and maybe other objects, depending on the dbtype) to use a shorter
prefix.
Unregistered sites will now display registration form to admins
after every core upgrade. Non core upgrades will not trigger the
form.
Registration form will not show for sites that are not set to
public.
This partially reverts MDL-73270, where some useful environmental
checks and notifications in the admin UI were added to inform
about different parts of Moodle relying on the "unsupported"
php-xmlrpc extension.
Since then, some changes have happened in core, only available
for Moodle 4.1 and up (see the MDL-70889 mini-epic). Namely:
- MNet (SSO, roaming, auth, enrol and Mahara portfolio) are not
using the php-xmlrpc extension anymore, but a pure php library.
- The xmlrpc webservices protocol, has been move from core to
the plugins directory, although it continues using the php-xmlrpc
extension.
Because of that here we are removing all the checks and notifications
related with MNet (not using the extension anymore), but keeping the
webservice plugin ones (still using the extension). Surely if some day the
protocol stops using the extension, we'll be able to remove the
corresponding checks too. But that's future.
Note the associated lang strings have been also removed (not deprecated)
because they were highly specific and hardly reusable:
- xmlrpcmaharaenabled
- xmlrpcmnetauthenticationenabled
- xmlrpcmnetenabled
And very same applies, because MNet doesn't contain anything deprecated
or not supported anymore, hence, straight deletion, to the function:
- mnet_get_deprecation_notice()
Also, related tests using any of the removed stuff above have been deleted.
In the other side, the "check_xmlrpc_usage" continues existing and
being used both by environment checks and admin notifications but,
as commented above, now it only looks for the xmlrpc webservice
protocol now.
* Adds time logging (number of seconds for each success) on install,
which was previously only shown in upgrades. Useful when installing
a new plugin as part of an upgrade, or if anyone wants to optimise
Moodle installation.
* In developer debug mode, upgrade savepoint time was already logged
but now it also logs time for lots of 'details' of the process in
case time is taken in other Moodle function calls.
There are many places (install/upgrade for core, modules, blocks,
and plugins) where we need to call the same, or very similar,
sequence of Moodle functions to ensure the item is updated properly.
This change moves that sequence into a function so that it can be
held consistently in one place.
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.
Matt Porritt