Moodle-Plugins

Hier werden sowohl Plugins vorgestellt, die im Moodle Plugin Verzeichnis veröffentlicht wurden, als auch solche, die nur in Github gepflegt werden.

Plugin tool_userdebug

Moodle Admins können den Debug-Modus immer aktivieren. Anderen Nutzern kann man für ihre (globale) Rolle die Capability tool/userdebug:adhocdebug geben (Adhoc Debugging) oder sie fest in die Liste der Debug-User eintragen (Permanent Debugging).

Ressourcen

"With this plugin you can define the debugmode for only some selected users."

https://moodle.org/plugins/tool_userdebug

https://github.com/grabs/moodle-tool_userdebug 

Konfiguration

Capability setzen

Die Capability tool/userdebug:adhocdebug muss für eine Globale Rolle vergeben werden, damit sie einen Effekt hat!

💡Wenn die Capability gesetzt ist, funktioniert der Debug-Modus auch wenn loginas genutzt wird!

Plugin Einstellungen

Website-Administration -> Entwicklung -> Nutzerbezogener Debug-Modus

Zunächst kann man einstellen, wie sich das Plugin verhält, wenn man es aktiviert:

grafik.png

Adhoc Debugging

Nutzungsmöglichkeiten:

A) Debugging via URL Param: &userdebug=1

B) Aktivieren über das "Käfer"-Symbol in der Menüleiste: 

grafik.png

C) Aktivieren über die Nutzer-Einstellungen:

grafik.png

Permanent Debugging

Website-Administration -> Entwicklung -> Nutzerbezogener Debug-Modus

grafik.png

Dies aktiviert den Debug-Modus für die ausgewählten User dauerhaft.


Autorin: Melanie Treitinger, Ruhr-Universität Bochum 

User lifecycle Plugins

Eine Übersicht von Plugins zu Aufräumstrategien für Accounts findet sich im Artikel 
user-lifecycle

Plugin mod_coursesearch

Das Plugin "Course Search" ist eine Aktivität, mit der man die Inhalte eines Kurses durchsuchen kann.

Plugin "Course Search"

Wenn man das Plugin im Kurs hinzufügt, erhält man je nach Einstellung zwei Suchfelder.

Zum einen gibt es ein klassisches Suchfeld im Kurs an der Stelle, an der man die Aktivität eingefügt hat.

Zum anderen gibt es rechts unten über dem "Fragezeichen" noch eine Lupe, die beim Draufklicken ebenfalls ein Suchfeld öffnet.

grafik.png

Die Ergebnisse werden übersichtlich auf einer eigenen Seite dargestellt:

grafik.png

Die Einstellungen des Plugins:

grafik.png

Nachteil

Das Plugin kann nur die folgenden Standard-Aktivitäten eines Kurses durchsuchen:
Pages, Forums, Books, Labels, Wiki, Lessons, Glossary, Database, H5P, Folders

https://marketplace.moodle.com/plugins/3495 

https://github.com/lysak-yurii/moodle-mod_coursesearch 


Autorin: Melanie Treitinger, Ruhr-Universität Bochum

Plugin local_csp

Das Plugin local_csp erlaubt das Prüfen und Erzwingen von HTTP-Headern nach der "Content Security Policy (CSP)"

Content Security Policy (CSP)

Das Plugin ermöglicht es, das Setzen von bestimmten Headern auf einer Moodle-Instanz zu beobachten und die Auswirkungen zu sammeln. Man kann die gewünschten Header anschließend auch setzen.

Das Plugin setzt zum Prüfen den Content-Security-Policy-Report-Only Header. Dieser Header hat u.a. als Parameter einen Endpoint, also eine URL: in der Datei /local/csp/collector.php werden die Daten per POST-Request entgegengenommen und in eine Tabelle geschrieben.    

Ein Scheduled Task (cleanup_csp_task) räumt die Tabelle nach der eingestellten Zeit wieder auf (Standard 26 Wochen: local_csp | cleanup_duration).

Zusätzlich zu den "Content Security Policy (CSP)"-Headern erlaubt das Plugin auch das Setzen von "Feature-Policy"-Headern. Hierbei handelt es sich um eine experimentelle Technologie (siehe "Permissions Policy"), mit der kontrolliert werden kann, welche Eigenschaften des Browsers eine Webseite nutzen darf. 

Anzeige von Warnmeldungen

Mit der Einstellung local_csp | notifications_enable_reported werden gelbe Kästchen auf jeder Webseite eingeblendet, die über die potentiellen Auswirkungen der aktuell gesetzten Header informieren.

Die Anzeige dieser Warnmeldungen ist an die Capability local/csp:seenotifications geknüpft, die standardmäßig für die Rollen teacher, editingteacher und manager gesetzt ist. 

