Welche nicht dokumentierten Einstellungen gibt es für das H5P-Plugin für Moodle?

Dokumentation gehört nicht zu den Stärken des H5P-Projekts. Das gilt auch für das H5P-Plugin für Moodle der H5P Group. Es erklärt viele der Stellschrauben nicht, mit denen du dein System anpassen kannst. Und gesammelt an einer Stelle findest du sie auch nirgends. Schließen wir diese Lücke!

Alle Einstellungen werden über Konfigurationsvariablen in Moodles config.php gesteuert. Du fügst sie dort einfach mit passenden Werten hinzu, wenn du sie brauchst.

Beispiel: $CFG->mod_hvp_crossorigin = "anonymous";

Ressourcen-Bündelung

H5P-Inhalte bauen in der Regel auf verschiedenen H5P-Bibliotheken auf. Jede Bibliothek bringt mindestens eine JavaScript-Datei mit und meist auch mindestens eine CSS-Datei. Ältere Bibliotheken enthalten oft mehr als eine dieser Dateien. Insgesamt sind das viele Dateien, die der Server ausliefern muss, und jede einzelne Anfrage bringt ein wenig Overhead beim Laden mit sich. Mit anderen Worten: Das kann die langsam werden.

H5P-Integrationen wie das H5P-Plugin für Moodle bringen deshalb einen Mechanismus mit, um Ressourcen zu bündeln. H5P fasst alle JavaScript- und CSS-Dateien, die ein Inhaltstyp benötigt, jeweils zu einer Datei zusammen. Der Server muss also nur zwei Dateien verarbeiten, um den Code an deinen Browser zu liefern. Das führt meist zu einem deutlichen Geschwindigkeitsgewinn, benötigt aber mehr Speicherplatz für all die cachedassets.

Anmerkung : Dieser Mechanismus war deutlich wichtiger, als H5P entstand und HTTP/1 den Ton angab. Inzwischen hat HTTP/2 die Rechnung natürlich erheblich verändert.

Anmerkung : Moodle selbst macht normalerweise dasselbe standardmäßig auch für alle JavaScript-Dateien („cachejs“-Option).

$CFG->mod_hvp_aggregate_assets

Mit dieser Einstellung kannst du die Ressourcen-Bündelung bewusst abschalten. H5P lädt dann jede einzelne JavaScript- und CSS-Datei separat und ohne jedwedes Caching.

Setze mod_hvp_aggregate_assets auf "0", um die gebündelten Dateien zu deaktivieren.

Die Bündelung abzuschalten, sollte selten nötig sein, kann beim Debugging aber helfen, wenn etwas nicht funktioniert. Es kann zum Beispiel vorkommen, dass H5P-Bibliotheken streiken, weil bei der Entwicklung Fehler gemacht wurden oder etwas nicht bedacht oder gar gewusst wurde.

Backup-Verhalten

Wenn du ein Backup eines Moodle-Kurses mit H5P-Inhalten erstellst, stellt das Plugin sicher, dass alle Dateien, die zum Wiederherstellen der H5P-Inhalte nötig sind, in der Backup-Datei landen.

Standardmäßig enthält jedes Backup eines Kurses mit H5P-Inhalten Kopien aller verwendeten Bibliotheken samt ihrer Abhängigkeiten und der zugehörigen Datenbanktabellen; selbst dann, wenn dieselbe Bibliothek in 50 Kursen genutzt wird. Das ist sehr sicher, lässt die Backups aber deutlich größer werden.

$CFG->mod_hvp_backup_libraries

Die Einstellung mod_hvp_backup_libraries kannst du auf "0" setzen, damit die Bibliotheksdateien gar nicht erst mitgesichert werden. Die H5P-Inhalte enthalten dann weiterhin einen Verweis auf etwas wie „H5P.CoursePresentation 1.26“, die jeweilige Bibliothek wird aber nicht abgelegt. Das macht die Backups deutlich kleiner (und der Vorgang läuft vieeel schneller, aber das ist ein Thema für sich).

