That last thing that I have to change in order for this plug-in to work completely is the backup and restore functions. Moodle has completely overhauled the backup and restore system for 2.x, and I need to rewrite these functions completely.
The main structural differences from 1.9 are pretty obvious. In 1.9, there were two files: "backuplib.php" and "restorelib.php" that were located in the modules main directory. In Moodle 2, these are gone, and in their place is a "backup" subdirectory, with one or more subdirectories supporting possible backup formats. For this purpose, I will focus on the "moodle2" subdirectory, which contains the code necessary to backup and restore in Moodle 2.
First things first, I need to tell Moodle that my module support backup. This is done using a function called stampcoll_supports in the "lib.php" file. This function allows me to more granularly define features that the module may or may not support. Mostly the defaults suffice, but in the case of backup, the default is "does not support".
I add the function and put a line in that indicates the module supports backup. This is what I add:
function stampcoll_supports($feature) {Now, the Moodle backup system knows, and will expect my module to provide backup and restore support code.
switch($feature) {
case FEATURE_BACKUP_MOODLE2: return true;
default: return null;
}
}
Next, I need to create the actual backup code. I create the subdirectory structure "backup/moodle2". The directory can use three files for backup: "backup_[modulename]_settingslib.php", "backup_[modulename]_stepslib.php" and "backup_[modulename]_activity_task.php". I don't actually need "backup_stampcoll_settingslib.php", as I will only be using defaults, but I'll include it for completeness and leave it with no code.
Starting with "backup_stampcoll_stepslib.php" is a good choice. This file allows me to define the data structure of my activity, so that the backup function can understand it. The module only has two tables, so it's fairly easy. (To make it even easier, "borrow" another module's code and change it - I used "/mod/choice").
Now, the "steps" file is really the meat of the whole operation. It defines the data structures and all dependencies. When I'm done, my file has the following code:
protected function define_structure() {
// To know if we are including userinfo
$userinfo = $this->get_setting_value('userinfo');
// Define each element separated
$stampcoll = new backup_nested_element('stampcoll', array('id'), array(
'name', 'intro', 'introformat', 'image',
'timemodified', 'displayzero', 'anonymous'));
$stamps = new backup_nested_element('stamps');
$stamp = new backup_nested_element('stamp', array('id'), array(
'userid', 'giver', 'text', 'timemodified'));
// Build the tree
$stampcoll->add_child($stamps);
$stamps->add_child($stamp);
// Define sources
$stampcoll->set_source_table('stampcoll', array('id' => backup::VAR_ACTIVITYID));
// All the rest of elements only happen if we are including user info
if ($userinfo) {
$stamp->set_source_table('stampcoll_stamps', array('stampcollid' => '../../id'));
}
// Define id annotations
$stamp->annotate_ids('user', 'userid');
$stamp->annotate_ids('user', 'giver');
// Define file annotations
$stampcoll->annotate_files('mod_stampcoll', 'intro', null); // This file area hasn't itemid
// Return the root element (stampcoll), wrapped into standard activity structure
return $this->prepare_activity_structure($stampcoll);
}
The backup_nested_element objects define the XML data structure of my backup. Essentially it contains all of the necessary data. The id fields of data that will be created new are not included, since they will be discarded anyway. When there are multiple records per activity, like there is with "stamps", we create two XML levels: one for the type (stamps) and then one for each actual record (stamp). The add_child function creates the actual XML tree structure. I use set_source_table to define where the data comes from and the main key used to access it. Note that I only bother defining the "stamps" table if the backup is storing user information.
Lastly, the annotate_ids function tells the backup system to remember specific data identifiers that may change when restored. The first argument is the type of Moodle variable, and the second is the identifier I specified in my definitions (see http://docs.moodle.org/dev/Backup_2.0_for_developers#annotate_is_important for all variable types). In this case, both are user identifiers: one for the user receiving the stamp and one for the user giving the stamp.
Then, I create "backup_stampcoll_activity_task.php". This is the main file of the backup process, uses the other two files and calls all the specific steps. This is a pretty standard file, and all I really need to do is change all of the "choice" strings (from the module I borrowed from) to "stampcoll" strings. I'm not including the code here, but you can get it from the git repo.
That should give me all I need to successfully backup. When I run it in a test course, I now see my module as an option to backup, and when I execute the backup, it is successful. Unfortunately I can't verify it without the restore code.
Again, borrowing from the "choice" module, I create my "restore_stampcoll_stepslib.php" file. This is pretty much a search-and-replace of the "choice" string for the "stampcoll" string again. But I do need to spend a little bit more effort in the process_stampcoll and process_stampcoll_stamp functions:
Essentially, I just add the apply_date_offset function to the only time fields I have. And I use the get_mappingid function to get the correct user id's for the two user fields in the "stamp" table. That's pretty much it.protected function process_stampcoll($data) {
global $DB;
$data = (object)$data;
$oldid = $data->id;
$data->course = $this->get_courseid();
$data->timemodified = $this->apply_date_offset($data->timemodified);
// insert the stampcoll record
$newitemid = $DB->insert_record('stampcoll', $data);
// immediately after inserting "activity" record, call this
$this->apply_activity_instance($newitemid);
}
protected function process_stampcoll_stamp($data) {
global $DB;
$data = (object)$data;
$oldid = $data->id;
$data->stampcollid = $this->get_new_parentid('stampcoll');
$data->userid = $this->get_mappingid('user', $data->userid);
$data->giver = $this->get_mappingid('user', $data->giver);
$data->timemodified = $this->apply_date_offset($data->timemodified);
$newitemid = $DB->insert_record('stampcoll_stamps', $data);
// No need to save this mapping as far as nothing depend on it
// (child paths, file areas nor links decoder)
}
The "restore_stampcoll_activity_task.php" file is similarly a search-and-replace task, with the exception of the define_restore_log_rules function. I need to modify the rules variable to only return logs that my module creates:
static public function define_restore_log_rules() {Now that I have my restore code, I can apply it to the backup I made and verify the function. I run the restore and achieve success!
$rules = array();
$rules[] = new restore_log_rule('stampcoll', 'add', 'view.php?id={course_module}', '{stampcoll}');
$rules[] = new restore_log_rule('stampcoll', 'update', 'view.php?id={course_module}', '{stampcoll}');
$rules[] = new restore_log_rule('stampcoll', 'view', 'view.php?id={course_module}', '{stampcoll}');
$rules[] = new restore_log_rule('stampcoll', 'update stamp', 'editstamps.php?id={course_module}', '{stampcoll}');
$rules[] = new restore_log_rule('stampcoll', 'delete stamp', 'editstamps.php?id={course_module}', '{stampcoll}');
return $rules;
}
I kind of rushed through this, and didn't touch on everything, so I encourage you to really read the backup documentation. It is very thorough.
This concludes my postings on module migration from Moodle 1.9 to Moodle 2.1. Please feel free to post comments and make suggestions.