localcsp_warnings.png

Report

Wie oben erwähnt sammelt das Plugin über den Endpoint des Headers alle Daten in einer Tabelle. Deren Inhalt kann man sich über den "CSP violation report" ansehen:

localcsp_violationreport.png

Einstellungen

Mit der Einstellung local_csp | csp_header_enable aktiviert man das Reporting. 

Folgende Direktiven schlägt das Plugin standardmäßig vor: 


localcsp_settings.png

https://github.com/catalyst/moodle-local_csp 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy-Report-Only 

https://moodle.org/mod/forum/discuss.php?d=460784 - hier gibt es einen Vorschlag für ein Set an Headern


Autorin: Melanie Treitinger, Ruhr-Universität Bochum

Plugin tool_monitoring

Beliebige Moodle Instanzen mit einem Monitoring Setup (wie Prometheus & Grafana) verbinden.

Grafana Dashboard

Das Plugin findet man auf Github und im Moodle Marketplace.

Features

Admin Dashboard

Das Admin Dashboard findet man unter /admin/tool/monitoring oder indem man über Website-Administration > Plugins > Dienstprogramme > Monitoring > Übersicht navigiert.

Metrics Overview

Siehe Dokumentation für die vorinstallierten Metriken und die Labels nach denen diese aufgeteilt sind.

Metric Config users_online

Der Prometheus Endpoint selbst ist direkt erreichbar und kann über die Route /monitoringexporter_prometheus/metrics abgerufen werden.

Warnung: Der Endpoint ist standardmäßig ungesichert. Solange kein prometheus_token gesetzt ist, sieht jeder, der die URL aufrufen kann, alle aktivierten Metriken ohne Zugangsbeschränkung. Obwohl standardmäßig alle neu registrierten Metriken deaktiviert sind, sollte zur Sicherheit ein Token gesetzt werden.

Metrics mit Tags gruppieren (optional)

tool_monitoring erlaubt es, Metriken mittels der Moodle's Tag API ganz leicht zu gruppieren. Man kann jeder Metrik beliebige Tags zuweisen (die ihren eigenen Schlagwortbereich haben). Exporter können dann über einen Parameter die auszuliefernden Metriken nach ihren Tags filtern. Zum Beispiel akzeptiert der mitgelieferte Prometheus Exporter einen tag Query Parameter in der URL. Wird ein einzelner Tag Name übergeben, filtert dieser all Metriken raus, die nicht mit diesem Tag versehen sind. Wird eine kommagetrennte Liste von Tags übergeben, werden nur die Metriken exportiert, die mit allen diesen Tags versehen sind. (Zu beachten ist die UND-Verknüpfung, die hier angewendet wird.) Für Details zur Implementierung, siehe die Prometheus exporter Klasse.

Um eine Metrik mit Tags zu versehen, muss man auf ihre Konfigurationsseite gehen und dann einfach die Tag Namen in das "Tags" Feld eingeben.

Metric Config Tags users_online

Metrics Overview Tags

Ein Klick auf einen Tag filtert die Liste der Metriken entsprechend.

Metrics Overview Tags filtered

Prometheus configuration

scrape_configs:
  # Einen beliebigen einzigartigen Job Namen wählen.
  - job_name: moodle
    # Standard ist HTTP.
    scheme: https
    # Wenn ein Zugangstoken gesetzt wurde, diesen hier angeben.
    authorization:
      credentials: 'super-secure-secret'
    # Den vollständigen Endpoint Pfad angeben. Standard ist sonst einfach '/metrics'.
    # Wenn das Moodle Routing nicht vollständig konfiguriert wurde, muss noch '/r.php' vorangestellt werden.
    metrics_path: /monitoringexporter_prometheus/metrics
    # Ziel Host angeben.
    static_configs:
      - targets: ['example.com']

Ein Grafana Dashboard aufsetzen

Dies setzt voraus, dass eine Prometheus Konfiguration wie oben bereits besteht. Ein beispielhaftes Grafana Dashboard kann von docs/examples/grafana_dashboard.json in Grafana importiert werden:

Dazu nach "Dashboards" > "Neu" navigieren und "importieren" auswählen und die json-Datei auswählen oder deren Inhalt dort hineinkopieren. Dann die Prometheus Datenquellen auswählen und auf "importieren" klicken.

Dokumentation

Die Installationsanweisungen, Anleitungen zum Hinzufügen eigener Metriken und Exporter sub-Plugins und die vollständige Dokumentation findet man in der README.

© 2025 Daniel Fainberg, Martin Gauk, Sebastian Rupp, Malte Schmitz, Melanie Treitinger

Code, Tests und Dokumentation von und für Menschen geschrieben. 🚫🤖


Autor: <Daniel Fainberg, TU Berlin>