WordPress Wartung & Support in Wuppertal

Eine WordPress-Seite, die seit Jahren läuft, wird selten durch einen großen Fehler langsam. Meist sammelt sich Ballast an: Optionen, die bei jedem Aufruf mitgeladen werden, abgelaufene Zwischenspeicher, tausende alte Revisionen und Aufgabenlisten, die niemand mehr ansieht. Deshalb steht im Mittelpunkt meiner WordPress-Wartung für Wuppertaler Unternehmen die Datenbank einer älteren Seite. Ich sitze in Gdynia, arbeite allein, per E-Mail und in Dokumenten, und komme nicht zu Terminen nach Wuppertal.

#Warum die Datenbank einer gewachsenen Seite Pflege braucht

Foto: Atamari, CC BY-SA 4.0, Wikimedia Commons.

Die Datenbank ist der Teil, den im Alltag niemand sieht. Plugins kommen und gehen, jedes hinterlässt Einträge. Redakteure speichern jeden Beitrag dutzende Male. Ein Shop plant Hintergrundaufgaben, die sich über Jahre ansammeln. Auf dieser Seite beschreibe ich, was ich in dieser Datenbank prüfe, in welcher Reihenfolge, und wie Sie am Ende sehen, ob es etwas gebracht hat.

#Autoload-Optionen: was bei jedem Aufruf geladen wird

WordPress lädt viele Optionen aus der Tabelle wp_options mit einer einzigen Abfrage bei jedem Seitenaufruf. Die Entwicklernotiz vom 18. Juni 2024 nennt das Autoload. Sie beschreibt auch das Problem: Weil der Parameter bisher standardmäßig auf Laden stand, wurden viele Optionen unnötig bei jeder Anfrage geladen. Große, ungenutzte Werte verschlechtern die Leistung der Seite.

Was sich mit WordPress 6.6 geändert hat, laut derselben Notiz:

• Der Standardwert des Autoload-Parameters von add_option() und update_option() ist null statt "yes". WordPress kann damit unterscheiden, ob jemand einen Wert ausdrücklich gesetzt hat.
• Wer keinen Wert setzt und eine Option mit mehr als 150000 Bytes speichert, bekommt sie nicht mehr als Autoload. Die Grenze lässt sich mit dem Filter wp_max_autoloaded_option_size ändern.
• In der Datenbank können neben yes und no jetzt auch on, off, auto, auto-on und auto-off stehen.
• Eine Aufräumroutine für bestehende Einträge ist laut Notiz nicht geplant. Optionen, die ein Plugin vor Jahren gespeichert hat, bleiben also, wie sie sind.

Der letzte Punkt ist der Grund, warum eine ältere Seite davon nicht automatisch profitiert. Das Update ändert das Verhalten für neu gespeicherte Werte, nicht für den Bestand.

Seit 6.6 gibt es außerdem einen Test unter Werkzeuge, Website-Zustand. Die Übersicht der Leistungsverbesserungen in 6.6 beschreibt ihn so: Er zeigt Anzahl und Größe der Autoload-Optionen und meldet den Status kritisch, wenn die Schwelle überschritten wird. Die Voreinstellung nennt die Dokumentation des Filters: 800000 Bytes.

So gehe ich vor:

1. Ich lese das Autoload-Volumen mit WP-CLI aus. Der Befehl wp option list --autoload=on --format=total_bytes liefert die Gesamtgröße, mit --fields=option_name,size_bytes sehe ich die größten Einträge. Weil seit 6.6 mehrere Werte als Autoload gelten, lese ich die Spalte autoload zusätzlich direkt aus der Tabelle, statt mich auf einen einzigen Filterwert zu verlassen.
2. Ich ordne die größten Optionen Plugins zu. Gehört eine Option zu einem aktiven Plugin, entscheide ich pro Eintrag, ob sie auf jeder Seite gebraucht wird. Gehört sie zu einem Plugin, das längst entfernt ist, kommt sie auf die Löschliste.
3. Ich ändere nichts live. Auf der Staging-Kopie setze ich Optionen auf kein Autoload oder entferne sie und gehe die Seite durch.

