Attention : vous consultez actuellement la documentation dédiée aux versions 1.x de Moodle. La documentation pour les versions 2.x de Moodle est consultable ici : Developpement de module : Etape 6, celle pour les versions 3.x de Moodle est consultable ici : Developpement de module : Etape 6 et celle pour Moodle 4.x est consultable là : Developpement de module : Etape 6.

Developpement de module : Etape 6

De MoodleDocs
Aller à :navigation, rechercher

Retour à l'index

6ème étape : pouvoir conserver son module dans une sauvegarde

La fonction de sauvegarde/restauration

Un module d'activité ne peut-être sauvegardé avec le cours et restauré dans Moodle que s'il implémente un dispositif particulier qui s'intègre dans la stratégie standard de sauvegarde/restauration.

C'est au développeur de constituer le jeu de scripts qui permettent ces deux opérations presque symétriques.

Le procédé général de sauvegarde est la conversion des données contenues dans la base de données en une séquence sérialisée XML qui s'insère dans le flux XML général de sauvegarde d'un cours.

La sauvegarde de ressources annexes ou de fichiers attachés par des stratégies non-standard ou à des emplacements hors du répertoire de données du cours doivent être prises en charge séparément.

La sauvegarde

Elle s'effectue dans le script "backuplib.php" et met en scène quelques fonctions standard à implémenter.

La génération de la séquence XML est une opération simple. Les balises ne contiennent de préférence pas d'attributs.

Fonctions standard pour la sauvegarde

  • <module>_backup_mods($bf, $preferences)
  • <module>_backup_one_mod($bf, $preferences)
  • <module>_check_backup_mods($course,$user_data=false,$backup_unique_code)
  • <module>_encode_content_links($content,$preferences)

Fonctions utilisées pour l'écriture du script de sauvegarde

Nous citons ici les fonctions utiles de l'API lib/backuplib.php nécessaires pour écrire le script de sauvegarde.

Dans les trois cas, le dernier paramètre contrôle l'écriture d'un "retour chariot" en fin de balise.

  • fwrite ($bf, start_tag($tagname, $level, true));
  • fwrite ($bf, full_tag($tagname, $level, false, $value));
  • fwrite ($bf, end_tag($tagname, $level, true));

start_tag() écrit une balise ouvrante de nom d'élément $tagname, à un niveau d'indentation $level. On s'accorde pour que la valeur de $level parte de 3 et augmente à chaque imbrication. La balise est refermée par un appel subséquent à end_tag().

full_tag() produit une balise complète encadrant une valeur littérale (pour le XML).

Exemple :

La séquence :

       fwrite ($bf,start_tag("HEADING",$level,true));
       $level++;
       //Print heading data ignoring id and foreign keys
       fwrite ($bf,full_tag("TITLE",$level,false,$heading->title)); 
       fwrite ($bf,full_tag("ABSTRACT",$level,false,$heading->abstract)); 
       fwrite ($bf,full_tag("RATIONALE",$level,false,$heading->rationale)); 
       fwrite ($bf,full_tag("ENVIRONMENT",$level,false,$heading->environment)); 
       fwrite ($bf,full_tag("ORGANISATION",$level,false,$heading->organisation)); 
       fwrite ($bf,full_tag("DEPARTMENT",$level,false,$heading->department)); 
       $level--;
       fwrite ($bf,end_tag("HEADING",$level,true));

Produit bien dans le fichier de sauvegarde une séquence

       <HEADING>
           <TITLE>...</TITLE>
           <ABSTRACT>...</ABSTRACT>
           <RATIONALE>...</RATIONALE>
           <ENVIRONMENT>...</ENVIRONMENT>
           <ORGANISATION>...</ORGANISATION>
           <DEPARTMENT>...</DEPARTMENT>
       </HEADING>

La restauration

Elle est un peu plus délicate, et est implantée dans un script standard appelé "restorelib.php" dans le répertoire du module :

D'une part, l'exploration de l'arbre XML conduit à une écriture un peu plus lourde que la sauvegarde, d'autre part, se pose le problème du réencodage des références :

En effet, les enregistrements de la base de données contiennent peut-être ce qu'on appelle des "clefs étrangères". Il s'agit de données qui identifient d'autres enregistrements dans des tables voisines.

Lors de la restauration, les données sont reconstituées sous forme de nouveaux enregistrements, utilisant des identifiants (id) obtenus dans la nouvelle base de données (il y a de fortes chances que les identifiants d'origines ne puissent être réutilisés car déjà pris dans cette base de données). Mais alors, ce sont les valeurs des références des autres clefs étrangères qui ne sont plus correctes.

Heureusement, Moodle prévoit ce problème et propose un dispositif pour réencoder les identifiants en utilisant la table spéciale prefix_backup_ids à travers un jeu de fonctions adéquat.