Automated restore creating duplicate assignments etc.

Automated restore creating duplicate assignments etc.

by Pete Frost -
Number of replies: 1

Hi all,

  I've been tasked with creating some PHP code that will automatically restore a course (which still exists) from an earlier backup. The backup is stored in moodle2 format, untar'd. It's then put into a temporary directory before the restore controller is executed. Here's the code that executes the controller:

$transaction = $DB->start_delegated_transaction();
try {
    // Define the import.
    $controller = new \restore_controller(
        $tempdir,
        $this->courseid,
        \backup::INTERACTIVE_NO,
        \backup::MODE_GENERAL,
        get_admin()->id,
        \backup::TARGET_CURRENT_DELETING
    );
    // check whether restore might work
    $controller->execute_precheck();
    // Run the import.
    $controller->execute_plan();
    // commit changes to database
    $transaction->allow_commit();

The intention is for the restored course contents to completely replace whatever's currently in the course. However, what actually seems to happen is that the restored assignments etc. are appended to the course (so whatever was in the course before the restore was done is still there). Judging by the contents of the Moodle database table (mdl_assign), the restored assignments are being given a new id and the old ones are being left in the table.

I derived the controller parameters by looking at what parameters are passed to the controller when I manually do a restore via the Moodle web interface, so I'd expect them to be correct, but perhaps they're not. My script is being run via CLI rather than via the web but I can't see why that would make any difference.

Can anyone spot what I'm doing wrong? We're running Moodle 3.1. Here's the debug output that appears in my terminal:


instantiating restore controller bccddfa7443a49163c0690de7b1828e2
setting controller status to 100
loading backup info
loading controller plan
setting controller status to 300
checking plan security
setting controller status to 600
saving controller to db
calculating controller checksum dac228e0057a2c01530031990df38738
loading controller from db
setting controller status to 700
saving controller to db
calculating controller checksum adfbb68305e6df83c3df47aef6afb075
loading controller from db
setting controller status to 800
processing file aliases queue
setting controller status to 1000
saving controller to db


Average of ratings: -
In reply to Pete Frost

Re: Automated restore creating duplicate assignments etc.

by Pete Frost -

I've managed to fix this. It turns out that the restore_controller class doesn't actually do any deleting for you (as far as I can tell), despite accepting a target parameter (TARGET_CURRENT_DELETING) which seem to imply that it will.

The Moodle web interface calls the following static method before it triggers the restore controller:

restore_dbops::delete_course_content($courseid);

Once I added that to my code, it started working as expected. I ended up with:

$transaction = $DB->start_delegated_transaction();
try {
    restore_dbops::delete_course_content($this->courseid);

    // Define the import.
    $controller = new \restore_controller(
        $tempdir,
        $this->courseid,
        \backup::INTERACTIVE_NO,
        \backup::MODE_GENERAL,
        get_admin()->id,
        \backup::TARGET_CURRENT_DELETING
    );
    // check whether restore might work
    $controller->execute_precheck();
    // Run the import.
    $controller->execute_plan();
    // commit changes to database
    $transaction->allow_commit();
} catch(\moodle_exception $e) {
    $transaction->rollback($e);
} f



Average of ratings: Useful (1)