Der Nachteil: Du musst beim Wiederherstellen einer Backup-Datei sicherstellen, dass alle benötigten H5P-Bibliotheken in der erwarteten Version installiert sind. Es reicht meist nicht, nur dafür zu sorgen, dass die neuesten H5P-Bibliotheken installiert sind. Wenn ein H5P-Inhalt nicht mit der nötigen Bibliotheksversion ausgeliefert werden kann, funktioniert er nicht. Manche Leute haben sich damit schon Ärger eingebrockt, weil sie das nicht wussten.

Cross-Origin-Resource-Sharing (CORS)

Es gibt drei Variablen, die mit der Auslieferung über Domaingrenzen hinweg zu tun haben. Sie steuern, ob Medien (Bilder, Audio, Video), die H5P-Inhaltstypen verwenden und die von anderen Moodle-Seiten in einem Multisite-Netzwerk geladen werden, mit dem Cross-Origin-Resource-Policy-Header ausgeliefert werden. Das ist wichtig, weil Browser Medien von fremden Domains blockieren, wenn der entfernte Server sie nicht ausdrücklich freigibt.

$CFG->mod_hvp_crossorigin

Mit dieser Einstellung kannst du dem Plugin sagen, dass es allen lokalen H5P-Medienanfragen das crossorigin-Attribut hinzufügen soll. Nötig ist das, wenn die Moodle-Seite H5P-Ressourcen über HTTP ausliefert, sie aber auf einer HTTPS-Seite einbettet (Mixed Content), oder wenn ein Reverse Proxy bzw. ein CDN den Cross-Origin-Resource-Policy-Header entfernt oder umschreibt.

Standardmäßig ist hier nichts gesetzt. Der Browser verlässt sich dann auf die CORS-Header des anderen Servers. Wenn du das ändern willst, stehen dir folgende Werte zur Verfügung:

  1. "anonymous": Mit diesem Wert wird das Attribut crossorigin bei <img>-, <audio>– und <video>-Elementen auf anonymous gesetzt. Der Browser schickt die Anfrage dann ohne Zugangsdaten, und der entfernte Server muss mit Access-Control-Allow-Origin: * antworten (oder mit dem Origin der anfragenden Seite).
  2. "use-credentials": Wie oben, nur schickt der Browser Zugangsdaten mit (Cookies, Authentifizierung). Ich würde sagen, das wird nur selten zum Einsatz kommen.

$CFG->mod_hvp_crossoriginRegex

Mit dieser Einstellung kannst du gezielt einzelne Domains freigeben, die eine crossorigin-Behandlung brauchen. Ist crossorigin gesetzt, crossoriginRegex aber nicht, dann wird das Attribut auf alle lokalen Medien angewendet. Das ist meist unproblematisch, aber unnötiger Overhead, wenn nur ein paar externe Quellen es benötigen.

Standardmäßig ist nichts gesetzt. Du kannst hier jeden gültigen regulären Ausdruck im JavaScript-Format als Zeichenkette verwenden, etwa "example\.com" oder "subdomain\.example\.com". Ist der Wert gesetzt, ergänzt das Plugin das crossorigin-Attribut nur bei Medien, deren Quell-URL zu diesem regulären Ausdruck passt. So kannst du bestimmte externe Seiten adressieren, zum Beispiel einen Dateiserver oder eine andere Moodle-Seite, ohne alle Medien zu beeinflussen.

$CFG->mod_hvp_crossoriginCacheBuster

Mit dieser Einstellung kannst du dafür sorgen, dass Anfragen mit und ohne crossorigin für dieselbe Datei sich im Browser-Cache nicht in die Quere kommen. Ohne sie bekommen Nutzende nach einem Update der Seite womöglich veraltete Medien zu sehen.

