Bonsoir,
dans ce cas précis, des bonnes pratiques de custoisation permettraient d'éviter de toucher au code standard, altérations qui peuvent rendre difficile à terme la maintenance :
La solution que j'adopte régulièrement est :
- enclencher les "customscripts" dans le fichier de configuration de Moodle en ajoutant :
$CFG->customscripts= $CFG->dirroot.'/local';
puis créer un répertoire 'my' dans 'local' et y copier le fichier /my/index.php
( il y maintenant /local/my/index.php )
placer une instruction "die;" en toute fin de fichier (pour éviter le rebond sur le index.php original)
Commenter l'inclusion du fichier "config.php" (celui ci aura déjà été chargé dans le premier appel au "vtai" my/index.php)
Modifier le code de cette page tranquillement, elle n'est plus dans une zone standard et Moodle y est dérouté par l'usage des customscripts.
Pour les librairies utilisées, le mieux est de recopier une fonction, en la préfixant de "local_" dans un fichier /local/customlib.php par exemple, puis d'appeler cette fonction. Cela ne marche que pour la fonction détournée, car les appels internes continueront à appeler les fonctions originales. Cel ne marche donc aussi QUE pour des fonctions que vous appelez directement dans le script détourné, sinon la tâche est plus rude car il faut détourner toutes les fonctions intermédiaires entre l'appel customisé et la fonction que l'on veut modifier. Avec la nouvelle architecture de Moodle qui encapsule de plus en plus les librairies dans des classes, cela devient de moins en moins facile...
Pour aller plus loin :
ce répertoire "my" peut devenir un plugin local, en ajoutant un fichier de version, et un répertoire de langue. ce qui peut lui permettre de détenir aussi sa propre librairie (plutôt que tout mélanger dans /local/customlib.php). il peut donc devenir "installable" !
Cheers
Valery / Integrateur