Here is some additional information. Since the code is expecting files to exist in the /temp/backup/<backup folder name> folder, I found the backup in the Moodle file system, copied it to desktop, changed file extension to .zip, then unzipped to that folder. Then I executed the script again. This time, it hit all my good debug output messages. But there was a lot of errors showing up related to this or that object or event saying that get_objectid_mapping() is missing. Quite a lot of Moodle objects are lacking that override. This comes in to play because of restoring in a non-interactive (CLI) mode and the backup having contained user data. I first tried this without having user data in the backup and the same test failed saying users.xml was missing. Well yeah, it's missing in the backups we normally do. Because we aren't backing up the users for new course creations. Anyway, so I had made another backup with the users backed up too to get past that exception and then ran into this long list of messages like the following in my output log file for the CLI script:
++ In order to restore course logs accurately the event "tool_recyclebin\event\course_bin_item_created" must define the function get_objectid_mapping(). ++ * line 550 of \lib\classes\event\base.php: call to debugging() * line 100 of \admin\tool\log\backup\moodle2\restore_tool_log_logstore_subplugin.class.php: call to core\event\base::get_objectid_mapping() * line 63 of \admin\tool\log\store\standard\backup\moodle2\restore_logstore_standard_subplugin.class.php: call to restore_tool_log_logstore_subplugin->process_log() * line 137 of \backup\util\plan\restore_structure_step.class.php: call to restore_logstore_standard_subplugin->process_logstore_standard_log() * line 112 of \backup\util\helper\restore_structure_parser_processor.class.php: call to restore_structure_step->process() * line 178 of \backup\util\xml\parser\processors\grouped_parser_processor.class.php: call to restore_structure_parser_processor->dispatch_chunk() * line 100 of \backup\util\helper\restore_structure_parser_processor.class.php: call to grouped_parser_processor->postprocess_chunk() * line 148 of \backup\util\xml\parser\processors\simplified_parser_processor.class.php: call to restore_structure_parser_processor->postprocess_chunk() * line 92 of \backup\util\xml\parser\processors\progressive_parser_processor.class.php: call to simplified_parser_processor->process_chunk() * line 190 of \backup\util\xml\parser\progressive_parser.class.php: call to progressive_parser_processor->receive_chunk() * line 278 of \backup\util\xml\parser\progressive_parser.class.php: call to progressive_parser->publish() * line ? of unknownfile: call to progressive_parser->end_tag() * line 179 of \backup\util\xml\parser\progressive_parser.class.php: call to xml_parse() * line 158 of \backup\util\xml\parser\progressive_parser.class.php: call to progressive_parser->parse() * line 110 of \backup\util\plan\restore_structure_step.class.php: call to progressive_parser->process() * line 181 of \backup\util\plan\base_task.class.php: call to restore_structure_step->execute() * line 178 of \backup\util\plan\base_plan.class.php: call to base_task->execute() * line 168 of \backup\util\plan\restore_plan.class.php: call to base_plan->execute() * line 343 of \backup\controller\restore_controller.class.php: call to restore_plan->execute() * line 296 of C:\applications\diamondd\BackupCourseAndRestoreToAlternateCourse.php: call to restore_controller->execute_plan() * line 43 of C:\applications\diamondd\BackupCourseAndRestoreToAlternateCourse.php: call to restoreTest()
There are so many of these occurrences in my log output file, I am only including a random one.
After the successful restore, the course content was not emptied from the original template course, and the new course content was simply appended to the end of each section in the course. Even though I used the appropriate parameter when instantiating the restore_controller object. This is how I was creating the controller:
$controller = new restore_controller($backupdir, $course_destination_id, backup::INTERACTIVE_NO, backup::MODE_SAMESITE, $USER_ID, backup::TARGET_CURRENT_DELETING);
So my question is ultimately, why is the folder that is created in the <moodledata>/temp/backup/<foldername> path empty? That seems to be the kicker, why I am having this issue. That folder is created when you instantiate a restore_controller object. But there are no places found in the code where that backup file is unzipped to that folder. So, how come a backup that is just created doesn't have that folder already created? I have to unzip the file there manually in order for the restore to work. My other script that creates new term courses doesn't experience the same problems. That is what I find interesting. The only difference between that script and this one is that the script that works is backing up a template course, making a new course (empty), then restoring from that template backup into the new course. The one that doesn't work is making a backup of a term course, then restoring into a template course. The script that works doesn't have any code in it to unzip the backup file. What am I missing?