Der Wert sollte ein gewöhnliches Query-String-Fragment sein, das sich für deinen Anwendungsfall passend ändert. Nur wenn es sich von dem unterscheidet, was im Cache liegt, wird der Cache verworfen. Ein möglicher Wert wäre also "cachebuster=" . time(). Die aktuelle Zeit zum Verwerfen des Caches zu nutzen, macht den Sinn des Cachings natürlich zunichte – passe das also an deinen Anwendungsfall an.

Entwicklung

Die H5P Group hat eine eigene Entwicklungsumgebung für H5P-Inhaltstypen gebaut, das H5P CLI, die wirklich nützlich ist. Manche Leute entwickeln Inhaltstypen aber (immer noch) lieber direkt auf einer Moodle-Instanz. Und das ist normalerweise eine Qual. Ich gehe hier nicht ins Detail, warum – du wirst gleich sehen, weshalb nicht. Aber es gibt da diese eine Einstellung …

$CFG->mod_hvp_dev

Du könntest mod_hvp_dev auf "1" setzen. Das hätte einen Entwicklungsmodus aktiviert, in dem H5P beim Hochladen einer Bibliothek die Patch-Version ignoriert hätte – du hättest eine Bibliothek mit identischer Major-/Minor-/Patch-Version immer wieder und mit Änderungen installieren können. Ich verwende hier den Konjunktiv, weil diese Funktion nicht mehr funktioniert. Die H5P Group hat die Unterstützung dafür im H5P-Core (versehentlich?) entfernt. Das ist aber nicht soooo wichtig. Wie gesagt, mit dem H5P CLI lässt sich ohnehin besser entwickeln. Aber manchmal wäre diese Option praktisch, wenn man etwas testen oder reparieren muss …

Anmerkung: Das H5P-Plugin für WordPress hat dasselbe Problem

Kontrolle über Exportdateien

H5P-Inhalte lassen sich normalerweise über den „Reuse“-Button in der Aktionsleiste unterhalb des Inhalts herunterladen – es sei denn, wer den Inhalt erstellt, schaltet diese Option ab. Damit das möglich ist, legt H5P eine fertige Exportdatei ab, statt sie bei jeder Anfrage ad-hoc zu erzeugen. Das ist schneller, braucht aber mehr Speicherplatz.

Du kannst etwas Verwandtes auch im Adminbereich des H5P-Plugins einstellen. Dort findest du eine „Download erlauben“-Option, die festlegt, ob ein Download angeboten werden soll. Die Konfigurationsvariable legt stattdessen fest, ob die für den Download voegesehene Export-Datei überhaupt erzeugt wird. Und außerdem kannst du damit den Zugang zum Download beispielsweise auch von der Rolle der nutzenden Person in Moodle abhängig machen oder dir eine andere Bedingung ausdenken.

Vielleicht möchtest du das ändern …

$CFG->mod_hvp_export

Die Einstellung mod_hvp_export kann auf "0" oder false gesetzt werden oder gar nicht.

  • "0": Es werd keine Exportdatei mehr für neue Inhalte erzeugt. Bereits existierende Exportdateien werden aber nicht gelöscht. Das wäre deine Wahl, wenn sich keine H5P-Inhalte herunterladen lassen sollen und du Speicherplatz sparen willst.
  • false:  Die Exportdatei wird gespeichert, das heißt es gibt weiterhin eine Export-URL, über die du den Inhalt herunterladen könntest, auch wenn du Nutzenden den Download verbietest. Vielleicht hast du ja einen Anwendungsfall dafür …
  • Falls nichts gesetzt wird, hängt das Verhalten von der „Herunterladen erlauben“- Einstellung (mod_hvp/export) in Moodles Administration ab.

File Storage

