Development:Backup 2.0 for developers - Revision history

Stronk7: /* Other components that can be backed up */

2011-04-26T10:04:09Z

Other components that can be backed up

← Older revision		Revision as of 10:04, 26 April 2011
Line 442:		Line 442:
	* Course formats		* Course formats
	* Themes: [[Development: Backup 2.0 theme data\| Backup 2.0 theme data]]		* Themes: [[Development: Backup 2.0 theme data\| Backup 2.0 theme data]]
			* Plagiarism plugins

Quen at 11:46, 8 March 2011

2011-03-08T11:46:03Z

← Older revision		Revision as of 11:46, 8 March 2011
Line 435:		Line 435:
	* Also, as stated at the beginning of this tutorial, we are still missing "subplugins" final support in modules, so try to avoid implementing backup on them for now. Once ready, there will be one new section in this document about them.		* Also, as stated at the beginning of this tutorial, we are still missing "subplugins" final support in modules, so try to avoid implementing backup on them for now. Once ready, there will be one new section in this document about them.
	* Any question / improvement / comment, feel free to contact with Moodle HQ, better if using the Tracker or, alternatively, forums / email / direct contact with your very-best-developer-friend. Note this is version x.0 (dot zero) of the backup API, so sure there are possibilities to improve it along the time.		* Any question / improvement / comment, feel free to contact with Moodle HQ, better if using the Tracker or, alternatively, forums / email / direct contact with your very-best-developer-friend. Note this is version x.0 (dot zero) of the backup API, so sure there are possibilities to improve it along the time.

			== Other components that can be backed up ==

			Most plugins which can be added to a course can also include data in a course backup. Some examples:

			* Course formats
			* Themes: [[Development: Backup 2.0 theme data\| Backup 2.0 theme data]]

Stronk7: /* Annotating files */

2010-12-09T13:34:41Z

Annotating files

← Older revision		Revision as of 13:34, 9 December 2010
Line 384:		Line 384:
	</code>		</code>

	That means that, within the $choice element we have one file area in use, of course belonging to the 'mod_choice' component (where all the choice files belong to), named 'intro' and not using itemid (null). Note that, as far as it is possible to have multiple file areas in the same element (table), you may end having multiple calls to that method, one for each filearea to be added to backup. About the third parameter, in case we need it, it must be the name of one of the attributes or fields of the $choice element (usually, in the vast majority of cases, the 'id' of the element), otherwise we'll use null.		That means that, within the $choice element we have one file area in use, of course belonging to the 'mod_choice' component (where all the choice module files belong to), named 'intro' and not using itemid (null). Note that, as far as it is possible to have multiple file areas in the same element (table), you may end having multiple calls to that method, one for each filearea to be added to backup. About the third parameter, in case we need it, it must be the name of one of the attributes or fields of the $choice element (usually, in the vast majority of cases, the 'id' of the element), otherwise we'll use null.

	=== One encoded wor(l)d ===		=== One encoded wor(l)d ===

Stronk7: /* Annotating files */

2010-12-09T13:34:17Z

Annotating files

← Older revision		Revision as of 13:34, 9 December 2010
Line 381:		Line 381:

	<code php>		<code php>
	$choice->annotate_files~~(array~~('~~choice_intro~~'), null); // This file area hasn't itemid		$choice->annotate_files('mod_choice', 'intro', null); // This file area hasn't itemid
	</code>		</code>

	That means that, within the $choice element we have one file area in use, named '~~choice_intro~~' and not using itemid (null). Note that, as far as it is possible to have multiple file areas in the same element (table), ~~the first parameter is~~ one ~~array~~. About the ~~second~~, in case we need it, it must be the name of one of the attributes or fields of the $choice element (usually, in the vast majority of cases, the 'id' of the element).		That means that, within the $choice element we have one file area in use, of course belonging to the 'mod_choice' component (where all the choice files belong to), named 'intro' and not using itemid (null). Note that, as far as it is possible to have multiple file areas in the same element (table), you may end having multiple calls to that method, one for each filearea to be added to backup. About the third parameter, in case we need it, it must be the name of one of the attributes or fields of the $choice element (usually, in the vast majority of cases, the 'id' of the element), otherwise we'll use null.

	=== One encoded wor(l)d ===		=== One encoded wor(l)d ===

Stronk7: /* Defining the sources */ Small change in API

2010-07-07T22:57:42Z

Defining the sources: Small change in API

