dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
The admin setting updateautodeploy no longer exists. The two existing
config.php flags $CFG->disableupdateautodeploy and
$CFG->disableonclickaddoninstall merged into a single one.
Most of the functionality provided by this tool (typically the
validation and actual deployment of the plugin package) has been moved
to the core level. So this is becoming just a thin wrapper and user
interface for installing new plugins via the administration UI.
Also fixes MDL-49600 as we no longer keep the unzipped contents of the
packages in the persistent temp directories.
The method detect_plugin_component() returns false or string. The
normalize_component() expects strings only. Passing false to it
(typically when the plugin does not declare its component) caused the
PHP warning.
Credit goes to Ankit Agarwal for spotting this during testing.
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.
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.
