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.
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.
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 patch introduces new lib/pluginlib.php library that provides
unified access meta-information about all present plugin types. The
library defines plugin_manager singleton that in turn gathers
information about all present plugins and their status. The list of
plugins can be rendered either as plugins check table or plugins control
panel.
This makes print_plugins_table() function obsolete and because it is not
expected to be called by any contrib plugin, the function is removed.
CSS for the legacy table generated by print_plugins_table() is cleaned
up.
