Update-Management
Update-Schritte
Schilderung typischer to-dos und Abläufe für Moodle-Updates
Moodle-Updates gliedern sich in folgende typischen Phasen, wobei auf dieser Wiki-Seite vor allem technische Themen dokumentiert werden sollen:
- Sichten neuer Funktionen und UI-Änderungen
- Installieren und Konfigurieren auf Testsystem (ggf. mehrfach)
- Testing auf Testsystem
- Dokumentieren der Neuerungen
- Update-Ankündigung
- Generalprobe auf Testsystem
- Update-Durchführung Produktiv-System inkl. DB-Backup + Frontend-config
- Troubleshooting
1. Sichten neuer Funktionen und UI-Änderungen
Liste aller Neuerungen (Beispiel Moodle 5.1): https://moodledev.io/general/releases/5.1
Neue Funktionalitäten / New Features: https://docs.moodle.org/de/Neue_Funktionalit%C3%A4ten / https://docs.moodle.org/en/New_features
YouTube-Videos Moodle: https://www.youtube.com/@moodle/playlists (Videos zu Moodle 5.1)
Dag Klimas macht auch oft Videos zu den neuen Features, z.B. Moodle 5.1 - Was hat sich geändert, was ist neu? und Moodle 5.2 - Was hat sich geändert, was ist neu?
Weekly Releases
Jede Woche werden Moodle-Versionen veröffentlicht, die issues aus dem Tracker (Schema "MDL-12345", siehe Moodle issues) integrieren. Weekly-Releases erhalten ein +-Zeichen am Ende, z.B. 5.2.2+. Einen Überblick dieser Änderungen bietet die "UPGRADING.md", Beispiel für Moodle 5.2: Upgrade-notes in github
Im Moodle Tracker können auch issues beobachtet werden durch Klick aufs Auge-Icon. Zum Nachverfolgen kann die Suche genutzt werden: watcher = currentUser() ORDER BY updated DESC
2. Installieren und Konfigurieren auf Testsystem
3. Testing auf staging
4. Dokumentieren der Neuerungen
5. Update-Ankündigung
- Moodle-Startseite, z.B. mit Boost Union via Banner
- Websites Störungs- und Wartungsmeldungen (z.B. Rechenzentrum)
- Foren / Lehrenden-Foren
- Info-Chats
6. Generalprobe auf Testsystem
Aufs staging-System wird eine Kopie der live-Datenbank eingespielt und sichergestellt, dass die Versions-Dateien auf den Webservern dazu passen. Dann werdendie neuen Dateien eingespielt und der komplette Update-Prozess simuliert.
7. Update-Durchführung Produktiv-System inkl. DB-Backup + Frontend-config
Zuerst ist ein Datenbank-Backup zu erstellen, z.B. mittels pgadmin. Jetzt wird es ernst: Wartungsmodus per CLI aktivieren: sudo -u www_mdl /usr/bin/php admin/cli/maintenance.php –enable
Zugriff für Administratoren während Wartungszeit:
Der Wartungsmodus muss per Frontend gestartet werden (/admin/settings.php?section=maintenancemode) oder via /maintenance.php --enableold, dann können admin-Accounts Moodle weiter nutzen oder sich auch neu einloggen via /login/index.php?username=[Anmeldename]
Wird /cli/maintenance.php aufgerufen, ist die Site auch für admins gesperrt.
Dann wird das live-System mittels vorbereitetem Job aktualisiert. Upgrade per CLI oder im Frontend, dann ist der Aktualisierungsschlüssel einzugeben und der Update-Fortschritt wird verfolgt. Wichtig: auf live dauert es meist deutlich länger als auf den Testsystemen (trotz DB-Kopie), z.B. weil noch mehr Daten im Cache sind. Ist das Update durchgelaufen, sind die vorher definierten Konfigurationsanpassungen im admin-Frontend einzustellen. Zum Abschluss wird der Wartungsmodus wieder deaktiviert (maintenance.php –disable).
Wenn gepflegt, kann noch ein "to-dos nach dem Update" abgearbeitet werden. Zudem sollten minor- und Major-Updates in einem Changelog dokumentiert werden, dazu auch wenn neue Plugins hinzu kamen.
8. Troubleshooting (bei Bedarf)
Sollte etwas nicht wie geplant und im Vorfeld getestet funktionieren: don´t panic! In diesem Fall sind die Debbuging-Methoden anzuwenden. Zudem wie immer auch die debugging- und logging-Meldungen sichten. im Normalfall fallen die Probleme bereits im Testing auf, weshalb ein sorgfältiges Testen mit einer möglichst identischen live-System-Kopie wichtig ist.
Hier ein Beispiel.
Aktivieren Debug-Modus mittels config.php
//=========================================================================
// 7. SETTINGS FOR DEVELOPMENT SERVERS - not intended for production use!!!
//=========================================================================
//
// Force a debugging mode regardless the settings in the site administration@error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
@ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
$CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
$CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
Hinweis: E_STRICT ist ab PHP 8.4 deprecated und wird dereinst nicht mehr setzbar sein.
SQL-Abfragen anzeigen:
$CFG->upgradeshowsql = true;
Dadurch werden alle SQL-Befehle während des Upgrades ausgegeben und wie lange sie geladen haben ("Query took"), das sieht dann in der Konsole z.B. so aus:
--------------------------------
DECLARE crs7 NO SCROLL CURSOR WITH HOLD FOR SELECT * FROM mdl_capabilities
[array (
)]
--------------------------------
Query took: 0.00043296813964844 seconds.
--------------------------------
Links / Quellen
https://docs.moodle.org/de/Aktualisierung_von_Moodle
Autor: Klaus Steitz, TU Darmstadt
Docker
Mit Docker kann Moodle lokal installiert werden, siehe auch Lokales Moodle: moodle-docker auf github
Es kann aber neben Entwicklung auch für den produktiven Moodle-Betrieb genutzt werden. Niels Gandraß hat auf dem Hochschultreffen 2026 präsentiert, wie dies aussehen kann.
Agile Moodle Updates with Docker and GitLab CI
Die flexible und zugleich zuverlässige Verwaltung mehrerer Moodle-Plattformen in Entwicklungs-, Staging- und Produktionsumgebungen birgt verschiedene betriebliche Herausforderungen. Die Präsentation zeigt den Weg von einem klassischen manuellen Ansatz zu einem vollständig containerisierten Anwendungsstack. Die Containerarchitektur reicht von Moodle selbst bis hin zu spezifischen Worker-Diensten, wie beispielsweise GoeMaxima für den Fragetyp „STACK“. Software- und Plugin-Versionen werden in umgebungsspezifischen Konfigurationsdateien festgehalten, die in einem Git-Repository versioniert sind und schließlich in eine automatisierte GitLab-CI-Build-Pipeline einfließen, die bereitstellungsfertige Container erzeugt. Die Implementierung zeigt, wie Containerisierung und Automatisierung den Wartungsaufwand drastisch reduzieren, Bereitstellungsfehler minimieren und ein agiles Moodle-Plattformmanagement mit Upgrade-Ausfallzeiten von weniger als 60 Sekunden ermöglichen.
https://gandrass.de/#pub-Gandrass2026MoodleDocker
Down with the Downtime: Agile Moodle Updates with Docker and GitLab CI (31 Seiten, PDF)
Autor: Klaus Steitz, Technische Universität Darmstadt
Erfahrungssammlung von Problemen bei Major-Updates
Probleme beim Upgrade auf Moodle 5.x
Ein Moodle Upgrade auf eine neue Major-Version bringt meistens bedeutende Änderungen mit sich, die bei bestehenden Systemen zu Problemen führen können, vor allem wenn Plugins nicht angepasst wurden.
Upgrade von 5.1 auf 5.2
"Lesson learned vom Moodle 5.1 -> 5.2 Update. Die Beschreibungstexte von Subsections wurden nicht automatisch in Textfelder umgewandelt, sondern der Task musste händisch gestartet werden. Das ist in den Einstellungen der Subsections möglich (Plugins > Unterabschnitte > Task auswählen). Mir war das aus der Beschreibung hier (https://docs.moodle.org/502/en/Upgrading#Subsections_removals) nicht klar und vielleicht hilft es ja anderen :) Marie Hennings im MaH D-A-CH Matrix Channel"
Direktlink: /admin/settings.php?section=mod_subsection_settings
mod_hvp (Stand August 2026)
Es gibt noch keine veröffentlichte Version für Moodle 5.x: https://marketplace.moodle.com/plugins/1406/versions
Offizielles Repository: https://github.com/h5p/moodle-mod_hvp
Man kann alternativ Moodle5-kompatible Forks nutzen, z.B. https://github.com/lucaboesch/moodle-mod_hvp oder https://github.com/catalyst/moodle-mod_hvp
Ausgewählte Diskussionskanäle:
H5P Group sucht Co-Maintainer:innen
Probleme nach H5P-Update in Zusammenhang mit Mathjax
H5P: mod_hvp vs mod_h5pactivity (Core)
Informationen zur AG H5P
question bank
- https://docs.moodle.org/500/en/Question_banks_in_upgraded_sites
- Video von Rick Jerz: https://www.edu-gen.com/profession/presentations/Moodle_5_Question_Banks/M5-QB.html
-
Fix-Skripte zum Aufräumen von Duplikaten vorm Upgrade laufen lassen: https://moodle.hu-berlin.de/mod/forum/discuss.php?d=1121146#p1907886
- "Ein Tipp noch, wer seine Kurse wie wir semestriert und z.B. SS25:xyz nennt, dem kann ich empfehlen, die Namen der q-banks anzupassen, hier wird nämlich der fullname hergenommen, was von der Logik für den Benutzer zur Verwirrung führen kann. Denn, wenn Inhalte vom Kurs SS25 in den WS25 Kurs importiert werden, dann heißt die Aktivität q-bank dann SS25:xyz im WS25'er Kurs." (Susanne Schenk in "Wann auf Moodle 5 aktualisieren + Update-Pläne")
- Fragen aus Quiz löschen, auch ohne Rechte auf die Fragensammlung: https://moodle.hu-berlin.de/mod/forum/discuss.php?d=1163032 und https://forum.moodle-an-hochschulen.de/mod/forum/discuss.php?d=19
- Video "Upgrade einer Fragensammlung von Moodle 4.5.4 nach 5.0" von Dag Klimas
- Video "Die neuen ‘Fragensammlungen‘ überblicken" von Dag Klimas
Plugin-Verhalten nicht-unterstützter Versionen
Die meisten Plugins laufen auch unter Moodle 5, wenn es nicht explizit eine 5er-Version gibt. Wie immer ist in solchen Fällen kritisch zu prüfen, ob das Plugin Probleme verursacht, da es ohne Moodle5-Version schon über ein Jahr lang kein Update mehr erhalten hat.
Marketplace-Link im Activity chooser ausblenden
In der Aktivitätsauswahl (Activity chooser) erscheint im Footer per Standard ein Marketplace-Link mit dem Text "Suchen Sie weitere Aktivitäten auf dem Moodle Marktplatz". Um diesen auszublenden, gibt es das admin-Setting "activitychooseractivefooter":
"Website-Administration -> Kurse -> Einstellungen der Aktivitätsauswahl" (/admin/settings.php?section=activitychoosersettings)
Es kann auch dauerhaft gesetzt werden, ohne dass es bei Updates zurückgesetzt werden kann, via config.php:
$CFG->activitychooseractivefooter = 'hidden';
Links / Quellen
Autorin: Melanie Treitinger, Ruhr-Universität Bochum