Weiße Seite — Drupal protokolliert mehr als die meisten.

Erst einordnen.

Die entscheidende Frage lautet wie immer: Was wurde zuletzt geändert? Bei Drupal kommt eine zweite dazu: Wurde Konfiguration importiert? Das ist ein eigener Vorgang mit eigenen Fehlerquellen.

Die drei Quellen.

Das Serverprotokoll beim Hoster enthält Fehler, die auftreten, bevor Drupal startet — Syntaxfehler, Speicherüberschreitungen, Rechteprobleme. Das ist die erste Anlaufstelle bei einer vollständig weißen Seite.

Das Drupal-Protokoll liegt je nach Einrichtung in der Datenbank oder als Dateien im Dateisystem. Die Datenbankvariante ist bequem, aber bei einem Totalausfall nicht erreichbar — deshalb ist die Dateivariante für den Ernstfall die bessere Wahl.

Der Statusbericht im Backend ist bei Drupal ungewöhnlich aussagekräftig: Er meldet fehlende Aktualisierungen, Konfigurationsprobleme, Rechteprobleme, veraltete Module und Sicherheitshinweise an einer Stelle. Wenn das Backend noch läuft, ist das der schnellste Weg zur Diagnose.

Fehleranzeige aktivieren.

Drupal unterdrückt Fehlermeldungen im Produktivbetrieb. Für die Fehlersuche lässt sich das über eine lokale Einstellungsdatei umstellen — dort wird festgelegt, dass Meldungen angezeigt und ausführliche Fehlerseiten erzeugt werden.

Diese Datei ist bei Drupal ohnehin der richtige Ort für umgebungsabhängige Einstellungen: Sie wird von der Hauptkonfiguration eingebunden, wenn sie vorhanden ist, und gehört nicht in die Versionsverwaltung.

Zwei Regeln: nur vorübergehend, und nicht auf einem öffentlich erreichbaren System ohne Zugangsbeschränkung. Die Meldungen verraten Pfade, Versionen und Konfigurationsdetails (Debug-Modus).

Der Zwischenspeicher.

Bei Drupal die häufigste Ursache nach Änderungen — und zugleich das häufigste Mittel. Drupal speichert aufbereitete Konfiguration, kompilierte Dienste, Routen und Vorlagen zwischen. Ein widersprüchlicher Zustand führt zuverlässig zu Abbrüchen.

Das Leeren geht über die Kommandozeile, über das Backend oder notfalls über das Dateisystem beziehungsweise die Datenbanktabellen. Die Kommandozeile ist der verlässlichste Weg und funktioniert auch dann, wenn das Backend nicht mehr lädt.

Ein Drupal-Eigenheit: Nach dem Hinzufügen oder Entfernen von Modulen, nach Änderungen an Diensten und nach Code-Änderungen ist das Leeren nicht optional, sondern notwendig. Wer das vergisst, sucht Fehler, die keine sind (Cache leeren).

Nach einem Update.

1. Zwischenspeicher leeren, am besten über die Kommandozeile.
2. Datenbankaktualisierung ausführen — wurde sie gemacht?
3. Protokoll lesen und die genannte Datei einem Modul zuordnen.
4. Statusbericht ansehen, sobald das Backend wieder läuft.
5. Verdächtiges Modul deaktivieren.
6. Theme testweise auf ein Kerntheme umstellen.

Schritt zwei ist bei Drupal besonders wichtig: Wenn die Datenbankaktualisierung nach einem Code-Update nicht gelaufen ist, passen Code und Datenbankstruktur nicht zusammen — und das äußert sich in schwer zuzuordnenden Fehlern (Update durchführen).

Modul eingrenzen.

Wenn das Backend läuft, lassen sich Module dort einzeln deaktivieren. Einzeln, nicht alle auf einmal — sonst weiß man hinterher nicht, welches es war.

Ohne Backend geht es über die Kommandozeile: Module lassen sich dort deaktivieren, ohne die Weboberfläche zu brauchen. Das ist der große Vorteil eines Systems mit ordentlichem Kommandozeilenwerkzeug.