← Older revision		Revision as of 22:57, 7 July 2010
Line 360:		Line 360:
	* '''../some/path/to/parent''': To manually point to other value of any parent.		* '''../some/path/to/parent''': To manually point to other value of any parent.

	Is important to note that, in 99% of the case we should be using, exclusively, some of the constants above, and backup, automatically will handle them properly. In case we have any other condition or param to be added like, for example, the number 23, or the string 'user', we cannot add them directly, but enclose them with the helper ~~$this->~~is_sqlparam(23) or ~~$this->~~is_sqlparam('user'). That way backup will know they are raw SQL params not needing any special handling, like the constants above.		Is important to note that, in 99% of the case we should be using, exclusively, some of the constants above, and backup, automatically will handle them properly. In case we have any other condition or param to be added like, for example, the number 23, or the string 'user', we cannot add them directly, but enclose them with the helper '''backup_helper::is_sqlparam(23)''' or '''backup_helper::is_sqlparam('user')'''. That way backup will know they are raw SQL params not needing any special handling, like the constants above.

	Well, now it's time to run backup again and take a look to our activities/choice_XX/choice.xml file. Now everything should be there, properly nested, the choice, the options and the answers. We are really near finishing now.		Well, now it's time to run backup again and take a look to our activities/choice_XX/choice.xml file. Now everything should be there, properly nested, the choice, the options and the answers. We are really near finishing now.

Stronk7: /* Settings, Steps and Tasks */

2010-05-06T07:56:30Z

Settings, Steps and Tasks