Löschen ist nur dann sicher, wenn klar ist, wem die Option gehört. Eine Option eines aktiven Plugins entferne ich nie ohne diese Zuordnung.

#Abgelaufene Transients

Transients sind zwischengespeicherte Werte mit Ablaufzeit. Die Entwicklerdokumentation beschreibt zwei Dinge, die für die Pflege zählen. Erstens bereinigt WordPress abgelaufene Transients laut Dokumentation nur selten. Zweitens liegen sie nur dann in der Datenbank, wenn kein externer Objekt-Cache eingerichtet ist. Auf einer Seite mit externem Objekt-Cache wie Memcached liegen sie dort, nicht in wp_options.

Ob also ein Problem besteht, hängt vom Hosting ab. Ich zähle sie zuerst. Mit wp option list --transients --format=count sehe ich die Menge, und mit wp transient delete --expired entferne ich die abgelaufenen auf der Kopie. Der Befehl nennt die Zahl der gelöschten Einträge, die ich in den Bericht übernehme.

#Revisionen und Papierkorb

Revisionen sind Kopien eines Beitrags bei jedem Speichern. Laut Dokumentation zur wp-config.php speichert WordPress sie standardmäßig. Die Konstante WP_POST_REVISIONS schaltet sie ab oder legt eine Obergrenze fest, etwa auf 3 oder 12. Dort steht auch der Hinweis, dass die Zeile bei manchen Installationen erst funktionierte, nachdem sie an den Anfang der Datei verschoben wurde. Das prüfe ich deshalb auf Staging.

Meine Empfehlung ist selten, Revisionen ganz abzuschalten. Eine Redaktion, die einen Text zurückholen muss, wird es merken. Besser ist eine Obergrenze, die Sie schriftlich festlegen. Vorher zähle ich die vorhandenen Revisionen mit wp post list --post_type=revision --format=count, damit der Bericht eine Zahl nennt und keine Vermutung.

Der Papierkorb hat eine eigene Regel: EMPTY_TRASH_DAYS steht laut derselben Dokumentation auf 30 Tage, und mit dem Wert null gibt es keinen Papierkorb mehr. Wer den Wert auf null stellt, löscht beim Klick auf “Endgültig löschen” ohne Rückfrage. Ich ändere ihn nur auf Ihren Wunsch.

#WP-Cron oder echter Cron-Job

Viele Plugins und WordPress selbst planen Aufgaben über WP-Cron. Die Dokumentation erklärt: WP-Cron läuft nicht dauerhaft, sondern prüft bei jedem Seitenaufruf, ob etwas fällig ist. Wenn drei Stunden lang niemand die Seite aufruft, läuft auch drei Stunden lang nichts. Die Aufgabe wird dann beim nächsten Aufruf nachgeholt.

Für zeitkritische Aufgaben beschreibt die Dokumentation einen anderen Weg: den Aufruf von wp-cron.php über den Aufgabenplaner des Servers einzurichten und WP-Cron in der wp-config.php mit define( 'DISABLE_WP_CRON', true ); abzuschalten. Dann läuft er im festen Takt, nicht erst beim nächsten Besucher.

Das geht nur, wenn Ihr Hosting einen Cron-Job erlaubt. Auf einfachen Tarifen ist das nicht immer der Fall. Dann bleibt WP-Cron aktiv, und ich schreibe die Folgen in den Bericht, etwa verspätete geplante Beiträge. Mit wp cron event list und wp cron event run --due-now sehe ich auf der Kommandozeile, was fällig ist und ob etwas hängt, vorausgesetzt es gibt SSH-Zugang.

#Action Scheduler in WooCommerce-Shops

Wer einen Shop betreibt, hat meist noch eine zweite Warteschlange. Action Scheduler ist laut eigener Dokumentation eine Bibliothek für Hintergrundaufgaben, die unter anderem Webhooks von WooCommerce verarbeitet. Seit Version 3.0 speichert sie ihre Daten in eigenen Tabellen mit dem Präfix actionscheduler_, wie die FAQ beschreibt.

Zwei Eigenschaften sind für die Pflege wichtig:

