The method move_plugin_directory() was a relict from previous 2.9
implementation within tool_installadon_installer and was originally
supposed to be used to move whole plugin folders. The archiving feature
has been finally implemented via using zip files (so that we do not have
actual PHP code present in the dataroot) and we do not need this method.
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.
Previously, the validator was used for installation of the new plugins
only. We now validate every incoming plugin package. As a result, we
must no longer insists on the target location is empty. Instead, warning
is raised.
The mdeploy.php standalone script (used to download and unzip plugins
into the dirroot) and the \core\update\deployer class (as a
communication bridge between the core and the mdeploy.php) was
originally designed and implemented with the assumption that it would be
eventually used for updating the Moodle core itself, too. Therefore it
was written as standalone utility without dependency on the Moodle core
libraries.
However, it never happened and there is no real demand for that. So now
there is no need to have and maintain a completely parallel solution for
common things like fetching and unzipping plugin ZIPs.
Additional reasoning for mdeploy.php was that the core is not very
reliable during the core upgrade and we could run into various troubles.
This does not seem to be that bad. We rely on a lot of core
functionality (such as output rendering, DB access etc) and plugins
deployment seems to work well (and better) with common core libraries.
So long mdeploy, and thanks for all the hard work you did for us.
This is not really new class. Originally, the validator was implemented
in the scope of the tool_installaddon plugin. But we need its features
in other parts at the core level (e.g. during the upgrade to validate
available missing dependencies or available updates). Looking back, it
was a mistake to have it implemented at the plugin level rather than the
core level.
So this patch moves the tool_installaddon_validator class to
\core\update\validator class, together with associated unit tests,
fixture files and strings. There were changes made in the
tool_installaddon to make use of this new class instead of the old one.
This is a great step towards the bright future, hopefully there won't be
many regressions.
AMOS BEGIN
MOV [validationmsg_componentmatch,tool_installaddon],[validationmsg_componentmatch,core_plugin]
MOV [validationmsg_componentmismatchname,tool_installaddon],[validationmsg_componentmismatchname,core_plugin]
MOV [validationmsg_componentmismatchname_help,tool_installaddon],[validationmsg_componentmismatchname_help,core_plugin]
MOV [validationmsg_componentmismatchname_info,tool_installaddon],[validationmsg_componentmismatchname_info,core_plugin]
MOV [validationmsg_componentmismatchtype,tool_installaddon],[validationmsg_componentmismatchtype,core_plugin]
MOV [validationmsg_componentmismatchtype_info,tool_installaddon],[validationmsg_componentmismatchtype_info,core_plugin]
MOV [validationmsg_filenotexists,tool_installaddon],[validationmsg_filenotexists,core_plugin]
MOV [validationmsg_filesnumber,tool_installaddon],[validationmsg_filesnumber,core_plugin]
MOV [validationmsg_filestatus,tool_installaddon],[validationmsg_filestatus,core_plugin]
MOV [validationmsg_filestatus_info,tool_installaddon],[validationmsg_filestatus_info,core_plugin]
MOV [validationmsg_foundlangfile,tool_installaddon],[validationmsg_foundlangfile,core_plugin]
MOV [validationmsg_maturity,tool_installaddon],[validationmsg_maturity,core_plugin]
MOV [validationmsg_maturity_help,tool_installaddon],[validationmsg_maturity_help,core_plugin]
MOV [validationmsg_missingcomponent,tool_installaddon],[validationmsg_missingcomponent,core_plugin]
MOV [validationmsg_missingcomponent_help,tool_installaddon],[validationmsg_missingcomponent_help,core_plugin]
MOV [validationmsg_missingcomponent_link,tool_installaddon],[validationmsg_missingcomponent_link,core_plugin]
MOV [validationmsg_missingexpectedlangenfile,tool_installaddon],[validationmsg_missingexpectedlangenfile,core_plugin]
MOV [validationmsg_missingexpectedlangenfile_info,tool_installaddon],[validationmsg_missingexpectedlangenfile_info,core_plugin]
MOV [validationmsg_missinglangenfile,tool_installaddon],[validationmsg_missinglangenfile,core_plugin]
MOV [validationmsg_missinglangenfolder,tool_installaddon],[validationmsg_missinglangenfolder,core_plugin]
MOV [validationmsg_missingversion,tool_installaddon],[validationmsg_missingversion,core_plugin]
MOV [validationmsg_missingversionphp,tool_installaddon],[validationmsg_missingversionphp,core_plugin]
MOV [validationmsg_multiplelangenfiles,tool_installaddon],[validationmsg_multiplelangenfiles,core_plugin]
MOV [validationmsg_onedir,tool_installaddon],[validationmsg_onedir,core_plugin]
MOV [validationmsg_onedir_help,tool_installaddon],[validationmsg_onedir_help,core_plugin]
MOV [validationmsg_pathwritable,tool_installaddon],[validationmsg_pathwritable,core_plugin]
MOV [validationmsg_pluginversion,tool_installaddon],[validationmsg_pluginversion,core_plugin]
MOV [validationmsg_release,tool_installaddon],[validationmsg_release,core_plugin]
MOV [validationmsg_requiresmoodle,tool_installaddon],[validationmsg_requiresmoodle,core_plugin]
MOV [validationmsg_rootdir,tool_installaddon],[validationmsg_rootdir,core_plugin]
MOV [validationmsg_rootdir_help,tool_installaddon],[validationmsg_rootdir_help,core_plugin]
MOV [validationmsg_rootdirinvalid,tool_installaddon],[validationmsg_rootdirinvalid,core_plugin]
MOV [validationmsg_rootdirinvalid_help,tool_installaddon],[validationmsg_rootdirinvalid_help,core_plugin]
MOV [validationmsg_targetexists,tool_installaddon],[validationmsg_targetexists,core_plugin]
MOV [validationmsg_targetexists_help,tool_installaddon],[validationmsg_targetexists_help,core_plugin]
MOV [validationmsg_unknowntype,tool_installaddon],[validationmsg_unknowntype,core_plugin]
MOV [validationmsg_versionphpsyntax,tool_installaddon],[validationmsg_versionphpsyntax,core_plugin]
MOV [validationmsglevel_debug,tool_installaddon],[validationmsglevel_debug,core_plugin]
MOV [validationmsglevel_error,tool_installaddon],[validationmsglevel_error,core_plugin]
MOV [validationmsglevel_info,tool_installaddon],[validationmsglevel_info,core_plugin]
MOV [validationmsglevel_warning,tool_installaddon],[validationmsglevel_warning,core_plugin]
AMOS END
The plan is to have a single tool looking after all operations with
plugin ZIP packages (downloading, unzipping, moving to the dirroot and
back). For legacy reasons, we have that logic currently duplicated in
mdeploy and tool_installaddon. I would like to unify and simplify the
whole machinery to use the same code for available updates, manual
installation and plugin dependencies.
The purpose of this class is to provide a general client for all APIs
available at https://download.moodle.org/api/ (e.g. available updates,
plugin info, plugins list etc). Currently, fetching data from this API
is done separately at several places. This leads to code duplication and
harder maintenance (I know it well).
Additionally, the existing client was implemented as
tool_installaddon_pluginfo_client in the admin/tool/installaddon/ scope.
I will soon need to use the same functionality in the
core_plugin_manager and it would hurt my karma if the core was depending
on a class provided by a admin tool plugin (even if it is standard one).
So, there is new \core\update\api client implementing the version 1.3 of
the pluginfo API. There is a TODO note left for remaining services.
The method should check against $CFG->disableupdatenotifications and not
$CFG->disableupdateautodeploy. This had to be a copy&paste mistake from
the \core\update\deployer::enabled().
While looking at it, I also fixed couple of places where this method
should and could be used.
These are cosmetic improvements spotted while working on the issue.
1. Do not waste time if there are no changes to notify about.
2. Fix the legacy plugin manager's get_plugins() call.
Credit goes to PJ King. I was trying to add unit tests for this new
behaviour but it turned out there are many hard-coded dependencies and
it's not easy to make the whole machinery support alternative location
of testable (fake) plugins.
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
