Closed hello-josh closed 9 years ago
Hi, sorry, I'm afraid this is a known issue. To fix it in the database, at a time when you are sure there are no current restores ongoing, delete all rows from mdl_subpage_sections where sectionid > 10000000. (Note: This assumes you have less than that many sections. To double-check you could also include a left join against course_sections and check there isn't one that matches that id.)
What usually causes it is if a previous restore crashes partway through. It can crash if you try to restore the same thing twice at the same time, or else just if something totally unrelated to subpage causes the restore to crash.
I didn't think of a good way to prevent this happening yet. Your script where it restores with a transaction around everything should prevent it from being caused by that restore, though.
I have multiple courses using subpages, will deleting the rows where sectionid > 10000000 mess up current courses or are they renumbered at the end of the restore process?
During normal use (other than restore) the sectionid from mdl_subpage_sections should correspond to an id from the mdl_course_sections table.
It temporarily uses a larger number when restoring to avoid clashes with a database unique index, because it doesn't know the new section number at that point. Then renumbers it.
So you should only have entries with really big numbers if a restore is currently in progress.
Awesome, thanks! That is my issue then, I have a broken restore that corrupted the temporary numbers in the table
We are having a similar issue on one of our old Moodle 2.4 systems :-(
I wonder... We are about to upgrade the entire system to Moodle 2.7 and get an updated subpage plugin from you, Do you think It is fixed in the new plugin version?
Came across this issue again, as we are using it (still) on Moodle 3.1 And once again, @sammarshallou advice helped :smile: (Thank you!)
Sustaining nadavkav. we also had this problem :-(
Good (ish) news - since last comment I made a script called mod/subpage/deletebaddata.php which you can use to automatically delete the bad data without having to manually do it in the database.
You need to call it manually like mod/subpage/deletebaddata.php?iamsure=1&sesskey=whatever (where whatever is your current sesskey) - obviously it is available only to site admin.
The script should be safe to use provided that there is no current ongoing restore operation at the point when you run it.
Sorry we haven't done a better fix! We are still using subpage with Moodle 3.1 as well, but are beginning to phase it out (that said I firmly expect we will still have it for legacy material in 3.2, 3.3, 3.4, and probably a long way into the future).
Thank you @sammarshallou very much for this important update! We will definitely use it, if future issues like these arise again.
I have also recommended (even strongly) phasing out this plugin, but I am not sure how seriously I am taken ;-) as the pedagogical stuff like it a LOT :smile:
I am running into the following error when trying to restore a course that contains subpages:
This happens if I am trying to restore into a new course as well as when trying to restore into an existing course while deleting the prior course content.
This is the script I am running it with now (based off of MOODLE_24_STABLE). Is there a fix for this in a more recent version that I can backport into the 2.4 version?