This has exactly the same behaviour as the existing
plugintype_name_plural() method, but returns the singular form of the
plugin type (such as 'Activity module').
This new method just takes the result of the core get_plugin_types() and
re-orders the plugin types in the same way as they are displayed at the
Plugins overview screen.
For statslib tests was enough to require cronlib.php as
far as all the tests there are using ob-capture / output
expectations, so the new function does not bork anything.
For pluginlib tests finally the use was deleted because
it's a part of cron not interesting (should be always "cheap")
and to keep it there we should be adding a bunch of output
expectations under some cases, for practically nothing.
Data cached in these caches change only at well defined places (during
need for upgrade checks, at the plugin management screen etc). So it
makes sense to use proper application caches instead of request caches.
This saves couple of database queries at almost every page in Moodle.
Where the static variable was not really needed (as in case of arrays
defined by the hard-coded list of items), non-static variable is used as
I believe that there is no real performance gain.
There was a problem experienced after 2.4.0 release because the version
of the 2.4.0 release was the same as 2.5dev release. So the version
value matched twice in the loop and the line was repeated in the email.
Before this patch, the available_update_checker::cron_notifications()
method accessed the availableupdates property. But for plugins, that property
basically contains the most recent version available. So we were missing
the check against the actual version installed.
The fix was simple - obtain available updates via the available_updates()
method that performs the check.
This patch makes Moodle call HTTP HEAD method via cURL to see if the ZIP
is expected to be downloadable by mdeploy.php. This is mainly intended
for SSL certificates check.
From now on, Moodle verifies the available updates provider server. To
make it work, either there must be a valid CA certificate available in
the operating system, or the administrator has to upload the valid CA
certificate to moodledata/moodleorgca.crt (PEM format) file manually.
The correct policy is that users with moodle/question:config can set the
default settings for particular qtypes. However, it requires
moodle/site:config in order to do manage qbehaviours or manage qtypes.
It turned out that this well-meant debugging message just caused a lot
of false alarm with no good reason. It seems to be better just ignore it
at the moment.
There was a potential security risk that someone with access to the Moodle
database could update mdl_config table and use it as a vector to
install malicious code on the server.
Credit goes to Dan Poltawski for raising this.
If the stored response has still 1.0 version (which is expected during
the upgrade to 2.4), a debugging message is displayed. Added a string to
explain what's going on and how to recover from the state.
The caller of the mdeploy.php utility is expected to create a file in
the data directory. The name of such file and the passphrase in it are
then sent to mdeploy.php as a part of the request. The submitted and
stored values are then compared.
This class represents the communication bridge from Moodle UI to the
(standalone) mdeploy.php utility. It consists of various helper methods
useful when dealing with user interface, update confirmation etc.
The class is implemented as a singleton. This allows us easily
transfer required data from top level scripts (like /admin/index.php)
into the rendering methods deep in the stack without the need to change
the API of many methods on the way.
David Mudrák