H5P muss Dateien irgendwo ablegen: JavaScript, CSS, Ressourcen wie Schriftarten und Medien, die beim Erstellen in die H5P-Inhalte eingefügt werden. Der Kern von H5P erledigt das nicht selbst, sondern überlässt die Aufgabe der H5P-Integration (z. B. dem H5P-Plugin für Moodle), die die Speicherverwaltung für die darunterliegende Plattform (z. B. Moodle) implementiert. Vgl. „Was war das doch gleich? Ein Überblick über die Architektur von H5P“.

Standardmäßig nutzt das H5P-Plugin für Moodle Moodles File-API, um Dateien auf die Festplatte deines Servers zu schreiben. Dafür gibt es eine eigene Klasse. Aber was, wenn du etwas anderes verwenden willst? Einen S3-Bucket, Google-Cloud oder eine Redis-Schicht über deinem Speicher?

$CFG->mod_hvp_file_storage_class

Mit der Variable mod_hvp_file_storage_class kannst du als String den PHP-Namen der Klasse angeben, die H5Ps File-Storage-Interface implementiert. Standardmäßig ist das "\mod_hvp\file_storage". Deine eigene Klasse muss natürlich dieselben Interface-Methoden implementieren, um Dateien zu lesen, zu schreiben, zu löschen, aufzulisten usw.

Konfiguration von Bibliotheken

Alle H5P-Inhaltstypen bringen ihre eigenen Optionen mit, die in einer semantics.json-Datei definiert sind. Wenn dir zum Beispiel die Standardwerte nicht gefallen oder du eine der Einstellungen verstecken willst, kannst du H5Ps alter_semantics-Hook nutzen (der zusammen mit seinen Geschwistern einen eigenen Beitrag wert ist). So kannst du die Optionen im H5P-Editor ändern, in dem Inhalte erstellt und bearbeitet werden.

Aber was, wenn du das (dynamisch) ändern willst, ohne dass beim Erstellen etwas eingestellt wird? Oder wenn du die getroffenen Einstellungen überschreiben willst, ohne sie tatsächlich in den Parametern zu verändern? Dann gibt es zumindest theoretisch einen Weg. Und wieder verwende ich den Konjunktiv …

$CFG->mod_hvp_library_config

Mit der Einstellung mod_hvp_library_config könntest du das Standardverhalten bestimmter H5P-Bibliotheken überschreiben oder erweitern, ohne den Quelltext der Bibliothek selbst anzufassen. Der Wert müsste ein verschachteltes assoziatives Array sein, mit den „machine names“ von H5P als Schlüsseln auf oberster Ebene, gefolgt von der Semantics-Struktur, die du überschreiben willst.

Zum Beispiel könntest du ['H5P.Video' => ['playback' => ['autoplay' => true]]] verwenden, um Autoplay für alle Videos einzuschalten. Wenn du den Wert serverseitig berechnest, ließe sich das Ganze auch dynamisch gestalten und beispielsweise die Anzahl der Fragen ändern, die aus dem Pool eines QuestionSets angezeigt werden – anhand von Kriterien, die du selbst festlegst.

ABER … Damit das funktioniert, müssten die H5P-Bibliotheken die Funktion H5P.getLibraryConfig nutzen. Das tut leider nur MathDisplay, das zum Rendern von LaTeX-Code verwendet wird.

Die MathJax-Bibliothek erwartet unter renderer.mathjax.config ein Objekt mit der MathJax-Konfiguration, die dann die Standardeinstellungen überschreibt. Damit wird zum Beispiel das Kontextmenü aktiviert, das bei einem Rechtsklick auf Formeln oder Symbole erscheint (standardmäßig deaktiviert):

$CFG->mod_hvp_library_config = [
  'H5P.MathDisplay' => [
    'renderer' => [
      'mathjax' => [
        'config' => [
          'options' => [
            'enableMenu' => true,
          ],
        ],
      ],
    ],
  ],
];

Effektiv dient mod_hvp_library_config also bislang nur dazu, das LaTeX-Rendering mit MathJax anzupassen.