Drupal im Betrieb — planbar, wenn man dem Takt folgt.

Der Rhythmus.

Drupal veröffentlicht in festen Abständen: Nebenversionen in planbaren Fenstern, Hauptversionen in bekanntem Abstand, Sicherheitsmeldungen an festgelegten Wochentagen. Entfernungen werden vorher angekündigt.

Das ist eine Qualität, die man erst schätzt, wenn man Systeme kennt, bei denen Updates überraschend kommen. Für die Betreuung heißt es: Man kann Termine setzen, statt zu reagieren.

Die typische Eskalation entsteht nur, wenn man dem Takt nicht folgt: zwei Jahre nichts, dann läuft die Hauptversion aus, der Hoster stellt PHP um, und alles fällt gleichzeitig an (Fristen).

Updates.

Alles über die Abhängigkeitsverwaltung, nie per Dateiaustausch. Danach Datenbankaktualisierung und Zwischenspeicher leeren — beides gehört zum Vorgang und wird gern vergessen (Update durchführen).

Die Update-Benachrichtigung per Mail einzuschalten ist eine Minute Arbeit und der wirksamste Einzelschritt. Dazu die Sicherheitsmeldungen abonnieren.

Zeitgesteuerte Aufgaben.

Drupal hat Aufgaben, die regelmäßig laufen müssen: Suchindex aktualisieren, Protokolle aufräumen, Warteschlangen abarbeiten, zwischengespeicherte Daten verwerfen, geplante Veröffentlichungen ausführen.

Diese laufen nur, wenn sie angestoßen werden. Drupal kann das beim Seitenaufruf tun — das ist bequem und unzuverlässig: Auf einer Seite mit wenig Verkehr läuft es unregelmäßig, und mit einem Seiten-Cache davor praktisch nie.

Richtig ist ein echter Cronjob auf dem Server. Die Folgen des Fehlens sind unauffällig und summieren sich: Die Suche findet neue Inhalte nicht, Protokolltabellen wachsen unbegrenzt, Warteschlangen stauen sich, geplante Veröffentlichungen erscheinen verspätet.

Prüf einmal, wann die letzte Ausführung war — das steht im Statusbericht. Ein Datum von vor Monaten ist ein Befund.

Konfiguration versionieren.

Der Punkt, der Drupal im Betrieb von anderen Systemen unterscheidet. Konfiguration — Inhaltstypen, Felder, Ansichten, Einstellungen — lässt sich als Dateien exportieren, in die Versionsverwaltung legen und zwischen Umgebungen übertragen.

Was das praktisch bringt:

• Nachvollziehbarkeit: Wer hat wann was geändert, und warum?
• Reproduzierbarkeit: Derselbe Zustand lässt sich auf jeder Umgebung herstellen.
• Testbarkeit: Änderungen erst in der Testumgebung, dann live — ohne Nachklicken.
• Rückweg: Eine fehlerhafte Änderung lässt sich zurücknehmen.
• Wiederaufbau nach einem Vorfall wird reproduzierbar statt rekonstruiert.

Wer das nicht nutzt, arbeitet bei Drupal unter seinen Möglichkeiten — und hat bei jedem Versionssprung und jedem Zwischenfall deutlich mehr Arbeit (Konfigurationsprobleme).

Die Einrichtung ist einmalig: Exportverzeichnis festlegen, erster Export, in die Versionsverwaltung aufnehmen. Danach gehört zu jeder Änderung ein Export.

Sicherungen.

1. Dateien und Datenbank — beides.
2. Das private Dateiverzeichnis nicht vergessen (Private Dateien).
3. Mehrere Stände, weil Schäden verzögert auffallen.
4. Außerhalb des Servers.
5. Automatisch.
6. Rückspielung einmal geprobt.

Punkt zwei ist Drupal-spezifisch und wird regelmäßig übersehen: Das private Verzeichnis liegt außerhalb des Webverzeichnisses, und eine Sicherung, die nur dieses erfasst, ist unvollständig.

Ein praktischer Hinweis: Vor dem Datenbankexport den Zwischenspeicher leeren — das macht die Sicherung deutlich kleiner und schneller (Backups).

Überwachung.

• Erreichbarkeit mit Benachrichtigung.
• Statusbericht regelmäßig ansehen — er meldet das meiste von selbst.
• Letzte Ausführung der zeitgesteuerten Aufgaben.
• Protokoll auf auffällige Einträge.
• Zertifikat und Domain vor Ablauf (SSL).
• Benutzerliste auf unbekannte Konten.
• Mailversand mit gelegentlichem Test.

Punkt zwei ist bei Drupal die effizienteste Form der Überwachung überhaupt — dazu gleich mehr.

