Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Backup API: Difference between revisions

From MoodleDocs
m (API of the activity backup structure step class)
(Fixed documentation of a return value)
Line 42: Line 42:
* Set data sources for the elements, using their methods like <code>set_source_table()</code> or <code>set_source_sql()</code>
* Set data sources for the elements, using their methods like <code>set_source_table()</code> or <code>set_source_sql()</code>


The method must return the root backup_nested_element instance.
The method must return the root backup_nested_element instance processed by the <code>prepare_activity_structure()</code> method (which just wraps your structures with a common envelope).


== API for blocks ==
== API for blocks ==

Revision as of 03:17, 24 January 2012

Moodle 2.0

The Backup API provides a way to include your plugin's in the course backup. See Restore API for the part that takes care of restoring data.

Overview

This page provides just a quick reference to the backup machinery in Moodle 2.0 and higher. There is a detailed documentation available at Backup 2.0 page - see especially the tutorial for plugin authors at Backup 2.0 for developers page.

Moodle creates backups of courses or their parts by executing so called backup plan. The backup plan consists of a set of backup tasks and finally each backup task consists of one or more backup steps. You as the developer of a plugin will have to implement one backup task that deals with your plugin data. Most plugins have their backup tasks consisting of a single backup step - the one that creates the XML file with data from your plugin's tables. Some activities may need two or more steps to finish their backup task though (for example the backup task of the Quiz module consists of three steps as it needs to write not just the Quiz setting itself but also the questions used by that particular quiz).

There are subtle differences in how the backup code is organised in various supported plugin types (activity modules, blocks, themes, course reports).

API for activity modules

Files

The files that implement the backup support in your activity module must be located in the subdirectory backup/moodle2/ in your plugin's folder. So, if you are developing the activity module called foobar then the backup files will be located in mod/foobar/backup/moodle2/ folder.

The following two files are supposed to exist in that location (replace foobar with the name of your module):

backup_foobar_activity_task.class.php
Provides the activity task class
backup_foobar_stepslib.php
Provides all the backup steps classes

If your module declares its own backup setting (apart from the ones common for all activity modules provided by the core), you will also want to create the backup_foobar_settingslib.php file to provide the setting classes. However most modules do not need this feature.

Backup task class

The file backup_foobar_activity_task.class.php must provide a single class called backup_foobar_activity_task. All activity tasks extend the backup_activity_task class.

There are three methods that your class must define.

protected function define_my_settings()
If your module declares own backup settings defined in the file backup_foobar_settingslib.php, add them here. Most modules just leave the method body empty.
protected function define_my_steps()
This method typically consists of one or more $this->add_step() calls. This is the place where you define the task as a sequence of steps to execute.
static public function encode_content_links($content)
The current instance of the activity may be referenced from other places in the course by URLs like http://my.moodle.site/mod/foobar/view.php?id=42 Obviously, such URLs are not valid any more once the course is restored elsewhere. For this reason the backup file does not store the original URLs but encodes them into a transportable form. During the restore, the reverse process is applied and the encoded URLs are replaced with the new ones valid for the target site.

Backup structure step class

The classes that represent the backup steps added in define_my_steps() are implemented in the file backup_foobar_stepslib.php. Most plugins define just a single step in the class called backup_foobar_activity_structure_step that extends the backup_activity_structure_step class. This class defines the structure step - that is the step where the structure of your plugin's instance data is described and linked with the data sources.

You have to implement a single method protected function define_structure() in this class class. There are three main things that the methods must do.

  • Create a set of backup_nested_element instances that described the required data of your plugin
  • Connect these instances into a hierarchy using their add_child() method
  • Set data sources for the elements, using their methods like set_source_table() or set_source_sql()

The method must return the root backup_nested_element instance processed by the prepare_activity_structure() method (which just wraps your structures with a common envelope).

API for blocks

API for themes

See Backup 2.0 theme data

API for reports

See Backup 2.0 course report data