Ohne beides bleibt der Eingriff über die Datenbank in der Tabelle der aktivierten Erweiterungen — unschön, aber im Notfall gangbar. Danach unbedingt den Zwischenspeicher leeren, sonst wirkt die Änderung nicht.

Ohne erkennbaren Anlass.

• Festplatte voll? Drupals Protokolle und Zwischenspeicher wachsen (Webspace voll).
• Datenbank antwortet nicht oder Verbindungsgrenze erreicht.
• Hoster hat umgestellt — PHP-Version, Grenzen, Module.
• Viele gleichzeitige Zugriffe lassen Grenzen reißen.
• Zeitgesteuerte Aufgabe läuft fehl und blockiert.

Der letzte Punkt ist bei Drupal relevant: Die Wartungsaufgaben erledigen Indexierung, Aufräumarbeiten und Warteschlangen. Wenn eine davon in einer Endlosschleife hängt, bindet sie Ressourcen — und das äußert sich als Trägheit oder Abbruch.

Speicher und Laufzeit.

Drupal braucht mehr Arbeitsspeicher als einfachere Systeme — das ist kein Fehler, sondern Folge der Architektur. Typische Stellen, an denen Grenzen reißen: Datenbankaktualisierungen, Konfigurationsimporte, Abhängigkeitsauflösung, Bildverarbeitung, große Ansichten.

Beides lässt sich anheben, oft in der lokalen Einstellungsdatei oder beim Hoster. Wichtig ist, die Grenze nicht blind zu verdreifachen, sondern zu fragen, warum sie gerissen wird (Speicherlimit).

Bei langlaufenden Vorgängen gilt: über die Kommandozeile ausführen statt über den Browser. Dort gelten andere Grenzen, und der Vorgang bricht nicht mitten in einer Aktualisierung ab.

Datenbank.

Fehlende Verbindung meldet Drupal deutlich. Weiße Seiten entstehen eher durch Strukturprobleme: eine nicht ausgeführte Datenbankaktualisierung, eine abgebrochene Aktualisierung, die einen halben Zustand hinterlässt, oder eine beschädigte Tabelle.

Ein Drupal-spezifischer Fall: Wenn eine Aktualisierung mittendrin abbricht, steht das System zwischen zwei Zuständen. Dann hilft meist nur das Zurückspielen der Sicherung und ein erneuter Versuch über die Kommandozeile — deshalb die Sicherung vorher (Datenbank).

Konfiguration.

Ein Thema, das es bei anderen Systemen so nicht gibt. Drupal hält Konfiguration in der Datenbank, synchronisiert sie aber mit Dateien, die sich versionieren lassen.

Fehlerquellen daraus: Ein Konfigurationsimport, der Einträge für Module enthält, die nicht installiert sind. Verwaiste Konfiguration entfernter Module. Eine Abweichung zwischen Dateien und Datenbank. Oder eine Unverträglichkeit, weil die Konfiguration aus einer anderen Umgebung stammt.

Prüfen lässt sich das über den Konfigurationsabgleich: Er zeigt, was sich zwischen Dateien und aktivem Zustand unterscheidet. Das ist ein mächtiges Werkzeug — und eine Fehlerquelle, wenn es unsauber eingesetzt wird.

Der Prüfweg.

1. Was wurde zuletzt geändert? Code, Module, Konfiguration?
2. Serverprotokoll lesen.
3. Zwischenspeicher leeren über die Kommandozeile.
4. Datenbankaktualisierung ausführen.
5. Statusbericht ansehen, sobald erreichbar.
6. Fehleranzeige aktivieren, wenn nötig und abgesichert.
7. Modul eingrenzen, einzeln.
8. Theme testweise auf ein Kerntheme.
9. Festplattenplatz und Grenzen prüfen.
10. Sicherung einspielen, wenn das Geschäft nicht warten kann.

Die Schritte drei und vier zusammen lösen bei Drupal einen erheblichen Teil der Fälle — und sie dauern mit Kommandozeilenzugriff zusammen keine zwei Minuten. Das ist das stärkste Argument dafür, diesen Zugriff zu haben.

Wenn du nicht weiterkommst.

Wenn nichts mehr geht und du keinen Kommandozeilenzugriff hast. 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.