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
1. There is a new admin setting to control whether this feature is
enabled. The admin can set the auto-save frequency to 1, 2 or 5 minutes,
or disable it.
2. When autosave is enabled, there is code in the quiz that monitors the
main quiz form, and does an ajax save call at the given frequency when
changes are being made by the student.
3. The ajax saves go to a new script that calls the question engine to
do the work.
4. To avoid simultaneous autosave + submit and finish, the auto-save
system shuts down shortly before time expires in a timed quiz.
1. Autosave works in some ways just like a normal save. We ultimately
call $behaviour->process_save() to do the work, and create a new step to
hold the data.
2. However, we come in through a completely different route through the
API, starting with separate auto-save methods. This keeps the auto-save
changes mostly separate, and so reduced the chance of breaking existing
working code.
3. When the time comes to store the auto-save step in the database, we
save it using a negative sequence number.
This is a clever trick that not only distinguises these steps, but also
avoids unique key errors when an auto-save and a real action happen
simultaneously. (There are unit tests for these tricky edge cases.)
4. When we load the data back from the database, most of the time the
auto-save steps are loaded back as if they were a real save, and so the
auto-saved data is used when the question is then rendered.
5. However, before we process another action, we remove the auto-saved
step, so it does not appear in the final history.
1. Split the question_attempt tests into one class per file.
2. Imporve the API to give tests more control, and to test more of the
important code. Some of this is not used here, but it is about to be.
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.