← Older revision		Revision as of 07:56, 6 May 2010
Line 166:		Line 166:
	</code>		</code>

	Looks simple, isn't it? Nothing but a few comments. This is looking really easy. For now, we aren't going to introduce any custom setting for any module, only the "core activity settings" will be used. Once backup and Moodle 2.0 is stable we can start analyzing useful settings to customize how the module's backup is performed. For now, just leave it blank, please.		Looks simple, isn't it? Nothing but a few comments. This is looking really easy. For now, we aren't going to introduce any custom setting for any module, only the "core activity settings" will be used. Once backup and Moodle 2.0 is stable we can start analyzing useful settings to customize how the module's backup is performed. For now, just leave it blank, please. In fact, if it's empty,''' you can safely not create it''' at all. It's here just for explanation purposes.

	Side note: To save some space, we only will be showing the © message/license in the code above. Just add it to each file created.		Side note: To save some space, we only will be showing the © message/license in the code above. Just add it to each file created.

Stronk7: x, the unknown version... lol.

2010-04-30T10:11:57Z

x, the unknown version... lol.

← Older revision		Revision as of 10:11, 30 April 2010
Line 434:		Line 434:
	* Right now there are some pending tasks related with different exceptions that will be thrown if you code something wrongly (bad nesting, incorrect field names, bad constant/sql param uses...) and how they are shown. Fix for that will be coming soon.		* Right now there are some pending tasks related with different exceptions that will be thrown if you code something wrongly (bad nesting, incorrect field names, bad constant/sql param uses...) and how they are shown. Fix for that will be coming soon.
	* Also, as stated at the beginning of this tutorial, we are still missing "subplugins" final support in modules, so try to avoid implementing backup on them for now. Once ready, there will be one new section in this document about them.		* Also, as stated at the beginning of this tutorial, we are still missing "subplugins" final support in modules, so try to avoid implementing backup on them for now. Once ready, there will be one new section in this document about them.
	* Any question / improvement / comment, feel free to contact with Moodle HQ, better if using the Tracker or, alternatively, forums / email / direct contact with your very-best-developer-friend. Note this is version 1.0 of the backup API, so sure there are possibilities to improve it along the time.		* Any question / improvement / comment, feel free to contact with Moodle HQ, better if using the Tracker or, alternatively, forums / email / direct contact with your very-best-developer-friend. Note this is version x.0 (dot zero) of the backup API, so sure there are possibilities to improve it along the time.

Stronk7: /* Annotating IDs */

2010-04-30T10:07:23Z

Annotating IDs

← Older revision		Revision as of 10:07, 30 April 2010
Line 374:		Line 374:
	It simply means, annotate for each $answer element, the value of the 'userid' field as one 'user' to be backup. In other words we are instructing backup that there is one new user to include later, when generating the users information and, at the same time, we are determining that those users are needed for the choice XX, so, if on restore we decide to skip that choice and such user isn't necessary for any other module / subsystem, it won't be restored. All this "uses" information is handled by the "inforef.xml" files within each activity backup, just in case you're interested to take a look to them. Else, just consider them, "dark magic".		It simply means, annotate for each $answer element, the value of the 'userid' field as one 'user' to be backup. In other words we are instructing backup that there is one new user to include later, when generating the users information and, at the same time, we are determining that those users are needed for the choice XX, so, if on restore we decide to skip that choice and such user isn't necessary for any other module / subsystem, it won't be restored. All this "uses" information is handled by the "inforef.xml" files within each activity backup, just in case you're interested to take a look to them. Else, just consider them, "dark magic".

	'''Note''': If you're not sure about which elements must be annotated, review [[Development:Backup 2.0 for developers #annotate_is_important\|"Annotating some important bits"]] for details about '''must-be-done''' annotations.		'''Note''': If you're not sure about which elements must be annotated, review [[Development:Backup 2.0 for developers #annotate_is_important\|"Annotating some important bits"]] above for details about '''must-be-done''' annotations.

	===== Annotating files =====		===== Annotating files =====

Stronk7: /* Annotating IDs */

2010-04-30T10:06:58Z

Annotating IDs

← Older revision		Revision as of 10:06, 30 April 2010
Line 373:		Line 373:

	It simply means, annotate for each $answer element, the value of the 'userid' field as one 'user' to be backup. In other words we are instructing backup that there is one new user to include later, when generating the users information and, at the same time, we are determining that those users are needed for the choice XX, so, if on restore we decide to skip that choice and such user isn't necessary for any other module / subsystem, it won't be restored. All this "uses" information is handled by the "inforef.xml" files within each activity backup, just in case you're interested to take a look to them. Else, just consider them, "dark magic".		It simply means, annotate for each $answer element, the value of the 'userid' field as one 'user' to be backup. In other words we are instructing backup that there is one new user to include later, when generating the users information and, at the same time, we are determining that those users are needed for the choice XX, so, if on restore we decide to skip that choice and such user isn't necessary for any other module / subsystem, it won't be restored. All this "uses" information is handled by the "inforef.xml" files within each activity backup, just in case you're interested to take a look to them. Else, just consider them, "dark magic".

			'''Note''': If you're not sure about which elements must be annotated, review [[Development:Backup 2.0 for developers #annotate_is_important\|"Annotating some important bits"]] for details about '''must-be-done''' annotations.

	===== Annotating files =====		===== Annotating files =====

Stronk7: added anchor to the annotate ids

2010-04-30T10:03:56Z

added anchor to the annotate ids

← Older revision		Revision as of 10:03, 30 April 2010
Line 70:		Line 70:
	* '''Detecting file areas used by the module''': Along the module we can be using various file areas in different elements and fields. We need to know exactly which file area is handled by which element and the (optional) itemid information used for that file area. In general, '''anything being one text field, or anything looking like one attachment''' has high chances to have one (hidden) file area associated. In our schema, we have one file area detected (choice_intro) corresponding to the introduction of the module and available to put any images or whatever in that field. Also, in general, all the "xxx_intro" file areas use to have no itemid, as far as the module's context is enough to define them without ambiguities. So, we mark the choice->intro as "choice_intro" file area and "no itemid"). From our expertise playing with the module we know there aren't more file areas at all.		* '''Detecting file areas used by the module''': Along the module we can be using various file areas in different elements and fields. We need to know exactly which file area is handled by which element and the (optional) itemid information used for that file area. In general, '''anything being one text field, or anything looking like one attachment''' has high chances to have one (hidden) file area associated. In our schema, we have one file area detected (choice_intro) corresponding to the introduction of the module and available to put any images or whatever in that field. Also, in general, all the "xxx_intro" file areas use to have no itemid, as far as the module's context is enough to define them without ambiguities. So, we mark the choice->intro as "choice_intro" file area and "no itemid"). From our expertise playing with the module we know there aren't more file areas at all.

	* '''Annotating some important bits''': Due to the modularity of the backup and in order to know exactly which information must be saved (because it's used) and which one can be skipped, '''it's important to annotate some important elements along the whole backup''' process. So, back to our schema, we have marked the "choice_answer->userid" field as "annotation" (so backup will, automatically, add all the information for that user). Here it's the list of elements that we must not forget to annotate (or we could end with non-restorable backups). Note that we must, always, be annotating "id" values and not other types of data:		* <span id="annotate_is_important">'''Annotating some important bits''':</span> Due to the modularity of the backup and in order to know exactly which information must be saved (because it's used) and which one can be skipped, '''it's important to annotate some important elements along the whole backup''' process. So, back to our schema, we have marked the "choice_answer->userid" field as "annotation" (so backup will, automatically, add all the information for that user). Here it's the list of elements that we must not forget to annotate (or we could end with non-restorable backups). Note that we must, always, be annotating "id" values and not other types of data:
	** '''user''': Any field pointing to one user->id present along the schema (as said above, our schema has one).		** '''user''': Any field pointing to one user->id present along the schema (as said above, our schema has one).
	** '''grouping''': Any field pointing to one grouping->id		** '''grouping''': Any field pointing to one grouping->id