Fix condition where if an asynchronous backup
completes via the UI and the user refreshes the
page a new backup was created with a mismatched
backup id.
This caused a permanently failing ad-hoc task
and blocked further backups for that course.
Allow both UI and automated backups to be created without
including files. Instead include only file references.
This is essentially implementing "SAMESITE" to backup files
instead of only for import and export functionality.
A new backup setting to include files (defaults to yes)
has been included.
The restore process will also look for and attempt to
restore files from the trashdir as part of restoring
backups. Additionally to support this process the
ammount of time files are kept in trashdir before they
are cleaned up via cron is also adjustable via admin
setting.
This patch adds asynchronous backup and restore functionality
to Moodle. This is an optional feature and is not enabled by
default. It can be enabled by site administrators.
Asynchronous backup and restores are actioned by the Moodle
adhoc task API. The progress of backup and restores is
displayedin the Moodle UI. Users can also be sent a message
when a backup or restore operation completes via the
Moodle messaging API.
This commit contains three changes in the three files:
1. A bug in the backup process meant that anything logged after a
certain point did not appear in the on-screen display of the
backup log, because the logger was serialised and deserialised
but display code referred to the old version. Changed so that
code retrieves new object.
2. Add more information to backup log when there is a missing file.
3. Add more information to restore log when there is a missing file
(and remove existing code duplication of the current message).
The 'missing file' situation is one that generally shouldn't occur in
normal usage, but when it does happen, it is useful to have full
information about the file.
When doing a backup or restore operation with the normal user interface,
if there is anything in the backup/restore log, it will now be displayed
at the end of the process below the Continue button.
If you have developer debugging enabled, it sets the display level to
LOG_DEBUG and there will always be content in the log. Otherwise, it
uses LOG_INFO which generally means the log is empty, and nothing
displays (no visible change for users).
Adds 'Preparing page display' progress bars for user interface pages
if they take a long time to display.
Also adds changes where other parts of the backup progress timed out on
long backups. After this change, and MDL-41838, it is finally possible on
my dev server to successfully back up the 'XL' test course.
It was not previously possible to have a section called 0 because of
bugs in the standard course formats, but we hit this with the OU course
format. You got an exception because backup settings tested to see if
their lable was empty, which means a section name of '0' was fatal.
Should work now.
* backup moodleforms for specific stages are now cached between stage processing and display making it possible to leave all validation up to the bridge.
* The backup stage now relies entirely on the backup controllers save, load, and check methods + dependency checks rather then previous stage processing to ensure accuracy.
* filename is now a required field and validated to ensure it ends with .zip and is a valid filename.
* There is now a previous button for backup stages after the initial and before the complete.
* The progress bar previous stages are now links as well allowing the user to jump to previous stages (not linked on complete of course).
* The root settings are only shown on the schema stage now if they were changed because of dependency.
* Stages are now numbered in the progress bar.
* The complete page now shows a notice that the backup was complete and provides a continue button to view the backup file.
* Adds administration blocks to the backup pages.
