Terrain 12 — Environnement de dev
⏱️ TL;DR — 25 mini-jeux
⭐⭐→⭐⭐⭐pour monter un poste de dev Moodle : install locale,config.php, moodledata, mode débogage développeur, purge des caches, CLI, éditeur XMLDB, générateur de squelette, Git. À la fin, tu codes des plugins dans de bonnes conditions.
💡 Pour un dev React — Moodle = PHP + MySQL/PostgreSQL + un dossier de données (moodledata) + du cache partout. Le réflexe qui n’existe pas côté JS : purger les caches après (presque) chaque changement.
🕹️ Mini-jeu 1 — Installer Moodle en local ⭐⭐⭐ 💻
But : une instance jetable.
Mission : monte un Moodle local (Bitnami, Docker moodle-docker, ou install manuelle).
✅ Solution
Options : MoodleHQ moodle-docker (officiel, reproductible), Bitnami, ou install manuelle (PHP+MySQL+code). Pour du dev de plugins, moodle-docker est idéal (versions maîtrisées, PHPUnit/Behat prêts). Voir Partie 4.
🕹️ Mini-jeu 2 — Le fichier config.php ⭐⭐ 💻
But : la config racine.
Mission : ouvre config.php à la racine de Moodle.
✅ Solution
config.php définit $CFG->dbtype/dbname/... (BDD), $CFG->wwwroot (URL), $CFG->dataroot (→ moodledata). C’est le point d’entrée technique. Jamais exposé publiquement. On y ajoute les constantes de debug (jeu 4).
🕹️ Mini-jeu 3 — moodledata ⭐⭐⭐ 💻
But : le stockage hors web.
Mission : repère le dossier moodledata ($CFG->dataroot).
✅ Solution
moodledata stocke fichiers, caches, sessions — hors de la racine web (sécurité). Moodle = base de données + moodledata + code. Sauvegarder = les trois. Ne jamais le rendre accessible par URL.
🕹️ Mini-jeu 4 — Le mode débogage développeur ⭐⭐⭐ 💻
But : voir toutes les erreurs. Mission : active le débogage DEVELOPER. Étapes :
- Administration → Développement → Débogage → « DÉVELOPPEUR » + « Afficher les messages de débogage ».
✅ Solution
Le niveau DEVELOPER affiche toutes les notices/avertissements (API dépréciées, erreurs) — indispensable pour développer. À désactiver en prod. Équivalent de WP_DEBUG. Peut aussi se forcer dans config.php ($CFG->debug, $CFG->debugdisplay).
🕹️ Mini-jeu 5 — Forcer le debug en config ⭐⭐⭐⭐ 💻
But : debug reproductible.
Mission : ajoute les lignes de debug dans config.php.
Étapes :
$CFG->debug = (E_ALL | E_STRICT);
$CFG->debugdisplay = 1;✅ Solution
Mettre le debug dans config.php le rend indépendant de l’UI (utile en équipe/CI). debugdisplay = 1 affiche à l’écran. On complète souvent avec $CFG->cachejs = false et $CFG->themedesignermode = true en dev (jeu 6).
🕹️ Mini-jeu 6 — Désactiver les caches JS/thème ⭐⭐⭐ 💻
But : voir ses changements immédiatement. Mission : active le mode designer de thème et coupe le cache JS. Étapes :
$CFG->cachejs = false;
$CFG->themedesignermode = true;✅ Solution
En dev, Moodle cache JS et CSS de thème → tes modifications ne s’affichent pas. cachejs = false et themedesignermode = true servent les fichiers frais. ⚠️ Lent : à réserver au dev, jamais en prod.
🕹️ Mini-jeu 7 — Purger les caches ⭐⭐⭐ 💻
But : LE réflexe. Mission : purge tous les caches après un changement.
✅ Solution
Administration → Développement → Purger les caches (ou php admin/cli/purge_caches.php). Après tout changement de version.php, db/, langue, template : purge. Sinon tu débogues du code fantôme. À graver.
🕹️ Mini-jeu 8 — La CLI de Moodle ⭐⭐⭐ 💻
But : administrer au terminal.
Mission : explore le dossier admin/cli/.
✅ Solution
admin/cli/ contient des scripts CLI : cron.php, purge_caches.php, upgrade.php, install.php, maintenance.php… Exécutés avec php admin/cli/xxx.php. La voie pro pour scripter l’administration (comme WP-CLI côté WordPress).
🕹️ Mini-jeu 9 — Lancer le cron en CLI ⭐⭐⭐ 💻
But : exécuter les tâches planifiées. Mission : lance le cron manuellement. Étapes :
php admin/cli/cron.php✅ Solution
Le cron exécute les tâches planifiées (terrain 10, jeu 19). En prod, un cron système l’appelle toutes les minutes. En dev, on le lance à la main pour déclencher notifications, calculs, etc. Sans cron, « rien ne se passe » en arrière-plan.
🕹️ Mini-jeu 10 — Mettre à jour en CLI ⭐⭐⭐ 💻
But : appliquer les upgrades. Mission : lance l’upgrade en ligne de commande. Étapes :
php admin/cli/upgrade.php✅ Solution
Après avoir bumpé un version.php (plugin ou cœur), upgrade.php applique les migrations de base. Plus rapide et scriptable que l’UI. Réflexe après chaque changement de version d’un plugin en dev (terrain 13).
🕹️ Mini-jeu 11 — La structure des fichiers ⭐⭐⭐ 💻
But : la carte du code Moodle.
Mission : repère mod/, blocks/, local/, theme/, lib/, admin/.
✅ Solution
Chaque type de plugin a son dossier : mod/ (activités), blocks/, local/ (fonctions transverses), theme/, auth/, enrol/, question/… lib/ = le cœur (APIs). Tout ton code vit dans le dossier du type approprié — jamais dans lib/ ni le cœur.
🕹️ Mini-jeu 12 — Explorer la base ⭐⭐⭐⭐ 💻
But : voir les tables.
Mission : ouvre la base (Adminer/phpMyAdmin) et regarde mdl_user, mdl_course, mdl_role.
✅ Solution
Tables préfixées mdl_ (préfixe configurable). Clés : mdl_user, mdl_course, mdl_course_modules, mdl_context, mdl_role/mdl_role_assignments, mdl_grade_*. Voir les tables démystifie le modèle (Partie 5). On n’écrit jamais mdl_ en dur : {tablename} en DML (terrain 13).
🕹️ Mini-jeu 13 — L’éditeur XMLDB ⭐⭐⭐⭐ 💻
But : générer un schéma sans SQL. Mission : ouvre Administration → Développement → Éditeur XMLDB.
✅ Solution
L’éditeur XMLDB génère db/install.xml (définition de tables portable entre SGBD) via une UI, et produit même le code PHP d’upgrade. On l’utilise pour créer les tables de ses plugins (terrain 13) sans écrire de SQL propriétaire.
🕹️ Mini-jeu 14 — Le générateur de squelette ⭐⭐⭐ 💻
But : partir d’une base conforme. Mission : repère l’outil de génération de squelette de plugin.
✅ Solution
tool_pluginskel (ou le générateur en ligne Moodle Plugin Skeleton Generator) produit un plugin conforme aux conventions (fichiers, en-têtes GPL, PHPDoc) à partir d’une recette. Excellent point de départ pour ne rien oublier (terrains 13–15).
🕹️ Mini-jeu 15 — moosh ⭐⭐⭐⭐ 💻
But : un couteau suisse CLI. Mission : (optionnel) installe moosh et liste des commandes.
✅ Solution
moosh (outil communautaire) offre des commandes CLI pratiques (créer cours/utilisateurs, générer des données, gérer plugins) au-delà de admin/cli/. Accélère le dev et les tests. Facultatif mais apprécié.
🕹️ Mini-jeu 16 — VS Code + le projet ⭐⭐ 💻
But : ton éditeur. Mission : ouvre le dossier Moodle (ou juste ton plugin) dans VS Code.
✅ Solution
Ouvre le code dans VS Code (extensions : Intelephense, Moodle snippets). Configure le coding style Moodle (jeu 22). Tu es en terrain connu : recherche, terminal intégré, Git.
🕹️ Mini-jeu 17 — Créer un dossier local vide ⭐⭐⭐ 💻
But : ton bac à sable.
Mission : crée local/labo/version.php avec le minimum.
Étapes :
<?php
$plugin->component = 'local_labo';
$plugin->version = 2026070900;
$plugin->requires = 2025100700; // Moodle 5.2✅ Solution
Un plugin local minimal = un dossier local/labo/ + version.php (component en frankenstyle local_labo, version au format YYYYMMDDXX). Moodle le détecte et propose l’installation. Ton bac à sable pour la suite.
🕹️ Mini-jeu 18 — Installer ton plugin labo ⭐⭐ 💻
But : boucler la boucle.
Mission : installe local_labo via Notifications (ou admin/cli/upgrade.php).
✅ Solution
Moodle détecte le nouveau composant et lance l’installation (page Notifications). Il faut aussi un lang/en/local_labo.php avec $string['pluginname']. Ton plugin apparaît alors dans la vue d’ensemble. Prêt à coder (terrain 13).
🕹️ Mini-jeu 19 — Versionner avec Git ⭐⭐⭐ 💻
But : historiser.
Mission : git init dans ton plugin et fais un commit.
Étapes :
cd local/labo
git init && git add . && git commit -m "init local_labo"✅ Solution
On versionne le plugin (pas tout Moodle : le cœur se réinstalle, la base se sauvegarde à part). Ajoute un .gitignore (build AMD, vendor). Réflexe identique à tes projets JS. Base de la distribution (terrain 15).
🕹️ Mini-jeu 20 — Initialiser PHPUnit ⭐⭐⭐⭐ 💻
But : préparer les tests. Mission : initialise l’environnement de test. Étapes :
php admin/tool/phpunit/cli/init.php✅ Solution
Moodle a son framework PHPUnit intégré : init.php crée une base de test isolée. On lance ensuite vendor/bin/phpunit path/to/test. Base des tests de plugins (terrain 16). En moodle-docker, tout est préconfiguré.
🕹️ Mini-jeu 21 — Initialiser Behat ⭐⭐⭐⭐ 💻
But : tests d’interface.
Mission : initialise Behat (admin/tool/behat/cli/init.php).
✅ Solution
Behat pilote un navigateur pour tester les scénarios utilisateur (« étant donné… quand… alors… »). init.php prépare l’environnement. Puissant pour tester les parcours d’un plugin (terrain 16). Lourd à mettre en place — d’où l’intérêt de moodle-docker.
🕹️ Mini-jeu 22 — Le coding style Moodle ⭐⭐⭐⭐ 💻
But : respecter les conventions. Mission : installe moodle-cs (codechecker) et vérifie ton plugin.
✅ Solution
Moodle impose un coding style strict (vérifié par moodle-cs / PHP_CodeSniffer). L’installer dans VS Code/CI attrape les écarts (indentation, PHPDoc, sécurité) avant la review. Exigé pour publier sur moodle.org (Partie 11).
🕹️ Mini-jeu 23 — Un debugger (Xdebug) ⭐⭐⭐⭐ 💻
But : points d’arrêt. Mission : vérifie/active Xdebug (Serveur → Infos PHP, terrain 10).
✅ Solution
Xdebug permet le débogage pas-à-pas depuis VS Code/PhpStorm — bien plus puissant que debugging()/var_dump. moodle-docker propose une image avec Xdebug. Facultatif au début, précieux ensuite.
🕹️ Mini-jeu 24 — La fonction debugging() ⭐⭐⭐ 💻
But : logguer proprement. Mission : ajoute un message de debug dans ton code. Étapes :
debugging('Valeur de $x : ' . $x, DEBUG_DEVELOPER);✅ Solution
debugging() affiche un message seulement en mode DEVELOPER (jeu 4) — mieux que var_dump/echo (qui traînent en prod). C’est le console.log propre de Moodle. Pour du dur, préfère Xdebug.
🕹️ Mini-jeu 25 — Récap environnement ⭐⭐⭐ 💻
But : valider le poste de dev.
Mission : un setup complet : instance locale, config.php en mode DEVELOPER + caches JS/thème coupés, CLI opérationnelle, base explorée, XMLDB connu, plugin labo versionné, PHPUnit/coding-style prêts.
✅ Solution
Tu as un environnement de dev Moodle pro : débogable, testable, conforme, versionné. Tout est prêt pour écrire un vrai plugin. Cap sur ton premier plugin local (terrain 13).
Terrain suivant : 13 — Premier plugin (local).