The previous 2.9 implementation of is_web_crawler() used stripos() in
certain cases. The unit tests re-added in the previous commit revealed
that certain crawlers (such as BaiDuSpider) were not correctly detected
in the new refactored implementation.
It seems lesser evil and safe enough to use /i in the regex search even
though it is not 100% same logic as before - as stripos() was used in
some cases only, not always.
Norfolk Island's standard time (NFT) was on UTC+11:30 until 4 October
2015, when it was changed to UTC+11:00. So it's not suitable for 11.5
bad mapping replacement anymore.
It seems that there isn't any other location using such 11.5 timezone
so completely getting rid of it for conversions.
This commit covers all events outside of /mod/. It adds mapping info for restoring
events, or the default implementation which returns false if mapping is not required.
This is not really necessary as there is no actual change in the
behaviour of the updates API between 1.2 and 1.3. However, as we plan to
use the new \core\update\api client for this in the future, it makes
only sense to have these two synced already now. In other words, Moodle
3.0 site will use the same version 1.3 for all download.moodle.org/api
end points.
The admin setting updateautodeploy no longer exists. The two existing
config.php flags $CFG->disableupdateautodeploy and
$CFG->disableonclickaddoninstall merged into a single one.
If there is an available archived zip with the version of the plugin
currently installed, we can use it to cancel/abort the upgrade of the
plugin. This is internally handled as the installation of the archived
zip and goes through all the validation and confirmation.
Additionally, some other parts were improved. Most notably, renderer no
longer decides itself if some installation can be cancelled but it
always asks the controller (plugin manager).
The button for installation was moved to the left so there should be
first buttons to add things, and then buttons to cancel things (which is
common in normal forms).
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.
Do not attempt to read an unreadable directory because previously the generated
errors were hard to fathom.
Thanks to James McQuillan for the basis of the patch.
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.
During the testing, I was experiencing weird behaviour - after a single
plugin updated was installed, I ended up on admin/index.php?cache=1. I
believe it was caused by the missing opcache_reset().
The new method core_plugin_manager::install_remote_plugins() will serve
as a backend for all the ways of installing ZIP packages from the moodle
plugins directory, such as installing new plugins (by clicking the
Install button in the plugins directory), installing available updates
(single and bulk mode) and installing missing dependencies (single and
bulk mode).
The method should be used both for validation pre-check screen and,
after the confirmation, for actual installation. Note that we
intentionally repeat the whole procedure after confirmation. Unzipping
plugins is cheap and fast and the ZIPs themselves are already available
in the \core\update\code_manager's cache.
We will need to add support for archiving existing code to prevent
accidental data-loss.
This basically provides what mdeploy.php was doing, but better. We now
have consistent way of installing all remote ZIP packages, always
validate them and we can perform bulk operations, too.
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.
If the plugin was missing from disk, the required core version was
displayed as "Moodle {$a}" because the core dependency resolver always
returns an object.
The previous version of the plugin manager's method
get_remote_plugin_info() was suitable for installing missing
dependencies only. To make use of for installing new plugins and/or
available updates, it must be clear that we are requesting information
for the particular plugin version only, not "given or higher" version.
The plugins check screen now provides buttons to cancel installation of
a plugin. Available only for new installations (not upgrades) and for
additional plugins (not standard), given that the web server process has
write access to the plugin folder.
This has also been reported as MDL-48535.
As a part of the patch, there is improved processing of page URLs during
the upgrade. All this dancing around $reload URL is not needed once the
$PAGE->url is properly set to guide the admin on the correct page during
the upgrade process.
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 patch improves the dependencies resolution in the plugin manager so
that the information about availability of the missing dependency is
included and can be displayed at the Plugins check screen during the
upgrade.
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 patch moves the resolving logic from the renderer (where it should
not really be) to the plugin manager (controller). This is needed
because we will need the very same logic to be used at other places.
The actual loading of available updates info objects is moved back to
the plugin manager class. As we can now mockup the manager in unit
tests, this allows us to bypass the real \core\update\checker and have
unit tests for \core\plugininfo\base::available_updates().