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.
sam marshall