• Die Warteschlange hängt am WP-Cron. Laut Beschreibung der Bibliothek wird sie über einen WP-Cron-Hook angestoßen. Wer WP-Cron abschaltet, muss also sicherstellen, dass der System-Cron ihn aufruft, sonst bleibt auch diese Warteschlange stehen.
• Abgeschlossene und abgebrochene Aufgaben löscht sie nach etwa einem Monat selbst. Fehlgeschlagene Aufgaben behält sie seit Version 4.0.0 standardmäßig drei Monate, wie die Seite zur Leistung beschreibt.

Wächst eine dieser Tabellen trotzdem stark, zum Beispiel weil ein Plugin laufend fehlschlagende Aufgaben erzeugt, ist das ein Befund und kein Aufräumproblem. Ich suche zuerst die Ursache. Der Befehl wp action-scheduler clean räumt dann Altbestände ab. Er behandelt standardmäßig abgeschlossene und abgebrochene Aufgaben, die älter als 31 Tage sind, und lässt sich auf weitere Status einschränken oder erweitern. Auch das läuft zuerst auf der Kopie.

#Vorher und nachher: so messe ich

Ohne Messung ist Aufräumen eine Meinung. Ich halte vor dem Eingriff diese Werte fest und wiederhole sie danach:

web.dev empfiehlt, am 75. Perzentil der Seitenaufrufe zu messen, getrennt nach Mobil und Desktop. Das übernehme ich. Feldwerte und Laborwerte sind verschiedene Dinge: Ein Labortest zeigt, was auf einem Testgerät passiert, Feldwerte zeigen echte Besucher. Verändert sich ein Feldwert, dauert es, bis das sichtbar wird. Deshalb nenne ich im Bericht beides getrennt und vermische sie nicht.

Eine Zusage wie “danach ist die Seite doppelt so schnell” gebe ich nicht. Die Datenbank ist nur eine von mehreren Ursachen für eine langsame Seite. Manchmal liegt das Problem bei Bildern, Skripten oder dem Hosting. Dann steht im Bericht, dass die Datenbank in Ordnung war und wo ich weitersuchen würde.

#Reihenfolge und Absicherung

Der Ablauf ist immer derselbe, damit nichts live geschieht, was ich nicht vorher gesehen habe:

1. Backup außerhalb des Hosting-Kontos ziehen und auf einer Staging-Kopie wiederherstellen.
2. Messwerte der Kopie festhalten.
3. Aufräumen in kleinen Schritten, nach jedem Schritt Formulare, Suche, Checkout und Anmeldung prüfen.
4. Messung wiederholen und mit dem Ausgangswert vergleichen.
5. Erst nach Ihrer schriftlichen Freigabe dieselben Schritte live ausführen, wieder mit frischem Backup.
6. Bericht mit allen Werten, gelöschten Mengen und offenen Entscheidungen.

Datenbankeingriffe lassen sich nicht immer sauber rückgängig machen. Deshalb ist das Backup kein Formalismus, und ich prüfe, ob sich die Kopie daraus wirklich wiederherstellen lässt.

#Datenschutz und die LDI NRW

Aufsichtsbehörde für Unternehmen in Wuppertal ist die LDI NRW. Datenbankpflege ist dabei kein reines Technikthema. Revisionen alter Entwürfe, Formulareinträge und Aufgaben in Warteschlangen können Namen, Adressen oder Bestelldaten enthalten.

Die DSGVO verlangt in Artikel 5 Absatz 1 Buchstabe e, dass personenbezogene Daten nur so lange gespeichert werden, wie es für den Zweck nötig ist (Verordnung (EU) 2016/679, Amtsblatt der EU). Der Grundsatz heißt Speicherbegrenzung. Er gilt für Sie als Verantwortliche. Ich gebe keine Rechtsberatung. Was ich liefere, ist der technische Befund: wo solche Daten in Ihrer Datenbank liegen, wie viele es sind und wie alt sie sind. Welche Frist Sie festlegen, entscheiden Sie. Muss ich dafür auf personenbezogene Daten zugreifen, klären wir vorher schriftlich, ob ein Vertrag nach Artikel 28 DSGVO nötig ist.

