Partie 6 — Développer des plugins

Le cœur du métier de développeur Moodle. Vous avez le modèle mental (Partie 5 — globals, frankenstyle, DML, Form API, Output API, hooks) : il est temps de construire. Cette partie contient trois tutoriels complets de A à Z — chaque fichier de chaque plugin est donné en entier, copiable tel quel — plus un panorama de tous les types de plugins et tout ce qu’il faut savoir pour versionner, distribuer et déployer. Version de référence : Moodle 5.2 (PHP 8.3+).

« Tout est plugin » dans Moodle : le forum est un plugin (mod_forum), le thème par défaut est un plugin (theme_boost), l’authentification par mot de passe est un plugin (auth_manual). Écrire un plugin, c’est donc écrire du code Moodle normal — avec les mêmes APIs que le cœur. La différence avec un package npm : Moodle impose une structure de fichiers stricte par type de plugin (le « contrat » du type), et c’est cette structure qui déclenche l’installation, les mises à jour de schéma, les permissions, la navigation… Une fois le contrat compris, tout devient mécanique.

💡 Pour un dev React : un plugin Moodle ressemble moins à un composant qu’à un package d’un monorepo avec conventions de fichiers imposées (pensez aux conventions de routing de Next.js : page.tsx, layout.tsx, route.ts… mais en beaucoup plus vaste). Le fichier version.php joue le rôle du package.json, db/install.xml celui d’une migration Prisma, db/access.php définit les permissions, et lib.php expose les callbacks que le cœur appelle — l’équivalent d’exports nommés attendus par le framework.

Sommaire des chapitres

01 — Panorama des types de plugins

Le tableau complet des ~40 types de plugins de Moodle 5.2 : modules d’activité (mod), blocs, plugins locaux, thèmes, authentification, inscription, types de questions, formats de cours, filtres, dépôts, web services, conditions de disponibilité, fournisseurs IA, facteurs MFA… Pour chacun : dossier d’installation, préfixe frankenstyle, cas d’usage typiques. Un arbre de décision pour choisir le bon type pour votre besoin (spoiler : local_ ou block_ dans la majorité des cas au début), et le mécanisme des sous-plugins (subplugins.json).

02 — Anatomie universelle d’un plugin

Ce que tous les plugins partagent : version.php (component, version YYYYMMDDXX, requires, maturity, dependencies), lang/en/, le dossier db/ dans tous ses états (access.php, install.xml, install.php, upgrade.php, hooks.php, events.php, services.php, tasks.php, messages.php, caches.php, subplugins.json), settings.php, lib.php (et quand il est réellement obligatoire), classes/ (autoloading, privacy provider, external, output, form, task…), templates/, amd/, pix/, styles.css. Et le cycle d’installation/mise à jour pas à pas : ce que fait exactement Moodle quand il découvre un nouveau dossier, et comment désinstaller proprement.

03 — Tutoriel complet : plugin local (local_todolist)

Votre premier vrai plugin, de zéro à fonctionnel : une todo-list personnelle par utilisateur. Table XMLDB, capabilities, page index.php avec le pattern sécurisé complet, formulaire moodleform d’ajout/édition, CRUD via DML, renderer + template Mustache, entrée dans la navigation (hook), page de réglages admin, puis une chaîne d’upgrade réelle (ajout d’une colonne en version 2). Chaque fichier donné en entier.

04 — Tutoriel complet : bloc (block_progressinfo)

Un bloc affichant la progression de l’utilisateur dans le cours : classe block_*, get_content(), configuration par instance (edit_form.php), applicable_formats(), capabilities spécifiques aux blocs (addinstance, myaddinstance), un module JS AMD léger, template Mustache, instances multiples, et l’ajout automatique au tableau de bord.

05 — Tutoriel complet : module d’activité (mod_simplecheck)

Le plus gros tutoriel de la documentation : une activité « checklist notée » avec toute la mécanique mod : mod_form.php, view.php, lib.php et les fonctions _add_instance/_update_instance/_delete_instance, les FEATURE_*, index.php, l’intégration au carnet de notes (grade_update), l’achèvement d’activité (règles custom via classes/completion/custom_completion.php), les events (course_module_viewed), le backup/restore (backup/moodle2/), le reset de cours et l’affichage sur la page de cours (cm_info). Avec, pour chaque brique, la mention explicite : obligatoire ou optionnel.

06 — Les autres types en pratique

Exemples courts mais complets et fonctionnels : un admin tool (tool_) avec page d’admin et tâche planifiée, un filtre de texte de cours, un format de cours héritant de format_topics, une condition de disponibilité (availability_), un champ personnalisé (customfield_), et des survols structurels honnêtes des types complexes : type de question (qtype_), dépôt (repository_), bouton d’éditeur TinyMCE (tiny_). Pour chaque : arborescence minimale, fichiers clés, pièges.

07 — Cycle de vie et distribution

Versionner correctement (quand bumper version.php ?), dépendances entre plugins, environment.xml, compatibilité multi-versions de Moodle (stratégie de branches git), distribution privée (git, zip, composer ?), déploiement en production (CLI upgrade, mode maintenance), gestion multi-instances, et une introduction à la publication sur moodle.org (détaillée en Partie 11).

Comment lire cette partie

Lisez 01 et 02 dans l’ordre : le panorama vous évite de développer un local_ là où un block_ était le bon choix, et l’anatomie est le socle commun aux trois tutoriels.
Faites réellement le tutoriel 03 (local_todolist) sur votre instance de dev (Partie 4) : c’est en installant, cassant et upgradant un vrai plugin que les mécanismes s’ancrent. Comptez 2–3 heures.
Le tutoriel 04 (bloc) est rapide ; le tutoriel 05 (mod) est long — c’est normal, les modules d’activité sont le type le plus riche. Vous pouvez le faire en plusieurs sessions (la structure du chapitre s’y prête).
Le chapitre 07 devient critique dès que votre plugin quitte votre machine : lisez-le avant tout déploiement en production.

⚠️ Piège : ne développez jamais directement dans une instance de production, et ne modifiez jamais le code du cœur pour arriver à vos fins (« core hack ») — chaque mise à jour de Moodle écraserait vos modifications. Tout ce dont vous avez besoin est faisable par plugin ; si ça ne l’est pas, c’est le signe qu’il faut reformuler le besoin (ou proposer un patch au cœur, Partie 11).

📚 Aller plus loin : la référence officielle des types de plugins est sur moodledev.io/docs/5.2/apis/plugintypes . Gardez aussi sous la main les fichiers communs et le dépôt d’exemples moodlehq/moodle-mod_pluginskel (générateur de squelettes). Le code du cœur reste votre meilleure documentation : mod/lesson, block_recentlyaccesseditems, local_ de la communauté…