Moodle offre de nombreuses manières de contourner ou altérer le comportement de la plate-forme. Malgré toutes les méthodes qui permettent de ne pas altérer la partie standard de moodle. Il existe certaines modificaitons non réductibles qui nécessitent des interventions localisées dans le code standard.

L'inconvénient majeur des patchs est la perte de certaines fonctionnalités ou comportements lors de l'écrasement de la base de code par une mise à jour. La maintenance d'une base de code nécessite alors une maintenance des patchs

Si on ne peut parler “d'avantage” directement, on peut néanmoins donner deux cas de figure où le patch ne peut pas être évité, à moins de renoncer à certains objectifs de fonctionnement dans la plate-forme. L'équation résultante est une équation coût-bénéfice qu'il faut maîtriser. Des bonnes pratiques permettront de réduire les coûts de l'intégration de patchs afin d'en préserver le bénéfice.

• Le patch se situe dans un élément non surchargeable. Il existe des éléments dans le code moodle qui ne peuvent pas être surchargés “structurellement”. Un exemple est une fonction privée d'une classe, dont il n'est pas possible de produire une surcharge “objet”.
• La modification est contournable, mais le contournement demande le clonage et le détournement d'une grande quantité de code. A ce moment, le détournement présente un risque supérieur au patch : celui de ne plus permettre l'intégration des évolutions et corrections du code standard.

La protique des patchs est communément détestée par les exploitants, car cela entraîne souvent une certaine “obligation” à connaître le dessous du capot. Il existe cependant un certain nombre de pratiques et d'outillages qui permettent d'améliorer l'équation coût/risque/bénéfices que représente l'usage de patchs “core”.

Les pratiques qui réduisent le problème :

• Les patchs sont répertoriés et identifiés. Il doit pouvoir exister un “catalogue” des patchs mis en place, afin de pouvoir conduire sans oubli une réintégration lors d'une mise à jour. L'outil “report_patches” (Rapport de patch noyau) permet de découvrir les implantations des patchs lorsqu'ils se conforment à une convention de marquage systématique.
• Les patchs sont packagés dans les composants (plugins) qui en ont besoin. Ceci permet d'avoir une source d'information de référence stable et d'avoir la source “officielle et formelle” du patch. De plus certains outillages peuvent proposer d'automatiser une bonne partie de la réintégration.
• Les patchs sont aussi court que possible, idéalement une ligne d'appel vers le code du patch. Ce n'est pas toujours possible en fonction de la plus ou moins grande qualité de la structure du code d'origine.

Les plugins APL proposent une description formelle des patchs. Deux répertoires contiennent les patchs et leurs fichiers de référence.

• Le répertoire __patch contient les fichiers modifiés de moodle.
• Le répertoire __reference contient les fichiers de référence qui ont servi à la mise en place des patchs. Ces fichiers peuvent être très légèrement différents.

Tous les patchs sont identifiés par une séquence PATCH+ … PATCH-.

Ce catalogue est fourni par le composant Rapport de patch noyau. Il peut scanner le code du moodle installé à la recherche de marques formelles de patchs et fournir un rapport détaillé des implantations.

Vous pouvez utiliser un comparateur de code (WinMerge, BeyondCompare, ou autre) pour intégrer les modifications.

• Un plugin demande des modifications de type “patch” s'il contient un réperoire patch. * Comparez les arborescences de moodle (à partir de la racine) avec le contenu du répertoire 'patch' du plugin, en ne visualisant que les différences.
• Identifiez les différences qui sont encadrées par les marqueurs PATCH+ et PATCH-.
• Reportez ces différences dans la partie “moodle”.

Exemples de modifications éligibles.

• Ignorez les autres différences non marquées. Elles peuvent être issues de légères variations entre les fichiers de moodle (version mineure supérieure ou antérieure) et la version de référence consignée dans le plugin.

Exemples de modifications non éligibles.

Il peut exceptionnellement se produire des cas d'incertitude. Les plugins sont révisés pour faire référence aux fichiers les plus récents de chaque version majeure de moodle, Les cas de doutes doivent être rarissimes.

La qualification formelle des patchs permet d'envisager un objectif plus ambitieux de pour voir gérer la presque totalité des patchs avec une méthode automatisée de réintégration. Cet outillage est en cours de test et sera proposés à nos clients qui hébergent et construisent leur propre version locale de moodle.

Revenir à l'index