The method available_update_deployer::make_execution_widget() used to
have hard-coded return URL. Now it accepts the return URL as the second
parameter and passes it to the mdeploy.php utility.
The callerurl parameter is now correctly passed and used.
Plugins that are to be installed and plugins that are missing from disk
are now highlighted at the Plugins overview screen. Other statuses (such as
of plugin to be upgraded) should not be needed at this page as those
are primarily intended for the Plugins checks screen during the upgrade.
This is much better API than using the array passed by reference. At the
moment, it is pretty hacky as it abuses text_progress_trace to output
raw HTML echoed by uninstall_plugin() but that will be improved later
while moving the logic out of that function into the plugin_manager.
As suggested by Tim Hunt during the peer-review, rendering methods
should not set properties of the page they are producing HTML code for.
Additionally, the page now uses correct check that the uninstalling can
happen.
This patch returns the layout of the Uninstall | Settings links to two
columns. There is no space saved on the screen by using the single
column and two columns align better. The reasoning for using single
column was that there would be multiple links in the 'Actions' column
but that does not seem to happen anytime soon.
The get_uninstall_url() method of all subclasses of plugininfo_base
class is now expected to always return moodle_url. Subclasses can use
the new method is_uninstall_allowed() to control the availability of the
'Uninstall' link at the Plugins overview page (previously they would do
it by get_uninstall_url() returning null). By default, URL to a new
general plugin uninstall tool is returned. Unless the plugin type needs
extra steps that can't be handled by plugininfo_xxx::uninstall() method
or xmldb_xxx_uninstall() function, this default URL should satisfy all
plugin types.
The overall logic is implemented in plugin_manager::can_install_plugin()
that respects the plugininfo class decision and vetoes it in certain
cases (typically when plugin or its subplugin is required by some other
plugin).
Plugins may use this general tool for uninstallation and eventually
removal of the deployed source code. At the moment, this is implemented
as a wrapper for the core function uninstall_plugin() with an extra hook
in the relevant plugin info subclass.
For non-standard add-ons, the tool can remove the deployed plugin source
code as well, if the web server has required write permissions. Ideally,
all add-ons installed via the new tool_installaddon should be removable
via the web interface as well.
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.
This was reported in forums as an usability issue. This icon is used
across Moodle as an active link to hide or show things - not as a status
icon. People were trying to disable plugins by clicking the icon. Until
there is a full support for doing this from the Plugins overview page,
it is better to remove the icons completely.
The Notifications (admin/index.php) page has now information about
available updates for core and eventually plugins, too. Note that the
structure of the available updates array changed. This breaks backward
compatibility for eventual 3rd renderers out there (not expected
though).
Previously, it was the renderer method that actually called
all_plugins_ok(). I believe that renderer methods should not be
responsible for such an important step in the install/upgrade code flow.
So dependencies are now checked by admin/index.php on upgrade, too.
This follows the same path as we have in CLI installers. Plugin
dependencies are checked right after the environment checks and the
install can't continue unless all dependencies are fixed.
Now the message 'Your Moodle code is up-to-date!' is displayed only if
the fetch was done within the last hour. Otherwise, just the button
'Check for available updates' is displayed.
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.