#Der Rest der Wartung

Neben der Datenbankpflege gehören zur monatlichen Arbeit:

• Updates auf Staging zuerst. Core, Plugins und Theme probiere ich auf einer Kopie aus, bevor sie live gehen.
• Backups an einem Ort getrennt vom Hosting, deren Rückspielung ich stichprobenartig teste.
• Erreichbarkeits-Monitoring: fällt die Seite aus, bekommen Sie eine Mail.
• Kleine Änderungen an der Seite im Rahmen der Stunden, die für den Monat vereinbart sind.

Nicht genutzte Stunden eines Monats verfallen und wandern nicht in den nächsten. Einen Bereitschaftsdienst gibt es nicht, ich antworte schriftlich an Werktagen. Grafik, Mockups und Wireframes liefern Sie, ich setze sie um. Wie viele Stunden Ihre Seite braucht, schätze ich schriftlich, nachdem ich die Messwerte gesehen habe.

#Was ich zum Start brauche

• die Adresse der Seite und Zugang zum WordPress-Backend als Administrator
• Zugang zum Hosting per SFTP oder SSH, möglichst mit WP-CLI, oder den Namen des Hosters
• die Information, ob der Hoster einen Cron-Job erlaubt
• bei einem Shop: Hinweis auf WooCommerce-Erweiterungen, die Abos, Webhooks oder Importe nutzen
• eine kurze Notiz, ab wann die Seite spürbar langsamer wurde

#Weiterführende Seiten

Muss die Seite zuerst gebaut oder umgebaut werden, hilft WordPress-Entwicklung in Wuppertal. Für Shops gibt es WooCommerce in Wuppertal. Den allgemeinen Ablauf der Betreuung beschreibt die Seite WordPress-Wartung und Support.

#Häufige Fragen

Was ist Autoload, und warum bremst es meine Seite? WordPress lädt bei jedem Seitenaufruf alle Optionen, die als Autoload markiert sind, mit einer einzigen Abfrage. Liegen dort große Datenmengen, die kaum jemand braucht, wird jede Anfrage schwerer. Seit WordPress 6.6 werden große Optionen ohne ausdrücklichen Wert nicht mehr automatisch geladen, ältere Einträge bleiben aber, wie sie sind.

Kann ich Revisionen einfach abschalten? Technisch ja, mit der Konstante WP_POST_REVISIONS in der wp-config.php. Ich rate meist zu einer Obergrenze statt zum Abschalten, weil Ihre Redaktion Revisionen zum Zurückgehen braucht. Die Zahl legen wir schriftlich fest.

Ist WP-Cron ein Problem für meine Seite? Er läuft nur, wenn jemand die Seite aufruft. Auf einer Seite mit wenig Besuchern können geplante Veröffentlichungen oder Shop-Aufgaben deshalb verspätet laufen. Ein System-Cron des Hosters behebt das, sofern der Tarif ihn anbietet.

Wann lohnt sich das Aufräumen von Action Scheduler? Wenn die Tabellen mit dem Präfix actionscheduler_ sehr viele Zeilen enthalten, vor allem fehlgeschlagene oder alte Aufgaben. Das betrifft vor allem Shops. Ich zähle die Zeilen zuerst und lösche nur auf Staging, bevor ich es live wiederhole.

Wie belegen Sie, dass die Seite danach schneller ist? Ich messe vorher und nachher mit denselben Werkzeugen und nenne die Schwellen von web.dev: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1, gemessen am 75. Perzentil. Verbessert sich nichts messbar, steht das genauso im Bericht.

Betreuen Sie Seiten vor Ort in Wuppertal? Nein, auch nicht auf Anfrage. Alles läuft aus Gdynia, per E-Mail und Dokument. Das Layout bringen Sie mit, ich setze es technisch um.

#Ihre Anfrage an mich

Schreiben Sie mir die Adresse Ihrer Seite, seit wann sie langsamer wirkt, ob ein Shop dranhängt und bis wann etwas stehen soll. Nutzen Sie dafür das Kontaktformular, drei oder vier Sätze genügen. Eine erste schriftliche Einschätzung zu den Messwerten ist kostenfrei.