This is not directly relevant to the issue. I just spotted it while
working on the messaging API. Consider it as a well meant Trojan horse
on this branch ;-)
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
:-)
We are displaying available updates for installed plugins only. It was
decided (by me and Eloy) that we will not display info about available
Moodle update during the upgrade. It seems to be redundant as the admin
just uploaded a new version of Moodle so they probably chose what they
wanted.
The status_uptodate is a flag that the plugin's on-disk version and the
in-db version are in sync, that is no upgrade will be performed.
However, there can be a newer version of the plugin available. So using
the term "up-to-date" may be confusing.
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.
We will need to know our major version to fetch the relevant data from remote
servers. This patch also fixes yet another place where the version used
to be hard-coded.
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.
This reverts commit 296c0247c6cc9e525721fc92b5a78c7146e6887d, reversing
changes made to 2511b0742a3695298d8216fe9723581c089909d7.
Conflicts:
lib/db/upgrade.php
version.php
