This lets plugins other than activity modules backup and restore
question attempt data.
The old backup_questions_activity_structure_step and
restore_questions_activity_structure_step base classes still exist
and work exactly the same way they did before (because they use the
trait) so this change is completely backwards compatible.
To make this work fully, a few other things in the code had to be tweaked:
* Adding restore path elements had to consider the possibility of grouped
parents in more places.
* I needed to add protected get_task() to the restore_plugin class.
I don't think that is a problem.
* In the restore trait, the process_question_... methods needed to be
changed to public for some reasons to do with PHP traits that I don't
fully understand. However, I don't think this change is a problem.
* The way question_usage restore got the new contextid had to be changed
(or it did not work in activity contexts), but the new code looks like
a better way to do it anyway so that is good.
The new setting will allow to host the temporary backup files
into a specific target directory. Defaults to '$CFG->tempdir/backup'.
Calling make_backup_temp_directory() checks that the required sub-directory
will be properly created under the new target directory.
- Uses site generated (on backup) key.
- Can be applied potentially everywhere in the restore process.
- Covered with unit tests.
- Authentication / integrity aware so can be used between any 2 servers
(just requires matching key).
It was decided to roll only configuration dates and any date related to user content
such as 'timecreated' , 'timemodified' etc should not be rolled forward.
Now backup and restore operations free logger resources calling
to the destroy() method. This commit ensures:
1) That gc_collect_cycles() is not used anymore in backup-related tests.
2) That all backup and restore controllers in test do always call
to the detroy() method.
3) Some unset() calls, needed to make gc_collect_cycles() are not used
anymore.
In order to implement the backup and restore of log stores, that
are created as subplugins of the tool_log plugin , we need to
extend subplugins support from activities to virtually any plugin.
Basically that implies moving the add_subplugin_structure() method from
its current, restricted, activity level to general restore_structure_step.
This commit implements the change in restore, covered with tests verifying
old, bc behavior and also new, general one.
In order to implement the backup and restore of log stores, that
are created as subplugins of the tool_log plugin , we need to
extend subplugins support from activities to virtually any plugin.
Basically that implies moving the add_subplugin_structure() method from
its current, restricted, activity level to general backup_structure_step.
This commit implements the change in backup, covered with tests verifying
old, bc behavior and also new, general one.
1. Changes progress bar code to allow headings for progress bar (so users have
some clue what's going on if a page has more than one progress bar).
2. Changes restore code so that a progress bar can display during pre-checks if
they take longer than 5 seconds.
3. Changes pre-check and restore code so that, in various points where the system
can take a long time within an individual step, intederminate progress is
indicated and it won't time out.
Adds calls to the new backup progress tracking API within various steps of the
backup system - previously it only tracked progress between steps, but some steps
can themselves be slow. This ensures the system displays progress (either by
moving the progress bar if possible, or by making the wibbler below it pulsate)
during nearly all of the backup process.
Includes option to convert all enrolments to enrol_manual instances, support for mapping of custom fields and fixes for several other problems. This does not include support for custom enrol tables, it will be addressed in another issue.
At present core restore steps cannot have an after_restore function,
even though plugin restore steps can. Technically it would be possible
to just override the launch_after_restore_methods function but this
is not very neat. Instead, I added code to call after_restore function
(exactly the same way after_execute works).
