If the user selects a plugin in Moodle plugins directory to be installed
into their site, Moodle plugins directory will redirect them into their
site's admin/index.php script, providing the installaddonrequest
parameter.
This patch makes sure that only if the user is logged-in as the admin
and the site is fully installed and up-to-date, the add-on installation
request will be dispatched to the tool_installaddon for actual
processing.
We need to store the installaddonrequest value in the $PAGE's URL so
that is is stored in $SESSION->wantsurl in case the user needs to log in
at their site. Thanks to this, the request is dispatched after the user
logs in.
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.
* added new config option to determine length of courses returned by import
* added text indicator if there are more than X number of courses, similar to how the restore course list currently works
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.
Regex's placeholders can not be repeated, if
there are definitions that have more than one
selector type of the same kind it would not
be displayed like that in the steps definitions
list UI
GD PHP extension is now required. Add-ons need to remove $CFG->gdversion tests. The worst case regression is that add-on will think GD is not available.
As the admin_category::add() method now checks for the third parameter,
couple of typos were detected in the code. Additional parameters passed
to the add() method were probably a mistake, a relict or a typo.
Note that the typo in admin/tool/unsuproles/settings.php had actually
significant impact on the functionality as the array with required
capabilities was not actually passed to the admin_externalpage
constructor as intended.
course, cohort, enrol, role, groups and forum used to use hard-coded
MAX_USERS_PER_PAGE=100 for rendering user list. This has been converted
to $CFG->maxusersperpage.
Data cached in these caches change only at well defined places (during
need for upgrade checks, at the plugin management screen etc). So it
makes sense to use proper application caches instead of request caches.
This saves couple of database queries at almost every page in Moodle.
