Zum Inhalt springen

Blog · 20. August 2026

Fatal Error nach WordPress 7.1: So beheben Sie den WP-Rocket-Fehler

WordPress 7.1 legt Websites mit WP Rocket per Fatal Error lahm. Ursache, Sofort-Fix (Update auf 3.23.2.2) und Wege zurück ins Backend – Schritt für Schritt.

Fatal Error nach WordPress 7.1: So beheben Sie den WP-Rocket-Fehler

Fatal Error nach dem Update auf WordPress 7.1: WP Rocket legt gerade tausende Websites lahm

Seit dem 19. August 2026 erreichen mich auffällig viele Notrufe mit demselben Bild: Nach dem Update auf WordPress 7.1 zeigt die Website nur noch eine weiße Seite oder die Meldung „Es gab einen kritischen Fehler auf deiner Website" — und auch das Backend ist nicht mehr erreichbar. Der Auslöser ist in fast allen Fällen derselbe: eine Inkompatibilität zwischen WordPress 7.1 und dem Caching-Plugin WP Rocket. Die gute Nachricht: Der Fehler ist bekannt, der Hersteller hat bereits reagiert, und Ihre Website ist in wenigen Minuten wieder online. Hier zeige ich Ihnen Schritt für Schritt, wie.

Was ist passiert?

Wer WordPress 7.1 bei aktivem WP Rocket einspielt, bekommt in den Server-Logs (oder in der Fehler-Mail von WordPress) typischerweise diese Zeile zu sehen:

Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in …/wp-content/plugins/wp-rocket/…/Cloudflare.php:562

Der Fehler tritt im Cloudflare-Addon von WP Rocket auf — und zwar unabhängig davon, ob Sie Cloudflare überhaupt aktiv nutzen, denn die betroffene Datei wird beim Laden des Plugins mit ausgeführt. WP Media, der Hersteller von WP Rocket, hat das Problem noch am selben Tag in der offiziellen Knowledge Base bestätigt; auf GitHub wird es unter Issue #8596 geführt.

Die Ursache kurz erklärt

Technisch ist es ein Klassiker der PHP-8-Ära: WordPress 7.1 liefert an einer Stelle Array-Schlüssel neuerdings als Integer aus, wo WP Rocket bislang immer Strings erwartet hat. Die betroffene Funktion reicht den Schlüssel ungeprüft an substr() weiter — und seit PHP 8 quittiert PHP so etwas nicht mehr mit einer Warnung, sondern mit einem fatalen TypeError. Ergebnis: Die komplette Seite bricht beim Laden ab, Frontend wie Backend.

Die schnelle Lösung: WP Rocket auf Version 3.23.2.2 aktualisieren

WP Media hat mit WP Rocket 3.23.2.2 bereits einen Hotfix veröffentlicht (siehe Changelog). Wenn Sie noch in Ihr WordPress-Backend kommen, ist die Sache in zwei Minuten erledigt:

  1. Melden Sie sich im WordPress-Backend an.
  2. Gehen Sie zu Dashboard → Aktualisierungen (oder Plugins → Installierte Plugins).
  3. Aktualisieren Sie WP Rocket auf 3.23.2.2 oder neuer.
  4. Leeren Sie anschließend einmal den Cache (WP Rocket → „Cache leeren").

Ausgesperrt? So kommen Sie wieder in Ihr WordPress

Bei vielen Betroffenen ist auch /wp-admin nicht mehr erreichbar. Dann führen drei Wege zurück:

  • Wiederherstellungsmodus: WordPress verschickt bei kritischen Fehlern automatisch eine E-Mail an die Admin-Adresse („Deine Website hat ein technisches Problem"). Der Link darin öffnet das Backend im Wiederherstellungsmodus — dort können Sie WP Rocket aktualisieren oder deaktivieren.
  • Per (S)FTP bzw. Hosting-Dateimanager: Benennen Sie den Ordner wp-content/plugins/wp-rocket vorübergehend um (z. B. in wp-rocket_off). Damit ist das Plugin deaktiviert und die Seite sofort wieder erreichbar. Danach im Backend das Update einspielen und den Ordnernamen zurücksetzen bzw. das Plugin wieder aktivieren.
  • Per WP-CLI (für alle mit SSH-Zugang): wp plugin update wp-rocket — fertig.

Wenn Sie nicht sofort updaten können: die offiziellen Workarounds

Für Fälle, in denen ein Plugin-Update nicht sofort möglich ist, nennt WP Media in der Knowledge Base zwei Übergangslösungen:

  • Helper-Datei als Must-Use-Plugin: WP Media stellt eine kleine Helper-Datei (wp-rocket-cloudflare-intkey-fix.php) bereit, die Sie per SFTP oder Dateimanager in den Ordner wp-content/mu-plugins/ hochladen. Sie fängt den Fehler sofort ab und kann nach dem Update auf die fehlerbereinigte Version einfach wieder gelöscht werden.
  • Manueller Code-Eingriff: Wer sich mit PHP auskennt, kann in der betroffenen Datei den Schlüssel-Check um eine is_string()-Prüfung ergänzen. Das empfehle ich allerdings nur Erfahrenen — und ausschließlich als Notlösung, da die Änderung beim nächsten Plugin-Update ohnehin überschrieben wird.

Und wenn alles nichts hilft: WP Rocket vorübergehend deaktiviert lassen. Ihre Website läuft auch ohne Caching-Plugin — langsamer, aber stabil — bis das Update eingespielt ist.

So vermeiden Sie solche Ausfälle in Zukunft

Der Vorfall zeigt einmal mehr, warum ich Core-Updates — gerade Major-Releases wie 7.0 oder 7.1 — nie ungetestet auf einer Live-Seite einspiele. Drei Regeln, die sich bei meinen Kunden bewährt haben:

  • Updates zuerst auf Staging: Jede neue WordPress-Version wird erst auf einer Kopie der Website getestet. Fehler wie dieser fallen dort auf, bevor echte Besucher sie sehen.
  • Major-Releases nicht am Tag 1 einspielen: Ein paar Tage Wartezeit kosten nichts — Plugin-Hersteller liefern Kompatibilitäts-Fixes erfahrungsgemäß innerhalb der ersten Tage nach.
  • Backups und Monitoring: Ein aktuelles Backup plus Erreichbarkeits-Monitoring sorgen dafür, dass ein Ausfall Minuten dauert statt Tage.

Genau das ist der Kern meiner WordPress Betreuung: Ich teste jedes Update zuerst auf einer Staging-Kopie Ihrer Seite und spiele es erst dann live ein, wenn Theme und Plugins nachweislich mitziehen.

Fazit

Der Fatal Error nach dem WordPress-7.1-Update ist ärgerlich, aber harmlos und schnell behoben: WP Rocket auf 3.23.2.2 aktualisieren — notfalls über den Wiederherstellungsmodus oder per FTP — und die Seite läuft wieder. Ihre Inhalte und Daten sind zu keinem Zeitpunkt in Gefahr.

Ihre Website zeigt gerade den kritischen Fehler und Sie möchten da nicht selbst ran? Über meine WordPress Notfallhilfe bin ich kurzfristig erreichbar und bringe Ihre Seite in der Regel noch am selben Tag wieder online.