Der Statusbericht.

Eine Drupal-Stärke, die kaum genutzt wird. Der Bericht meldet an einer Stelle: ausstehende Updates, Sicherheitshinweise, nicht ausgeführte Datenbankaktualisierungen, Rechteprobleme, fehlende Verzeichnisse, Konfigurationsabweichungen, Zeitpunkt der letzten Wartungsausführung, PHP-Version und mehr.

Das ist eine vollständige Betriebsübersicht, die andere Systeme in dieser Form nicht haben. Einmal im Monat hineinzusehen ersetzt einen Großteil anderer Kontrollen.

Mein Rat: Setz dir eine monatliche Erinnerung. Wenn dort alles grün ist, ist das System in Ordnung — und wenn nicht, steht dort im Klartext, was fehlt.

Versionsplanung.

Drupal macht es einem leicht, weil die Termine bekannt sind. Was dazugehört:

1. Enddatum der aktuellen Hauptversion im Kalender.
2. Vorab-Analyse regelmäßig laufen lassen, nicht erst kurz vorher.
3. Veraltete Schnittstellen laufend abarbeiten, solange die alte Fassung läuft.
4. Modulstand im Blick behalten.
5. PHP-Pfad mit dem Hoster klären.
6. Sprung terminieren, wenn die Pflege ausläuft, nicht wenn die Sicherheitsupdates enden.

Punkt zwei und drei sind der eigentliche Trick bei Drupal: Wer die Analyse direkt nach einem Sprung erneut laufen lässt und die Hinweise über die folgenden zwei Jahre abarbeitet, macht aus dem nächsten Hauptversionssprung eine Formalie.

Aufräumen.

Einmal im Jahr, am besten vor einem geplanten Sprung:

• Module durchgehen — genutzt, gepflegt, vom Sicherheitsteam abgedeckt?
• Prüfen, was der Kern inzwischen kann.
• Verwaiste Konfiguration entfernter Module bereinigen.
• Hinterlegte Korrekturen prüfen — noch nötig?
• Entwicklungsmodule im Produktivbetrieb entfernen.
• Benutzerliste und Rechte durchsehen.
• Ungenutzte Inhaltstypen und Felder entfernen.
• Protokolltabellen auf Größe prüfen.

Punkt zwei ist bei Drupal besonders ergiebig: Es werden regelmäßig verbreitete Module in den Kern übernommen. In gewachsenen Installationen finde ich meist drei bis fünf, die dadurch überflüssig geworden sind (Module).

Was du selbst machen kannst.

• Statusbericht monatlich ansehen — das ist der wichtigste Punkt.
• Benutzerliste prüfen.
• Update-Benachrichtigungen nicht wegklicken.
• Testformular einmal im Monat absenden.
• Inhaltliches Aufräumen.

Der erste Punkt genügt fast. Drupals Statusbericht ist so aussagekräftig, dass ein monatlicher Blick den Großteil aller Probleme früh zeigt — und zwar in verständlicher Sprache.

Was ich übernehme.

1. Updates für Kern und Module, mit Sicherung und Testlauf.
2. Sicherheitsmeldungen verfolgen und reagieren.
3. Zeitgesteuerte Ausführung einrichten und überwachen.
4. Konfiguration versionieren und den Ablauf einrichten.
5. Sicherungen einrichten, prüfen, Rückspielung proben.
6. Statusbericht regelmäßig durchgehen.
7. Versionsplanung und laufende Vorab-Analyse.
8. Jährliches Aufräumen.

Was gesondert läuft: Hauptversionssprünge, Migrationen von Drupal 7, größere Umbauten, neue Funktionen und die Bereinigung nach einem Vorfall. Das sage ich vorher, damit es keine Überraschung gibt.

Punkt vier ist der, der sich am stärksten auszahlt: Eine Drupal-Installation mit versionierter Konfiguration ist deutlich günstiger zu betreuen als eine ohne — bei jedem Update, jedem Test und jedem Zwischenfall.

Wenn du nicht weiterkommst.

Wenn du dich nicht selbst darum kümmern willst oder nicht weißt, ob dein Drupal überhaupt gepflegt wird. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Bei einem laufenden Ausfall hilft der Notfall-Support, dauerhaft begleitet die Drupal-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management-Systeme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme nicht nur aus der Anwendung, sondern von innen: Datenmodell, Rechtekonzept, Templating, Modularchitektur, Caching, Betrieb.

Bei Drupal zahlt sich das besonders aus, weil das System konsequenter durchkonstruiert ist als die meisten anderen: Alles ist Entität, alles hat Felder, alles läuft über definierte Schnittstellen. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo eine Installation gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob deine Installation weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.