1. don't re-call in what app or forum for that app, but it had a script one could download and install in the application, and when the OP would run it the app would generate a systems report ... Operating system, Memory, MySQL version and settings, etc., etc. in a text file. It contained information to be used by someone more technical in trouble shooting an issue.
Now I know there is phpinfo, but haven't seen anything that discloses more info that might pertain to issues. Possible without disclosing sensitive info?
2. During the course backup process, after user selects the options for the backup
and begins the process, a progress bar displays % completed.
Depending upon the size of the course at around 8x+%-9x% it appears to 'hang' ... only
indication might be your browser 'twirlly'. Below a screen shot where progress bar stopped but in terminal session watching the backup process could see where it stopped.
After watching the process via command line, that pause usually occurs in the last step.
The backup file has been created and Moodle is attempting to *copy* the backup to the
location as set in settings for backups.
That's also where it fails with no indication as to the issue to the non-technical user.
Think it would be nice to have right above the progress bar (red box below), what Moodle is doing ...
a single word ... which, when Moodle backup process is working on certain areas of the course
contents, it changes the word ...
activities
quizzes
users
creating backup
copying backup
IF the process dies ... the user will see some indication of where it failed. Granted there might be other issues that would require turning on of debugging, but for the novice/non-techie communicating with techie, think this bit of info would be useful.
IF one sees it stopped at "copying backup" indicator, reporting that to the system administrator
will give them a clue as to where to look/do to resolve the issue.
System Admin might actually be able to recover the backup by inspecting
the moodledata/temp/backup/ directory by moving a .mbz file to another location
and then removing the entire temp backup build directory.
Also ... an observation ...
IF NOT using the new experimental backup, Moodle builds the .mbz files using temporary names:
backup.mbz.SoMeRanDomExt
To finish, Moodle must rename the file and copy it to the desired location.
IF USING the new experimental backup format, Moodle builds the .mbz file (a tar.gz) but this time does
not user a temporary name ... writes to backup.mbz.
Depending on the course contents, one might not get much compression - ie, smaller backups ...
but I do think on a Linux server the whole backup process is more often than not successful.
Just my two cents.
'spirit of sharing', Ken
