Partie 5 — Architecture du cœur de Moodle

La partie la plus importante de cette documentation. Tout ce que vous ferez ensuite — plugins, thèmes, intégrations — repose sur les concepts présentés ici. Version de référence : Moodle 5.2 (PHP 8.3+).

Moodle n’est pas un framework MVC moderne. C’est un socle applicatif vieux de plus de vingt ans, modernisé par couches successives (autoloading PSR-ish, DI container, hooks, Mustache, AMD/ESM…), mais dont le cœur reste organisé autour de page scripts et d’APIs transverses. Comprendre cette organisation — plutôt que d’y chercher un équivalent de Next.js ou Laravel — est la clé pour devenir productif.

💡 Pour un dev React : pensez à Moodle comme à un « monorepo » géant où chaque plugin est un package, où les APIs cœur (DML, Output, Form, Cache…) jouent le rôle de vos librairies partagées, et où les globals ($DB, $OUTPUT…) sont des singletons injectés au boot — l’équivalent, en beaucoup plus ancien, d’un contexte global applicatif.

Sommaire des chapitres

01 — Vue d’ensemble : cycle de vie d’une requête

Comment une requête HTTP traverse Moodle : config.php → lib/setup.php → page script. Les globals sacrés ($CFG, $DB, $USER, $SESSION, $PAGE, $OUTPUT, $COURSE, $SITE) et pourquoi ils existent. Le nommage frankenstyle (mod_quiz, block_html, local_foo…), l’autoloading (classes/ + namespaces), « tout est plugin », la structure d’une page type (require_login, $PAGE->set_*, echo $OUTPUT->header()), et le déplacement de la racine web dans public/ depuis Moodle 5.1.

02 — La base de données : XMLDB et DML

La couche DB complète : schémas XMLDB (db/install.xml, éditeur intégré, types, clés, index), upgrades (db/upgrade.php, savepoints, version.php), l’API DML ($DB->get_record, get_records_sql, get_recordset, insert_record…), placeholders, helpers SQL (get_in_or_equal, sql_like…), transactions déléguées, conventions de nommage, préfixe mdl_, et surtout le schéma mental des tables cœur (user, course, course_modules, context, role_assignments, grade_items, files…) avec leurs relations.

03 — Form API : moodleform

Définir des formulaires en PHP : definition(), addElement() (tous les types), setType() obligatoire, addRule(), addHelpButton(), validation custom, get_data()/set_data(), éditeurs/filepicker/filemanager dans les forms, éléments répétés, hideIf/disabledIf, le pattern complet is_cancelled()/get_data(), et pourquoi le markup généré est difficile à styler.

$OUTPUT et core_renderer, renderables + templatable, render_from_template(), templates Mustache côté PHP, $PAGE (pagelib : set_url, set_context, requires->js_call_amd…), notifications, html_writer (legacy), moodle_url, l’API de navigation (primary/secondary/settings nav), pagination et tables (table_sql/flexible_table).

05 — Fichiers, chaînes de langue, configuration

La File API : file areas, contexte/component/itemid/filepath/filename, stored_file, file_storage, servir des fichiers via pluginfile.php + xxx_pluginfile(), draft areas dans les formulaires, file_rewrite_pluginfile_urls(). La String API : get_string(), lang/en/, AMOS et la traduction FR, placeholders {$a}. La configuration : get_config/set_config, pages d’admin (admin_settingpage, admin_setting_configtext…), $CFG->x vs get_config('plugin').

06 — Events, Hooks, Tasks, Messages

Events 2 : déclarer \mod_foo\event\..., trigger(), observers (db/events.php), logs & analytics. Le nouveau système de Hooks (4.4+) : classes de hooks, db/hooks.php, hook manager, remplacement progressif des callbacks lib.php (liste des callbacks legacy encore courants). Task API : scheduled tasks (db/tasks.php, cron), adhoc tasks, CLI, verrous. Message API : providers, notifications, et le subsystem Communication (Matrix).

07 — Cache, sessions, sécurité côté code

MUC (Moodle Universal Cache) : définitions (db/caches.php), types application/session/request, stores (file, Redis…), cache::make, invalidation. Sessions. Sécurité : require_login/require_capability/has_capability, context_course::instance() et famille, is_siteadmin, sesskey (CSRF), required_param/optional_param + tous les PARAM_*, format_text/format_string et XSS — avec le pattern de page sécurisée complet.

Comment lire cette partie

Lisez le chapitre 01 en entier avant toute chose : il installe le modèle mental (globals, frankenstyle, autoloading) que tous les autres chapitres supposent acquis.
Les chapitres 02 (base de données) et 07 (sécurité) sont les deux à connaître par cœur : 90 % des bugs et failles des plugins tiers viennent d’une mauvaise maîtrise de ces deux-là.
Les chapitres 03–06 se lisent dans l’ordre qui vous arrange, mais 04 (Output) suppose 01, et 06 (Events/Hooks) est indispensable avant d’écrire votre premier plugin sérieux.

📚 Aller plus loin : la documentation développeur officielle vit sur moodledev.io (et non plus docs.moodle.org/dev). Gardez sous la main la Component library (démarrable localement via grunt componentlibrary) et le guide de codage .