Le format page est un format très puissant qui demande un peu de technique d'intégration.
Depuis sa version d'origine pour Moodle 2.3, un gros effort a été fait pour se débarrasser au plus possible de patchs dans le noyau de Moodle. Ce travail d'architecture est actuellement terminé. le format page, pour un fonctionnement normal, doit néanmoins être précédé d'une mise en place rigoureuse de certaines surcharge superficielles sur le fonctionnement standard de Moodle. L'intégralité de ces surcharges :
Moodle prévoit que le gestionnaire de blocs soit basé sur un design pattern de “Fabrique”. Ce pattern permet d'éviter à l'exécution, que la classe invoquée soit gravée dans le marbre. Elle peut être changée par un minimum de modifications du code.
Malheureusement, un petit défaut d'architecture ne permet pas de définir par simple configuration le gestionnaire de blocs, lors de l'entrée dans un cours. Ce choix s'effectue au début de la vue du cours, code faisant partie du noyau. Heureusement, ce script étant un “point d'entrée” de Moodle, il peut être facilement détourné.
La distribution du format page propose dans un répertoire __customscripts un ensemble de contournements pour la version courante de Moodle. la mise en place est simple et consiste à :
Ces mises en place n'empêchent pas le fonctionnement correct du format page, mais peuvent ajouter une plus grande cohérence de navigation dans certains cas d'usage.
Lorsqu'une page est entièrement surchargée par une activité, la séquence de lecture du cours est arrêtée sur l'activité pour jouer celle-ci à travers ses différents écrans. Le contexte d'affichage est sorti du cours pour aller dans celui de l'activité, qui se déroule le plus souvent avec des dispositions “standard” de Moodle (et donc sans tenir compte de cette situation particulière). Certaines activités éditées par Edunao prévoient déjà en natif la prise en charge de l'intégration au format page, en invoquant la navigation de ce format en bas de l'écran.
Pour les autres qui ne le prévoient pas, il est nécessaire de rajouter quelques contournements par des customscripts, afin d'injecter cette navigation en bas de page.
ATTENTION, toutes les activités ne sont pas architecturées pour admettre un contournement facile. Les plus adéquates sont celles qui font un appel explicite à :
echo $OUTPUT->footer();
Dans la vue à surcharger (une vue d'entrée commence toujours par l'appel à “config.php”).
A ce moment, vous pouvez copier cette vue dans un répertoire isomorphe dans les customscripts, et ajouter juste avant l'appel au footer la séquence de navigation du format page suivante :
if ($course->format == 'page'){
require_once $CFG->dirroot.'/course/format/page/xlib.php';
page_print_page_format_navigation($cm, true);
}
Comme pour toutes les surcharges par customscript n'oubliez pas de terminer votre page par
die;
Après avoir appelé le footer, pour éviter de rejouer la vue originale.
Il peut encore arriver dans certains cas de manipulations complexes, que la structure du format page soit perturbée ou altérée, provoquant des pertes de modules, mal indexés dans les pages et les sections. Les scripts suivants permettent d'exécuter des procédures correctives, générales ou ciblées :
Pour un cours donné <IDC>
cd <moodleroot>/course/format/page/cli sudo -u<webuser> php redraw_all_sections.php --courses=<IDC>
(*) Une liste d'ids à virgule peut être donnée à la commande. Sans mention du paramètre –courses, la correction s'opère sur la totalité de la plate-forme, pour tous les cours au format page détectés. Il est conseillé de faire un backup de base de données avant une opération de correction globale. (**) A noter que les modules mal attachés sont récupérés et rattachés à nouveau dans les sections/page, contrairement aux outils de correction par l'interface d'audit du format page en mode web. Ces dernières nettoyent les données en détruisant les éléments supplémentaires non rattachés.
Revenir à l'index du composant Format Page - Revenir à l'index des plugins - Revenir au catalogue