Quiz 2 — Architecture & plugins

$DB = accès base (DML), $USER = utilisateur courant, $CFG = config, $PAGE = la page en cours (URL, contexte, requires), $OUTPUT = le renderer (header/footer/HTML).

La convention de nommage type_nom (ex. mod_forum, local_todolist, block_html) qui préfixe fonctions, tables, chaînes, capabilities pour éviter les collisions. À respecter partout.

La carte d’identité du plugin : component, version (YYYYMMDDXX, à bumper à chaque changement de schéma), requires (Moodle min), maturity. L’équivalent du package.json.

On passe par le DML ($DB->get_records, insert_record…) : portable entre SGBD et paramétré (pas d’injection). Pour du SQL, get_records_sql avec placeholders, jamais de concaténation.

Il définit les tables du plugin de façon portable (MySQL/PostgreSQL), généré via l’éditeur XMLDB. Créé/supprimé automatiquement à l’install/désinstall.

Les capabilities du plugin (droits atomiques type/nom:action), avec leur contextlevel, captype, archetypes et flags de risque. Le socle de la sécurité par permission.

require_login() (session + accès), fixer le contexte (context_*::instance) + $PAGE->set_*, puis require_capability($cap, $context). Ensuite $OUTPUT->header()/footer().

À lire et assainir les entrées (required_param('id', PARAM_INT)). On ne touche jamais $_GET/$_POST bruts. Le type PARAM est la première défense.

C’est le jeton anti-CSRF : require_sesskey() sur toute action qui modifie un état via un lien. La Form API le gère automatiquement.

local = fonctionnalité transverse (pas liée à un cours). block = affichage contextuel dans une colonne. mod = activité de cours (le plus riche). Choisir le bon type évite de tout refaire.

À étendre le cœur sans le modifier : le cœur déclenche des hooks/callbacks auxquels ton plugin s’accroche. C’est la philosophie « tout est extensible » (comme les actions/filtres WordPress).

Elle génère des formulaires sécurisés : sesskey/CSRF automatique, validation, types PARAM_*. On ne bricole jamais un <form> à la main.

Un renderable/templatable porte les données (export_for_template), un renderer appelle un template Mustache (auto-échappé, thémable). HTML hors du contrôleur = testable et surchargeable.

Il migre la base entre versions sans perte de données (if ($oldversion < NNN) + upgrade_plugin_savepoint). La migration Prisma de Moodle. Déclenché après un bump de version.

Dans lang/en/component.php, appelées via get_string('cle', 'component'). Aucune chaîne en dur. pluginname est obligatoire. Base de l’i18n.

get_config('component', 'name') / set_config(...), alimentés par settings.php (Settings API). Les réglages vivent dans la table de config, pas dans une table à toi.

Moodle cache définitions de plugins, langue, thèmes. Après tout changement de version.php/db//lang/template, il faut purger sinon tu débogues une version périmée.

Le dossier de stockage de fichiers (uploads, caches, sessions), hors de la racine web (sécurité). Moodle = base de données + moodledata + code. Sauvegarder = les trois.

Le Privacy API (RGPD) : déclarer les données perso stockées, les exporter et les supprimer sur demande. Sans lui, le plugin est signalé non conforme (refus de publication).

Chaque mise à jour de Moodle écraserait tes modifications, et c’est un risque de sécurité. Tout est faisable par plugin/hook/surcharge ; sinon, on propose un patch au cœur.