Du klickst im Backend auf Werkzeuge, dann auf Website-Zustand, und da steht sie. Eine Empfehlung in Orange, ein Satz der klingt, als hättest du etwas übersehen: „Du solltest einen persistenten Objekt-Cache verwenden.“ Darunter ein Absatz über Datenbank und Antwortzeiten, der die Sache nicht viel besser macht.
Die kurze Antwort vorweg, damit du nicht bis unten scrollen musst: Das ist kein Fehler. Es ist eine Empfehlung, die WordPress seit Version 6.1 ausspricht, wenn beim Zustandscheck kein persistenter Objekt-Cache gefunden wird.
Betreibst du eine gewöhnliche Website, ein paar Unterseiten mit einem Blog dahinter, dann ist die Meldung halb so wild. Deine Seite läuft, deine Besucher merken nichts. Du kannst den Hinweis stehen lassen und weiterarbeiten.
Bei einer Kursplattform würde ich es anders betrachten. Deine Kursplattform verhält sich technisch anders als eine Visitenkarte im Netz, und deshalb liest sich dieselbe Meldung aus diesem Blickwinkel auch anders. Was das heißt, dazu gleich mehr. Erst muss klar sein, was der Objekt-Cache überhaupt tut.
Was ein persistenter Objekt-Cache in WordPress speichert
Bei jedem Seitenaufruf stellt WordPress im Hintergrund Fragen an die Datenbank. Wer ist der eingeloggte Nutzer. Welche Rolle hat dieser. Welche Optionen sind gesetzt. Welche Kurse darf dieser Mensch sehen. Das sind keine drei Abfragen, das werden je nach Setup schnell mehrere Dutzend, und zwar bei jedem einzelnen Klick.
Der Objekt-Cache legt die Antworten auf diese Fragen parat. Er speichert die einzelnen Datenpakete, die WordPress aus der Datenbank holt. Die fertig gebaute HTML-Seite bleibt außen vor, dafür ist der Seiten-Cache zuständig. Der Objekt-Cache arbeitet eine Ebene darunter, bei den Rohdaten.
Der Unterschied zwischen persistent und nicht persistent
Und hier liegt der Punkt, den die Meldung selbst nicht erklärt.
WordPress bringt einen Objekt-Cache von Haus aus mit. Der hat nur eine Einschränkung: Er lebt für die Dauer eines einzigen Seitenaufrufs. WordPress sammelt die Antworten, merkt sie sich für diesen einen Aufruf, wirft sie am Ende weg. Beim nächsten Besucher beginnt das Fragespiel von vorne.
Persistent bedeutet, dass die Antworten den Seitenaufruf überleben. Sie liegen im Arbeitsspeicher und der nächste Aufruf greift darauf zu, ohne die Datenbank noch einmal zu behelligen. Das fehlt, wenn dir WordPress die Meldung zeigt.
Dafür braucht es einen zusätzlichen Dienst, der diesen Speicher bereitstellt. In der Praxis ist das meistens Redis, seltener Memcached, bei manchen Shared-Hostern auch APCu. Das war für mich damals der Moment, an dem ich erst mal nachlesen musste: Diesen Dienst installierst du nicht als Plugin. Er muss auf dem Server laufen. Das Plugin verbindet WordPress nur mit diesem.
Warum die Meldung bei einer Kursplattform anders wiegt als bei einem Blog
Ein Blog ohne Login liefert jedem Besucher dieselbe Seite aus. Die lässt sich komplett als HTML zwischenspeichern, und die Datenbank wird danach kaum noch angefasst. Für so eine Seite bringt ein persistenter Objekt-Cache wenig. Ich könnte verstehen, wenn jemand den Hinweis per Filter deaktiviert. Bei einem kleinen Blog kann ich das gut nachvollziehen.
Deine Kursplattform arbeitet anders. Deine Teilnehmer sind eingeloggt. Jede Seite die sie sehen ist auf sie zugeschnitten: welche Kurse freigeschaltet sind, wo der Fortschritt steht, welche Membership-Rolle greift. Für eingeloggte Nutzer wird ein Seiten-Cache in der Regel gar nicht ausgeliefert, weil jede Seite anders aussehen muss. Die Datenbank arbeitet also bei jedem Klick durch, und der Seiten-Cache kann daran nichts ändern.
Dasselbe gilt für deinen Shop. Wer eingeloggt ist, Artikel im Warenkorb liegen hat und auf sein Kundenkonto zugreift, erzeugt genau die Sorte Abfragen, die kein Seiten-Cache abfängt. Der Objekt-Cache ist die Ebene, die hier greift.
In meinen Augen ist die Meldung damit für eine Kursplattform kein unwichtige im Backend, sondern ein berechtigter Hinweis. Nicht dringend, aber berechtigt.
Persistenter Objekt-Cache aktivieren: Was du dafür brauchst
Zwei Dinge. Einen Server der Redis bereitstellt, und ein Plugin das WordPress mit diesem Redis verbindet. Für den zweiten Teil gibt es Redis Object Cache, kostenfrei im offiziellen Plugin-Verzeichnis.
Der erste Teil ist der, über den du vorher nachdenken solltest. Nicht jedes Hosting-Paket bringt Redis mit. Bei einem Virtual Private Server (VPS) richtest du es selbst ein, oder dein Anbieter hat es vorbereitet. Bei Managed Hosting steht es in den Leistungsdaten, und wenn nicht, fragst du nach. Ich würde Redis bei der Hosting-Wahl auf die Liste der Kriterien setzen, bevor du buchst. Nachträglich umziehen geht, macht aber keinen Spaß.
Läuft Redis, ist der Rest in fünf Minuten erledigt. Plugin installieren, aktivieren, den Objekt-Cache im Plugin einschalten. Die Meldung im Website-Zustand verschwindet, und im Backend arbeitest du spürbar flüssiger, sobald auf der Seite auch Betrieb ist.
Mein Tipp: Bevor du irgendein Cache-Plugin installierst, schau nach ob dein Hoster Redis anbietet. Wenn ja, aktiviere den Objekt-Cache und lass alle anderen Cache-Ebenen erst einmal liegen. Das ist der Schritt mit dem besten Verhältnis von Aufwand zu Wirkung, und er fasst weder deinen Login noch deinen Kaufprozess an.
Wo Cache gefährlich wird und warum der Objekt-Cache selten der Grund ist
Diese Unterscheidung ist mir persönlich wichtig, weil hier zwei Dinge durcheinander gehen die beide „Cache“ heißen.
Wenn du liest, dass Cache Logins zerschießt oder Kaufprozesse unterbricht, geht es in diesen Fällen wahrscheinlich eher um den Seiten-Cache. Der speichert die fertige HTML-Seite. Erwischt er dabei eine Login-Seite samt Sicherheitstoken, bekommt der nächste Besucher eine Seite mit einem abgelaufenen Token vorgesetzt und die Anmeldung läuft ins Leere. Beim Checkout wird es unschöner, weil dort im schlechtesten Fall Daten sichtbar werden die zu jemand anderem gehören.
Mir ist genau das auf einer Testseite passiert. Ich kam über das Frontend nicht mehr in meine eigene Installation, weil mein Login falsch gecacht war. Wie ich da wieder rausgekommen bin, erzähle ich in der Podcast-Folge.
Der Objekt-Cache kann bei falscher Konfiguration ebenfalls Ärger machen, das will ich nicht unterschlagen. Über einen Redis-Server, den dein Hoster bereitstellt, und das offizielle Plugin gehst du diesen Weg aber ziemlich geradlinig. Es gibt hier deutlich weniger Stellschrauben, an denen du dir die Seite zerlegen kannst, als bei einem Seiten-Cache mit zwei Dutzend Optionen im Backend.
Wenn dein Hosting kein Redis anbietet
Dann lässt du es. Ohne schlechtes Gewissen.
Stört dich der orangefarbene Hinweis, lässt er sich über einen Filter abschalten. WordPress stellt dafür site_status_should_suggest_persistent_object_cache bereit, den du in der functions.php deines Child-Themes auf false setzt. Ich würde ihn trotzdem stehen lassen, solange du vorhast irgendwann auf einen Server mit Redis zu wechseln. Dann ist er eine Erinnerung und keine Mahnung.
Und wenn du gerade erst anfängst, ist das ohnehin kein Punkt, der dich aufhalten sollte. Ein System das zu achtzig Prozent steht und live gehen kann, schlägt das fast perfektes System das nie fertig wird.
In der dazugehörigen Podcast-Folge gehe ich die anderen drei Cache-Ebenen durch, Page, Edge und Browser, und erkläre warum ich sie für den Start deiner Plattform bewusst nach hinten schiebe. Dazu die Geschichte mit dem Login, der mich aus meiner eigenen Seite ausgesperrt hat.
