Backup & restore issue 2.4

[aspark21]

There is an issue with Backup & restore of a course containing subpages.

from the below stack traces it looks like the sectionid in mdl_subpage_sections are kept the same despite being restored as a new course.

The site is on Moodle 2.4.1 & latest stable release of the plugin for 2.4

[sammarshallou]

In general, backup/restore of an entire course containing subpages to a new (not existing) course is supposed to work correctly.

A few things we know about that can cause this type of error:

OU bug 5438: Partial restore (e.g. restore of subpage to an existing course) unfortunately does not always work and can result in this error. Basically it will probably fail if the existing course contains subpages. This is due to limitations in the way subpages are implemented - to do it really 'properly' we would require changes to core code.

OU bug 4950: Sometimes if a restore crashes it can leave invalid entries in the mdl_subpage_sections table. These can break future restores. To fix this problem, you can delete the invalid entries from mdl_subpage_sections. Basically, delete the ones with really big numbers over a million like the examples above, using a query such as (I didn't test this): DELETE FROM mdl_subpage_sections WHERE sectionid > 1000000

[aspark21]

HI Sam,

Thanks for this.

These were caused during full backup & full restore so must be the second option most likely. However, some of the affected courses had not been restored before AFAIK but wouldn't be surprised if content had been imported into the course.

[emdalton]

We are experiencing the same problem on Moodle 2.5 with several courses, and it seems to be getting worse, i.e. more and more courses are being affected. We don't have direct access to the database backend, since we're on a hosted system, so we can't easily take the cleanup steps you recommend above.

We'd like to see Subpages, or a feature like it, added to Moodle Core, especially if that will help its stability. We rely on this plugin to keep our online courses manageable. How can we help get Subpages into core?

[sammarshallou]

emdalton - I had a request in with core to add API features that would make it possible to implement modules like subpage properly without hitting unusual backup/restore issues. Unfortunately they have rejected it as they have a different approach - that course formats should provide this functionality, in other words the feature to add a subpage would be handled within the course format rather than as a module.

https://tracker.moodle.org/browse/MDL-37702

Please see my last comment on that issue. Unfortunately it sounds like we're going to need to redevelop our course format (which isn't public because it contains lots of OU-specific details and only works with our theme, so not really suitable for use anywhere else) in order to incorporate subpage features. That means we may be approaching the end of the line for subpage. (It's still supported in Moodle 2.6 though, and very likely will be in 2.7 too.)

Regarding the problem you're seeing and lack of database access - ugh - could you write a script that does a query like the one I gave and get that put on the servers? Or would it help if I added a script like that into the subpage codebase somewhere? I guess it might be useful for us as well... I don't really want to add it to the MOODLE_25_STABLE version as that would required patching our live servers, but I could potentially stick it in the master (2.6) one..

[emdalton]

Thanks for the quick response! I remember that tracker -- I should, I'm one of the participants.

I disagree with Moodle dev that this should be part of a course format, because course formats provide the ability, for example, to switch between weekly and topic organization. The flextopic format wouldn't allow us to provide automatic dates for sections. I suppose that could be dealt with in some other way, however. I guess we'll have to find out. (I'll also need to find out what happens if someone has subtopics configured and then switches to a different format-- do we need to disable all other formats on our system to use this?)

We are going to need some help getting the database errors out of our system. Our hosting provider may be willing to run the script on the backend, but they'll be happier if it's part of an update to the module. I appreciate your problem with putting changes into the version you're using on your live systems. We won't be able to switch to 2.6 for 3 months. (We have to make updates between terms, and that's our next window.) If the 2.6 version can also run on 2.5, I think that would work for us. Is that possible?

Would the script you suggested (DELETE FROM mdl_subpage_sections WHERE sectionid > 1000000) only catch "bad" subpage sections, or do we need to somehow identify sections that are actually in use? Our new term starts this weekend, so I really can't have faculty having to go in and rescue orphaned content if this wipes out all our existing subpages. :(

Thanks again!

Elizabeth

[sammarshallou]

Hi,

We are not on 2.6 for a couple more months either! However we have a (custom) plugin that lets us run arbitrary database changes on the live database... :)

The only way to find out if the 2.6 version works on 2.5 would be to test it. We haven't done that - you're welcome to try it out if you want. Honestly don't know, we might have changed it to rely on a 2.6 API.

Just for you (well it will be useful here too) I have now coded the script that deletes these bogus entries, this is now in mod/subpage/deletebaddata.php in the current master version on github. Look in the source for that file to see instructions about how to use it.

About the SQL command I suggested - I can't guarantee it is safe, I would recommend looking at your database to see what the IDs are. Normally they are numbered sequentially though so it's unlikely you have more than a million of them unless yours is a very large installation. You could also consider running a more complex SQL command to delete only entries from that table where the 'sectionid' does not match an existing id in the mdl_course_sections table. Look inside the source code for deletebaddata.php if you want to see the SQL I used.

I'm going to close this issue now as there is a solution (of sorts) in the master code now (OU issue 10375) - if you have problems with leftover data in the 10,000,000+ range, run the deletebaddata.php script.