This was a regression of my recent improvement of rendering the "Check
for updates" button. There is now unified parameter ?fetchupdates=1 that
can be used on either admin/index.php or admin/plugins.php, so that we
can use a common UI widget for both locations (without the need to pass
the URL explicitly).
This should allow the admin to revert the upgrade of existing plugins,
such when the dependency chain leads to a dead-end. Additionally, we
archive (as a last-chance copy) the to-be-installed plugins when
cancelling their installation. This is mainly for developers who could
otherwise loose their code. For the same reason, plugins are being
archived upon uninstallation, too.
The plugin manager's method install_remote_plugins() has been changed to
install_plugins() and it is now able to install plugins from the
provided list of locally available ZIP files, too. This is used by the
Install plugins admin tool.
Includes:
* update checker refactored to \core\update\ namespace
* plugininfo classes refactored to \core\plugininfo\ namespace
* plugin_manager renamed to core_plugin_manager
* redirect back to original page after plugin uninstall
* fixed assign subplugin uninstall
* move assign subplugins under the assignment in admin tree
* fixed plugininfo for all question related plugin types
* auth uninstall support
* added missing block dependencies
* added theme uninstall
* subplugin types are following the plugin on plugin overview page
* several performance improvements in plugin manager
* new warnigns when plugininfo are outdated or missing
* multiple fixes and other improvements
Includes rework of cache parameter detection on admin/index.php.
Another problem is that uninstall does not leave system in consistent state,
we need to force users to go through upgrade after any type of uninstall.
This fixes also add-on installation redirect and other issues.
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.
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.
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 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.
