Quiz 3 — Frontend & thèmes

Un module JavaScript ES6 (dans amd/src/, transpilé vers amd/build/) exportant des fonctions (souvent init). Le système JS modulaire natif de Moodle — pas de <script> en dur.

$PAGE->requires->js_call_amd('component/module', 'init', $args) — charge le module et appelle sa fonction, avec des arguments passés en JSON. Le pont PHP → JS.

Ils ne contiennent que du balisage + des placeholders ({{var}} auto-échappés, {{#tasks}}…{{/tasks}}). La logique reste en PHP (export_for_template). Sécurité XSS gratuite + séparation nette.

Oui, avec core/templates (renderForPromise) : le même template sert côté PHP et côté client → UI dynamique sans dupliquer le markup. Proche du rendu React.

À charger les chaînes de langue côté JS (asynchrone) : pas de texte en dur, i18n respectée jusque dans le JavaScript. L’équivalent JS de get_string().

À afficher des icônes thémables et accessibles ($OUTPUT->pix_icon('t/check', $alt)). Tes icônes vont dans pix/. Évite les <img> en dur.

Un renderable est un objet à afficher ; templatable ajoute export_for_template() qui produit les données simples que Mustache consomme. L’Output API sépare données et vue.

Le thème par défaut est Boost. Un thème peut hériter d’un parent (comme Boost) et ne surcharger que ce qu’il change (SCSS, templates, réglages).

Via les réglages du thème (couleur, logo) et un champ SCSS brut (Boost), ou en héritant de Boost et en surchargeant des variables/templates. Purger le cache thème ensuite.

get_content() renvoie l’objet {text, footer} du bloc (avec cache interne) ; applicable_formats() déclare où le bloc est ajoutable (course-view, my, site…).

Via edit_form.php (des champs config_*), accessibles ensuite par $this->config->xxx. Chaque bloc posé a sa config.

Ce sont les capabilities de bloc : addinstance = ajouter dans un cours, myaddinstance = ajouter au tableau de bord. Elles décident qui peut poser le bloc.

À builder l’AMD (amd/src/ → amd/build/, minifié) et à linter le JS (ESLint). En dev, $CFG->cachejs = false sert la source directement.

En 3e argument de js_call_amd(..., [$data]) (sérialisé JSON), reçu par la fonction JS. Pas de variable globale ni de <script> inline.

Obligation légale fréquente + inclusion : navigation clavier, ARIA, contraste, alt. Moodle vise WCAG ; tes blocs/thèmes doivent suivre. Fait partie de la qualité.

Oui : le thème peut différer par appareil, catégorie ou cours selon la config du site. Le sélecteur de thème gère ces cas.

En fournissant un template Mustache de même nom ; $PAGE->get_renderer() et le moteur de templates cherchent d’abord côté thème. C’est ce qui rend l’affichage thémable.

Non : Moodle a son propre système (Mustache + AMD + core JS). Mais certains thèmes/plugins intègrent React. Ta compétence React s’applique surtout côté headless/LTI (Parties 9–10).

Dans le dossier pix/ du plugin (ex. pix/icon.svg), servies via la pix API. Cohérentes avec le thème et accessibles.

Le cache JS est actif. En dev, mets $CFG->cachejs = false (+ themedesignermode = true) ; en prod, il faut rebuilder (Grunt) et purger. Confusion classique.