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.
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.
The idea is to build a plugin that will internally call the random
allocator when the submissions deadline is reached. The teacher is able
to pre-define the configuration for the random allocator.
Includes:
* constants refactoring
* reworked db table init
* support for $CFG->debug = -1
* functional DB tests
* fixed $DB->get_indexes() to not throw exceptions when table does not exist
* fix handling of user passwords in test db
* add debug info to exception messages
* removed unnecessary PHP debug errors from mathslib
* fixed @error suppression in get_string
* fixed PHPUnit error handler setup
* added timezone info to default install
This method accepts all detected changes in cron-based fetch and picks
those the site admins want to be informed about (based on the maturity
level etc).
If enabled, Moodle sites will check for updates every night sometimes
between 01:00 AM and 06:00 AM local time. The actual offset will be
generated randomly at the beginning and used consistently since then.
This way, the queries against the server are supposed to be spread in
time.
Serious site admins should not try to upgrade their sites later than
01:00 AM as they are too tired already. Neither should they do it before
06:00 AM as they did not have a morning coffee yet and are too tired yet
:-)
The filelib is usually loaded already. However, during some steps of the
upgrade the curl class must be available to perform fetches of updates
and the library does not need to be loaded yet.
In case of Moodle code itself, there is no plugin_manager like class
available so the checker class itself must be aware of versions and
actually do the checks. On the other hand, we can always rely that
version, release and maturity are always returned by the remote server.
The purpose of the class is to fetch the information about available
updates for the Moodle core and/or Moodle components from a remote site
and cache it locally.
These changes are motivated by feedback from Tim Hunt (17 October 2011
in the developers chat room). The combination of using an interface, but
then putting all the useful information in public fields, was not good
design of this library. So I am merging the plugin_information interface
and the plugintype_base class into a new abstract class plugininfo_base.
This new class defines the basic API of all information holding
subclasses. This does not change the code, just puts the documentation
closer to the methods they are actually implemented.
David Mudrák