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.
This has exactly the same behaviour as the existing
plugintype_name_plural() method, but returns the singular form of the
plugin type (such as 'Activity module').
This new method just takes the result of the core get_plugin_types() and
re-orders the plugin types in the same way as they are displayed at the
Plugins overview screen.
The patch implements the second mode of the mdeploy.php script. If
--install option is passed, the given package is downloaded, verified
and deployed to the requested location.
Previously it was only possible to display the form immediately as
HTML output. You had to wrap in an output buffer in order to put
it in a renderer. This new function does the output buffer for you.
This function used to be in the user selector, but it is useful in
other areas where we want to search for users as it handles a number
of search options (including extra fields, etc.) and returns SQL
which can be included in a joined query.
A unit test has been added to check the results of these searches.
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
