Cannot restore a course

Cannot restore a course

by Alan Coats -
Number of replies: 4

Using Moodle v2.6.4 on Windows Server with IIS7, MySQL and php
Logged in as site administrator
Example of course being restored:
https://drive.google.com/file/d/0ByY6oN9kOSHMUjc1OWFRU3FKd0k/edit?usp=sharing

====

Every time I try to restore a course, when you click on the button to actually do the restore Moodle falls over with the following error (this occurs no matter if it is the above mentioned course or one I have just backed up):

Default exception handler: Coding error detected, it must be fixed by a programmer: Cannot call moodle_page::add_body_class after output has been started. Debug: 
Error code: codingerror
* line 1078 of \lib\pagelib.php: coding_exception thrown
* line 7 of \theme\bsdcint\lib.php: call to moodle_page->add_body_class()
* line 465 of \lib\outputlib.php: call to include_once()
* line 385 of \lib\outputlib.php: call to theme_config->__construct()
* line 6943 of \lib\moodlelib.php: call to theme_config::load()
* line 1097 of \backup\util\dbops\restore_dbops.class.php: call to get_list_of_themes()
* line 740 of \backup\moodle2\restore_stepslib.php: call to restore_dbops::create_included_users()
* line 34 of \backup\util\plan\restore_execution_step.class.php: call to restore_create_included_users->define_execution()
* line 181 of \backup\util\plan\base_task.class.php: call to restore_execution_step->execute()
* line 177 of \backup\util\plan\base_plan.class.php: call to base_task->execute()
* line 167 of \backup\util\plan\restore_plan.class.php: call to base_plan->execute()
* line 333 of \backup\controller\restore_controller.class.php: call to restore_plan->execute()
* line 184 of \backup\util\ui\restore_ui.class.php: call to restore_controller->execute_plan()
* line 99 of \backup\restore.php: call to restore_ui->execute()

Potential coding error - existing temptables found when disposing database. Must be dropped!
Can anyone suggest a solution other than up grade to v2.7 or greater?
Average of ratings: -
In reply to Alan Coats

Re: Cannot restore a course

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

There are lots of similar reports. They either refer to problems fixed in earlier versions or have no answers at all. 

My starting point with 'tricky' bugs is...

1. Looks at any optional plugins you have with massive suspicion. Ideally, delete them all and see if the problem goes away. 

2. Upgrade to (at least) the latest version of your branch and hope it's fixed.

Also, have a careful look through your web server's error log. Apart from the report above check for anything logged prior to that that may have 'set up' the problem. 

Average of ratings: Useful (1)
In reply to Alan Coats

Re: Cannot restore a course

by Ken Task -
Picture of Particularly helpful Moodlers

Downloaded your course and restored successfully:

Moodle: 2.6.8 (Build: 20150202) PHP 5.5.21 5.5.37 MySQL CentOS release 5.11

Two things in the error report ...

\theme\bsdcint\lib.php

Could you change the theme of that course and TIA (try it again)?

The other item:

Potential coding error - existing temptables found when disposing database. Must be dropped!

Moodle creates temporary tables during backup/restore processes and if the process fails it is supposed to clean them up *when the DB session ends*.  Most of the time, when/IF I run across something that reports this error, I check tables of the DB but find no temp tables.   However, that is something to check on your system.   Does DB user have all access rights to the DB for Moodle?   Might be the easiest to simply restart the MySQL service.

Also ... check moodledata/temp/backup/

Failed restores will be contained in a hash named folder ... long with charactersnumbers

Inside those folders one will find what Moodle had unzipped from the .mbz file.  The xml files are related to the folders.   files.xml for example, is really a listing of the hash named files found in the 'files' directory.

Check out the moodle_backup.xml file ... that's the roadmap for the restore.

Any folder and their contents found in moodledata/temp/backup/ can be safely/manually removed.  Might want to do that for this failed restore.

Also there are contenthashnamed.log files of larger than 0 bytes which might contain other clues.   Those are text files and can be opened with NotePad.

Other settings ... related to PHP and MySQL - max memory a script can consume, all the max timer settings - depending upon how quickly the restore fails - do you even see the progress bar begin?

Might also consider updating the 2.6.4 to highest in that series 2.6.8 ... some fixes might be in there for this.

There are some changes in 2.7.x that might surprise you and users so do some research on that before moving upwards (not saying you won't eventually have to do that as 2.6 is getting security fixes only now and will soon slide to 'Legacy non-supported'.

'spirit of sharing', Ken

In reply to Ken Task

Re: Cannot restore a course

by Alan Coats -

Many thanks for the replies.

I have tried it with using the 'Bootstrap' theme but it also gave the error

My next step is to try it on a new clean local installation with the same version of Moodle to see if the problem exists there. 

If it does I will try the latest branch of v2.6 to see if that fixes it. 

If the problem does not exist using my current version, then I will add the local plugins one at a time to see if any of them is the cause. If the problem still does not exist, I will have to look at the difference between this test version and the live version.

The reason for not upgrading to v2.7.x or later is I know the themes and some local plugins we use will break the system and all need redeveloping (not a small piece of work) and I need to restore now. Eventually we plan to go to v2.8.x

In reply to Alan Coats

Re: Cannot restore a course

by Alan Coats -

Problem resolved.

It was the BSDCInt theme. Even though the site does not use this theme, Moodle still looks at it when performing an import or restore.

As the theme is not used on the site in question, removing it completely fixed the problem.