La démarche de customisation
La démarche de "customisation" (ou personnalisation de Moodle) peut être ponctuelle ou de plus grande envergure.
Dans tous les cas elle n'est pas anodine, car elle impacte, suivant comment elle est exécutée, sur la facilité à maintenir le code de Moodle et de profiter des mises à jour régulièrement proposées par la communauté.
La démarche de "customisation" présentera toujours un risque à terme de rendre plus compliqué la maintenance, c'est-à-dire, surtout, que les modifications apportées, même si elles sont contrôlées au moment de leur insertion peuvent avoir potentiellement des effets de bord lors d'une mise à jour ultérieure. Certaines techniques permettent de minimiser ce risque.
Le questionnement préalable
Pour ces raisons, tout projet de personnalisation devrait suivre une démarche tendant à bien évaluer l'intérêt de la modification avant de lancer des développements :
- La fonctionnalité que je m'apprête à ajouter n'existe-t-elle pas déjà dans la plate-forme standard ?
- La fonctionnalité que je m'apprête à ajouter n'est elle pas fournie déjà par des contributions stables et dignes de confiance ?
- La communauté Moodle peut-elle m'aiguiller vers un contournement déjà identifié ?
- Ce contournement me suffit-il ?
- Moodle est-il bien l'endroit où développer cette fonctionnalité, ou des solutions complémentaires ne seraient-elles pas mieux adaptées et plus fonctionnelles ?
Une fois ce premier questionnement résolu, par votre exploration ou avec l'aide des nombreux contributeurs présents sur les forums, vous pourrez passer à la deuxième série de questions :
- La fonctionnalité que je désire peut elle être circonscrite dans des plugins (blocs, modules, filtres, formats de cours, formats de questions, rapports, etc...) ?
- La fonctionnalité que je désire est elle totalement nouvelle, ou dérive-t-elle de comportements existants ou approchants ?
- La fonctionnalité que je désire est-elle liée à des fonctions très centrales de Moodle, touche-t-elle à des librairies profondes ou est-elle une adaptation de superficie (*) ?
(*) Il peut être parfois difficile de répondre à cette question, et ce n'est pas l'interface de Moodle qui peut vous aider à y répondre : deux éléments d'interface très proches peuvent être produits à des endroits très différents du code de Moodle.
Les prérequis du succès "à terme"
- Toujours développer au plus près du "coding style" et des façons de faire de la communauté. Ceci permettra une relecture aisée du code par n'importe quel développeur Moodle de la communauté, même si le développeur original a quitté votre organisation.
- Tenter de préférence d'inscrire vos fonctionnalités dans des plugins "débrayables", plutôt que des altérations sauvages.
- Minimiser les impacts dans le noyau. Le mieux est évidemment de ne pas en avoir (solutions "patch free").
- Toujours développer en utilisant les propositions les plus récentes de l'architecture (et ne pas recopier du code déjà obsolète ou déprécié).
- Abuser du copier-coller. Contrairement aux examens, vous êtes vivement encouragés à copier des séquences de code écrite par les autres Moodleurs qui sont passés avant vous ! Leur expérience peut rapidement devenir la vôtre.
