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.
David Mudrák