Drupal-Cache — mächtig, und manchmal im Weg.

Die Ebenen.

Die ersten vier verwaltet Drupal weitgehend selbst. Der Punkt, an dem man eingreifen muss, ist die erste Zeile — alles, was mit Code, Modulen und Konfiguration zu tun hat.

Cache-Tags.

Das Konzept, das Drupals Zwischenspeicherung von der anderer Systeme unterscheidet. Jeder zwischengespeicherte Bestandteil bekommt Markierungen, die sagen, wovon er abhängt — von einem bestimmten Inhalt, einer Konfiguration, einer Liste.

Ändert sich etwas, werden alle Einträge mit der passenden Markierung ungültig. Das heißt: Wer einen Beitrag ändert, leert nicht den ganzen Zwischenspeicher, sondern genau die Bestandteile, die diesen Beitrag zeigen — einschließlich Übersichten und Blöcken.

Deshalb ist bei Drupal im redaktionellen Alltag praktisch nie ein manuelles Leeren nötig. Wenn es doch nötig scheint, ist das ein Hinweis: Dann fehlen in eigenem Code oder in einem Modul die richtigen Markierungen (Module).

Wege zum Leeren.

1. Kommandozeile: ein Befehl, leert alles, funktioniert auch ohne Backend. Der Standardweg.
2. Backend: ein Knopf im Leistungsbereich. Bequem, braucht eine funktionierende Oberfläche.
3. Dateisystem und Datenbank: Notfall, siehe unten.

Die Kommandozeile ist bei Drupal nicht Komfort, sondern Arbeitsgrundlage. Viele Vorgänge — Zwischenspeicher, Datenbankaktualisierung, Konfigurationsimport, Modulverwaltung — laufen dort deutlich zuverlässiger als über den Browser, weil andere Laufzeitgrenzen gelten.

Wenn dein Hosting keinen Kommandozeilenzugriff bietet, ist das bei Drupal ein handfester Nachteil. Das gehört in die Hosterauswahl (Hosting-Anforderungen).

Notfall ohne Backend.

Wenn weder Backend noch Kommandozeile erreichbar sind, bleibt der direkte Weg. Drupal legt Zwischenspeicher je nach Einrichtung in Datenbanktabellen oder im Dateisystem ab.

Bei der Datenbankvariante lassen sich die entsprechenden Tabellen über die Datenbankverwaltung leeren — die Struktur bleibt, nur die Einträge gehen. Zusätzlich gibt es ein Verzeichnis mit erzeugten PHP-Dateien, das entfernt werden kann; Drupal baut es neu auf.

Vorher sichern. Und danach die Dateirechte prüfen: Werden Verzeichnisse unter einem anderen Benutzer neu angelegt als dem des Webservers, entsteht das nächste Problem (Weiße Seite).

Wann Leeren nötig ist.

• Nach jedem Code-Update — Kern, Module, Theme.
• Nach dem Aktivieren oder Entfernen eines Moduls.
• Nach Änderungen an Diensten oder Routen.
• Nach Änderungen an Vorlagen im Theme.
• Nach einem Konfigurationsimport.
• Nach einem Umzug.

Nicht nötig: nach normalen Inhaltsänderungen. Das erledigen die Markierungen. Wenn doch, siehe oben — dann fehlt etwas im Code.

Seiten-Cache für Gäste.

Für nicht angemeldete Besucher kann Drupal ganze Seiten ablegen und ohne weitere Verarbeitung ausliefern. Das ist der größte Tempogewinn und für die meisten Websites die wichtigste Einstellung.

Einzustellen ist eine maximale Gültigkeitsdauer. Dank der Markierungen muss sie nicht kurz sein: Drupal macht Einträge bei Inhaltsänderungen ohnehin ungültig. Eine lange Dauer ist deshalb unproblematisch und sinnvoll.

Wichtig: Diese Ebene greift ausschließlich für nicht angemeldete Besucher. Für angemeldete ist sie wirkungslos — dafür gibt es die nächste (Caching richtig einrichten).

