C'est pour cette raison qu'il est toujours préférable de se constituer une plate-forme de préproduction juste à côté pour procéder à un test de mise à jour avant production. Dans plus de 95% des cas, les erreurs de ce type sont identifiables, en tout cas celles qui perturbent des écrans "généraux" de moodle.
Les cas plus complexes apparaissent lorsque l'erreur est imputable à des données particulières.
Une preprod qui recopie l'intégralité des données de la production est toujours mieux, mais cela duplique le moodledata et donc prend 2 fois plus de place. Un compromis étant de purger le pré-production de la majorité des cours "non significatfs" en contenus.
En général, il ne faut pas faire confiance "en prod" aux fonctions de mise à jour des plugins par l'administration moodle. Rien ne garantit absolument que transitoirement, une publication disponible ne soit pas erronée (on voit à quel point une seule virgule dans le code peut le casser à un endroit critique, pas toujours identifiable immédiatement par le développeur). La deuxième raison est que les répertoires de plugins de moodle doivent être laissés inscriptibles par le processus web, ce qui constitue une faille de sécurité majeure sur le serveur, surtout si d'autres applicatifs moins sécurisés que moodle sont installés à côté). Il convient de préciser les clefs suivantes dans le fichier de configuration :
$CFG->disableupdateautodeploy = true;
La clef :
$CFG->disableupdatenotifications = false;
ne présente pas de risque de sécurité, mais éventuellement des risques de rallentissement pour l'administrateur lorsque les conditions réseau sont altérées et que les temps de connexion entre votre serveur et moodle.org sont dégradés. Si vous n'avez pas une politique de mise à jour permanente ou suivie, désactivez ces requêtes en réglant sur "true".
Cheers
