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.
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.
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.
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).
after this change any restore_structure_step processor
method is able to instruct the dispatcher about to skip
any path below it. Until now, we were doing the checks on
each child processor method, but that was inneficient and
prone to errors (easy to miss the check in a child so some
orphaned piezes of restore may be causing mess here and there).
Once implemented, it's simlpy a matter of the parent deciding if
all its children must be processed or no. Easier for developers
and also small speed improvement because avoids unnecesary
dispatching/processing to happen.
Surely only will be used in parts of core, like in question_categories,
saving 50-60 sub processors (sub-paths) to be dispatched.
Tim Hunt