Dynamischer Cache und BigPipe.

Für angemeldete Besucher speichert Drupal Seitenteile zwischen und setzt nur die personalisierten Bestandteile neu zusammen. Das ist der Grund, warum ein ordentlich eingerichtetes Drupal auch im angemeldeten Zustand schnell ist — etwas, womit viele Systeme Mühe haben.

Dazu kommt ein Verfahren, das die Seite in Teilen ausliefert: Das Gerüst kommt sofort, langsame Bestandteile werden nachgeliefert. Für den Besucher fühlt sich das deutlich schneller an, auch wenn die Gesamtzeit gleich bleibt.

Beide sollten aktiv sein. Wenn sie abgeschaltet wurden — das kommt vor, meist um ein Darstellungsproblem zu umgehen — ist das ein Tempoverlust, der an anderer Stelle behoben gehört (Ladezeit).

Vorgeschaltete Dienste.

Drupal spielt gut mit vorgeschalteten Zwischenspeichern zusammen, weil es passende Angaben über die Gültigkeit mitsendet. Bei größeren Installationen ist eine solche Ebene üblich.

Zu beachten: Diese Dienste müssen über Änderungen informiert werden, sonst liefern sie alte Inhalte aus. Dafür gibt es Module, die eine Leerung auslösen, wenn sich etwas ändert.

Und wie überall: Seiten für angemeldete Besucher dürfen dort nicht landen. Ein vorgeschalteter Dienst, der personalisierte Seiten zwischenspeichert, zeigt sie unter Umständen anderen — das ist ein Datenschutzvorfall, kein Schönheitsfehler.

Wenn es trotzdem nicht erscheint.

1. Privates Fenster — schließt den Browser aus.
2. Zwischenspeicher über die Kommandozeile leeren.
3. Vorgeschaltete Dienste separat leeren.
4. Ist der Inhalt veröffentlicht?
5. Zugriffsrechte prüfen — sieht die Öffentlichkeit ihn überhaupt?
6. Ansicht prüfen: Filtert sie den neuen Inhalt heraus?
7. Richtige Umgebung?

Punkt sechs ist bei Drupal die häufigste vermeintliche Cache-Ursache: Eine Ansicht mit einem Filter, der den neuen Inhalt ausschließt — ein Datumsfilter, ein Sprachfilter, ein Status. Das sieht aus wie Caching und ist Konfiguration.

Eigener Code.

Wenn ein selbst gebauter Block oder eine eigene Ausgabe hartnäckig alte Daten zeigt, fehlen fast immer die Markierungen. Drupal kann nicht wissen, wovon dein Code abhängt — das muss er mitteilen.

Richtig ist, bei eigenen Ausgaben anzugeben, von welchen Inhalten, Konfigurationen oder Listen sie abhängen. Dann wird die Ausgabe automatisch ungültig, wenn sich etwas davon ändert.

Der schlechte Ausweg, den ich regelmäßig sehe: die Zwischenspeicherung für diesen Bestandteil komplett abzuschalten. Das funktioniert und kostet Tempo auf jeder Seite, auf der der Bestandteil vorkommt. Die Markierungen richtig zu setzen ist wenig Aufwand und die bessere Lösung.

Empfehlung.

Für eine normale Drupal-Website: Seiten-Cache für Gäste mit langer Gültigkeitsdauer, dynamischer Cache und das Teilauslieferungsverfahren aktiv, Zwischenspeicherung im Betrieb nie von Hand leeren müssen.

Wenn Letzteres doch regelmäßig nötig ist, ist das ein Befund und kein Betriebszustand — dann fehlen irgendwo Markierungen, und das gehört behoben statt umgangen.

Und wie immer: Caching ist ein Verstärker. Es macht eine gut gebaute Website sehr schnell und kaschiert bei einer schlecht gebauten nur das Symptom (Server zu langsam).

Wenn du nicht weiterkommst.

Wenn Änderungen nicht erscheinen oder du den Zwischenspeicher ständig von Hand leeren musst. 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.