Previously, the acknowledgement was required only when installing
plugins from the ZIP file. It is valid when installing plugins from the
Plugins directory, too. So we display it at the validator page now to
make sure it is displayed in both cases.
There is no need to require the admin to check the acknowledgement box
now. We do not do that anywhere in admin UI (and there are more
dangerous operations than installing a plugin). Admins still can deploy
plugins manually without this tool anyway. And at the end, they are
admins. They should know what they are doing. Simply displaying the
acknowledgement message before they click the install button is enough.
Now we allow the plugin type left unselected and we attempt to
auto-detect it. Only when the auto-detection fails, the admin has to
manually select the type of the plugin.
On contrary to deeper heuristic (read: guessing) we perform in the
Plugins directory (such as looking at the names of the language files),
here we simply rely on the plugin component being correctly defined in
the version.php file.
The validator class has more robust processing, to make sure the
component declaration is not provided in a commented area of the
version.php etc. However, as it is fully acceptable that the
auto-detection fails if the version.php uses non-standard syntax, this
easier approach is valid here.
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
Better performance, more reliable, completely self contained,
more validation and full backwards compatibility.
This will also allow us to implement ignoring of plugins.
The native rename() function does not support moving folders
cross-device. See https://bugs.php.net/bug.php?id=54097 for details. So
instead of trying to move the whole tree, the new installer's method
moves files recursively one by one.
This is consistent with what mdeploy.php already does.
This is necessary because PHP in Windows does not have any certificates and some *nix systems have outdated or missing ca bundles too.
The order is:
1/ dataroot/moodleorgca.crt always wins - needs to be added manually by admin
2/ php.ini setting "curl.cainfo" is next
3/ on Windows libdir/cacert.pem is used because it does not have any default cert bundles
4/ system default is the last - the previous value, ok for properly configured *nix systems
Both classes using cURL features now access it via the core curl wrapper
class. Credit goes to Dan Poltawski for spotting the previous discrepancy
during the integration review.
There is a new hook in the index.php file. If valid HTTP parameter
installaddonrequest is detected, the installer asks the administrator to
confirm the request.
If confirmed, the installer calls download.moodle.org/api/1.2/pluginfo.php
service to get information about the given plugin version. The essential
data are the URL of the ZIP to download and the MD5 hash of the ZIP.
These data must be fetched via HTTPS to protect against MiM attack.
If the ZIP is downloaded and the MD5 content hash is correct, the user
is redirected to the previously implemented ZIP validation page, as if
the ZIP was uploaded manually.
The valid format of the installaddonrequest is documented via the
test_decode_remote_request() unit test method.
The script validate.php expects a ZIP file stored in a temporary
location. It extracts the ZIP (optionally renaming the root directory)
and executes the validator. Then it renders the validator log messages
and continue buttons.
The validator code contains (modified) fragments of the
local_plugins_archive_validator class copyrighted by Marina Glancy that
is part of the local_plugins plugin. It operates over an extracted
copy of the ZIP file.