Update-Management

• Update-Schritte
• Docker

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:

1. Sichten neuer Funktionen und UI-Änderungen
2. Installieren und Konfigurieren auf Testsystem (ggf. mehrfach)
3. Testing auf Testsystem
4. Dokumentieren der Neuerungen
5. Update-Ankündigung
6. Generalprobe auf Testsystem
7. Update-Durchführung Produktiv-System inkl. DB-Backup + Frontend-config
8. 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?

2. Installieren und Konfigurieren auf Testsystem

3. Testing auf staging

4. Dokumentieren der Neuerungen

5. Update-Ankündigung

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