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.
Previously when the server response validation had failed, the property
available_update_checker::recentresponse was left as NULL. This caused
problems in available_update_checker::compare_responses() that expects
proper arrays passed.
This patch makes invalid data being ignored by setting the property to
an empty array as if no data have been fetched yet. A debugging message
is thrown so the admins will be able to diagnose eventual problems in
the future.
David Mudrák