WP Rocket vor WordPress 7.1 auf 3.23.2.2 aktualisieren

#Was abgestürzt ist

Sie haben auf WordPress 7.1 aktualisiert und die Site ist weiß. wp-admin ist tot. admin-ajax ist tot. REST ist tot. WP-CLI stirbt mit demselben Stack. Das PHP-Log wiederholt bei jedem Request eine Zeile:

PHP Fatal error: Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in .../wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562

Wordify hat das Ende zu Ende auf einer Testsite nachgestellt und den Stack am 20. August 2026 veröffentlicht. Der Fatal Error feuert auf init, während WordPress noch bootet, also sterben Frontend und Dashboard gemeinsam. WP_DEBUG druckt auf dem Bildschirm nicht immer etwas. Das Error-Log ist der verlässliche Ort.

Bei All-Inkl liegt dieses Log oft unter /logs/ im Kundenkonto, nicht im WordPress-Verzeichnis. Bei RAIDBOXES steht es in der Box unter Logs, und das Staging ist ein Klick entfernt. Wer nur die Homepage prüft, sieht unter Umständen noch eine gecachte HTML-Seite. Der Shop-Checkout und wp-admin sind trotzdem tot.

Das ist ein WP-Rocket-Bug, kein Hoster-Bug, und nicht “WordPress 7.1 ist kaputt”. Sites ohne WP Rocket haben diesen TypeError nicht getroffen. Sites auf WP Rocket 3.23.2.2 treffen ihn nicht. Die Changelog-Zeile lautet: “Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations.”

Der Codepfad sitzt im Cloudflare-Kompatibilitätsmodul. Sie brauchen keine Cloudflare-Zone, damit er läuft. Wordify war eindeutig: das Modul läuft bei jedem Request, unabhängig davon, ob das Cloudflare-Plugin installiert ist. Ein DACH-Shop mit Borlabs Cookie, Germanized und ohne Cloudflare-Konto ist also genauso betroffen wie eine Site, die Traffic über Cloudflare-Edge ausliefert.

In der MEZ-Nacht vom 19. auf den 20. August 2026 war das für viele Mittelstands-Shops unsichtbar, bis um 8 Uhr jemand den Warenkorb öffnete. Der weiße Checkout ist dann nicht nur ein Performance-Thema. Solange das Formular Daten entgegennimmt oder der Kunde glaubt, eine Bestellung sei durch, hängt Art. 32 DSGVO im Raum: die Verarbeitung muss dem Risiko entsprechen. Ein Origin, der auf init stirbt, erfüllt das nicht.

#Drei Teile, die einzeln harmlos sind

WordPress 7.1 hat geändert, wie Hook-Callback-IDs gebaut werden. Trac-Ticket 65919 ist die Core-Änderung. Bis 7.0.x nutzte _wp_filter_build_unique_id() spl_object_hash(), einen 32-Zeichen-Hex-String. 7.1 wechselte auf spl_object_id(), eine kleine Ganzzahl, die zum String gecastet wird. David Levine von rtCamp zeigte später auf dasselbe Ticket, als der offizielle WordPress-X-Account schrieb, “this wasn’t a bug in 7.1.” Der TypeError sitzt im Plugin. Der Typ des Keys hat sich im Core geändert. Beide Sätze können stimmen.

PHP speichert numerische String-Keys danach als Integer. Wenn "5292" als Array-Key in $wp_filter landet, behält PHP ihn als 5292. Nach 7.1 hat eine Closure an einer Action einen Integer-Key. Vor 7.1 war jeder Key ein String.

WP Rocket nimmt an, diese Keys seien Strings, mit strict_types=1 in Cloudflare.php. Auf init läuft es über Callbacks an deleted_post und transition_post_status und ruft substr() auf jedem Key auf. Strikte Typen verweigern die Umwandlung des Integers. Fatal.

Wordify hat die Schleife veröffentlicht:

foreach ( $original_wp_filter[ $priority ] as $key => $config ) {
    if ( substr( $key, - strlen( $method ) ) !== $method ) {

Ein nacktes WordPress plus WP Rocket überlebt oft. Austin Ginder hat das gefunden. Kommt ein Plugin hinzu, das eine Closure auf deleted_post an Priorität 10 hängt, oder auf transition_post_status an PHP_INT_MAX, stirbt der nächste Request. Elementor Pro ist das verbreitete Beispiel. Contact Form 7 Redirection ist ein weiteres. Das zweite Plugin macht nichts Falsches. Eine Closure zu haken ist normales WordPress.

In DACH-Agenturen ist genau diese Kombination der Alltag: Elementor Pro für das Layout, WP Rocket für den Cache, oft Contact Form 7 oder WPForms, oft Germanized am WooCommerce-Checkout. Germanized war in den öffentlichen Reports kein benannter Trigger. Elementor Pro war es. Die Lehre ist dieselbe: der Crash braucht die Kombination, nicht das einzelne Teil. Wer nur “wir haben WP Rocket getestet” liest, testet nicht den Bestand, den der Kunde wirklich fährt.

Matt Cromwell hat die Ironie auf X notiert: die Core-Änderung war eine Performance-Verbesserung, und Performance ist das Produkt, das WP Rocket verkauft.

#Der sechs Wochen alte GitHub-Bericht

wp-media/wp-rocket Issue 8596 wurde am 6. Juli 2026 eingereicht, während der 7.1-Beta. Der Bericht nannte den TypeError und schlug einen Einzeiler-String-Cast vor. The Repository, 21. August: WP Rocket hat ihn am selben Tag geprüft, die QA konnte ihn in automatisierten Tests nicht reproduzieren, und das Issue versank. Es bekam nie eine verantwortliche Person.

WordPress 7.1 erschien am 19. August 2026, Schlusstag der WordCamp US in Phoenix. Für Berlin, Wien und Zürich war das bereits später Abend MEZ. Ginder schrieb noch am selben Kalendertag: WP-Rocket-Sites in der Flotte von Anchor Hosting gingen nach dem 7.1-Sprung offline. Er hat das Plugin von Hand gepatcht, um sie zurückzubringen.

Zwei weitere GitHub-Issues, 8740 und 8741, landeten am Tag nach dem Release. WP Rocket veröffentlichte eine Warnung: nicht auf 7.1 aktualisieren, bis ein Fix steht, mit einem Support-Artikel unter docs.wp-rocket.me/article/1927. Später am 20. August kam 3.23.2.2, der Einzeiler-Cast aus dem Juli-Bericht. Wordify hat den Fix an demselben Crash geprüft, den sie auf 3.23.2.1 neu aufgesetzt hatten.

Der GitHub-Pull ist wp-media/wp-rocket#8745.

Sechs Wochen zwischen Meldung und Fix sind in einem Premium-Cache-Plugin keine Kleinigkeit. Die QA hat den Integer-Key plus die zweite Closure nicht in der Suite gehabt. Genau diese Lücke ist der Grund, warum ein Staging-Klon mit dem echten Plugin-Satz mehr wert ist als der Satz “wir haben 7.1 getestet” im Changelog.

#Wer ausgefallen ist

Ginders Flottenzahlen, 20. August: 124 von 332 Produktionsseiten mit WP Rocket fatal, 37 Prozent. Jeder Crash war WordPress 7.1 + PHP 8.x + Cloudflare.php.

Die spätere Post-Mortem von WP Rocket, von The Repository am 27. August aufgegriffen, schätzte rund 27 Prozent der Nutzerbasis als gefährdet und rund 10 Prozent als tatsächlich getroffen. CEO Rémy Lamiot sagte, Elementor Pro sei trotz Install-Basis und obwohl es einer der Trigger war, nicht auf der Kompatibilitätsliste gewesen, gegen die sie getestet haben. Der Juli-Bericht hatte keine verantwortliche Person. “This cost real time and real trust,” schrieb er.

Diese zwei Prozentsätze messen nicht dasselbe. Ginder hat eine betreute Flotte gezählt, die WP Rocket bereits fuhr. WP Rocket hat die ganze Nutzerbasis gezählt, inklusive Sites, die 7.1 in jener Woche nie eingespielt haben, und Sites ohne das zweite Plugin. Beide Zahlen zitieren. Nicht mitteln.

Eine RAIDBOXES-Flotte sähe anders aus, weil dort Staging zum Produkt gehört und Plugin-Updates oft angepinnt werden. Ein All-Inkl-Bestand ohne Klon und mit Auto-Update am Core sähe eher aus wie Ginders Mittwoch: der Sprung passiert, das Log füllt sich, der Kunde merkt es am nächsten Werktag. Das ist keine Aussage über die Qualität der Hoster. Es ist die Aussage, dass der zweite Plugin-Satz und der Update-Pfad den Ausschlag geben, nicht das Land, in dem der Server steht.

Wordifys erste Kundensite hat den Core um 01:55 UTC aktualisiert, 03:55 MEZ. Der erste Fatal Error traf das Log drei Sekunden später. Der Support hat das Plugin deaktiviert. Rund 35 Minuten Ende zu Ende, der größte Teil Diagnose, weil noch niemand “7.1” mit “WP Rocket” verbunden hatte. Um 03:55 MEZ sitzt in einem DACH-Mittelstand niemand vor dem Error-Log. Der Ticket-Eingang verschiebt sich auf den Vormittag.

Andrew Hoyer schrieb, er habe sein Team vor 7.1 gewarnt und sei trotzdem mit Dutzenden kaputter Sites aufgewacht. Sein Satz: Alpha, Beta und RC auf dem eigenen Stack testen, statt dem Vendor zu vertrauen. Steve Jones fragte, ob Leute die Produktion in der Stunde aktualisieren, in der ein Major landet, ohne Rollback. Beide Fragen sind die Arbeit eines Wartungsretainers. Sie sind kein Markenstreit.

#Sichere Reihenfolge

Wenn die Site noch auf WordPress 7.0.x steht und WP Rocket älter ist als 3.23.2.2:

1. Klon aufs Staging.
2. WP Rocket auf dem Staging auf 3.23.2.2 aktualisieren. Prüfen, dass wp-admin und eine ausgeloggte Startseite laden.
3. Dann WordPress 7.1 auf dem Staging einspielen. Login treffen, Checkout wenn WooCommerce, ein Formular, Cron.
4. Dieselbe Reihenfolge in der Produktion: Plugin zuerst, Core danach.

RAIDBOXES hat den Klon als Box-Funktion. Bei All-Inkl heißt Staging meist ein zweiter Vertrag oder ein manuelles Duplizieren. Beides zählt. Ein Unterverzeichnis auf der Produktion ist kein Klon: dieselbe Objekt-Cache-Instanz, dieselbe wp-config.php, derselbe Autoload.

Haben Auto-Updates 7.1 bereits eingespielt und die Site ist weiß, lassen Sie den Normalweg weg. Zuerst deaktivieren.

Reaktivieren Sie 3.23.2.1 nicht auf 7.1. Der Support-Artikel von WP Media ist eindeutig: erscheint kein Update in der Plugin-Liste, folgen Sie ihrer Anleitung für fehlende Updates. Die kaputte Version erneut zu aktivieren, legt die Site wieder lahm.

Sehr alte WP-Rocket-Builds, die älter sind als die Cloudflare.php-Schleife, sind nicht betroffen. Wordify hat das betroffene Band grob bei 3.16 bis 3.23.2.1 angesetzt. Wenn Sie unsicher sind, aktualisieren Sie trotzdem auf 3.23.2.2. Das ist die Version mit dem String-Cast.

Was 7.1 tatsächlich ausgeliefert hat, und was es gestrichen hat, steht in der WordPress-7.1-Roadmap-Notiz. Der iframed Beitragseditor ist ein eigener Entwicklerbruch. Details in der Notiz zum iframed Editor. Dieser Text gilt nur dem Rocket-Fatal.

#Wenn wp-admin bereits weiß ist

Löschen Sie Cloudflare.php nicht. Wordify: die Klasse hängt im Plugin-Container, und das Entfernen der Datei tauscht diesen Fatal Error gegen den nächsten.

WP-CLI. WP-CLI lädt Plugins, also stirbt ein nacktes wp plugin deactivate wp-rocket. Überspringen Sie das Plugin, während Sie es deaktivieren:

wp plugin deactivate wp-rocket --skip-plugins=wp-rocket

RAIDBOXES und Hetzner-Managed liefern SSH mit WP-CLI. All-Inkl-Tarife oft nicht. Dann bleibt SFTP.

SFTP. Benennen Sie wp-content/plugins/wp-rocket in wp-rocket.off um. WordPress behandelt einen umbenannten Ordner beim nächsten Request als deaktiviert.

Danach auf 3.23.2.2 aus dem wieder erreichbaren wp-admin aktualisieren und reaktivieren.

Ein Rollback auf 7.0.4 aus einem Backup vor dem Update stellt die Site ebenfalls wieder her. Das ist der langsamere Weg. Er verwirft die 7.1-Dateien, die bereits auf der Platte liegen. Nutzen Sie ihn, wenn SFTP und WP-CLI nicht erreichbar sind.

Ein Page-Cache auf Host-Ebene (LiteSpeed, nginx FastCGI, Cloudflare-Cache von HTML) kann anonymen Besuchern weiter eine letzte gute Seite ausliefern, während wp-admin tot ist. Das verdeckt den Ausfall vor einem Teil der Kunden und verzögert das Ticket. Prüfen Sie das Error-Log, nicht nur die Startseite. Ein 200 auf / bei weißem /wp-admin/ ist kein grünes Monitoring.

#Wie wir einen Core-Update testen

WPPoland (Mariusz Szatkowski) behandelt ein Major als Dreischicht-Prüfung, nicht als Kalenderereignis.

Staging ist ein Klon, kein Unterverzeichnis auf der Produktion. Dieselbe PHP-Version, derselbe Object-Cache, dieselben Plugins. Wir spielen zuerst die Plugin-Updates ein, die eine bekannte Inkompatibilität haben. Für 7.1 begann diese Liste mit WP Rocket 3.23.2.2. Dann der Core. Dann eine Smoke-Liste: Login, ein Speichern im Beitragseditor (jetzt immer iframed), WooCommerce-Warenkorb und Checkout wenn die Site sie hat, ein Formular-POST, ein Cron-Lauf.

Ein Produktionsklon nach DSGVO ist kein Spielplatz. Kundendaten, Bestellungen, Einwilligungsprotokolle gehören nicht ungefiltert auf ein dauerhaftes Staging, das fünf Leute per HTTP erreichen. Art. 32 DSGVO verlangt technische und organisatorische Maßnahmen. Praktisch heißt das: Klon mit gekürzten personenbezogenen Daten wo möglich, Zugriff nur über VPN oder HTTP-Auth, AVV mit dem Hoster, der die Box stellt. RAIDBOXES und All-Inkl sitzen in der EU. Das ersetzt nicht die eigene Zugriffskontrolle auf den Klon.

Wir vertrauen nicht auf “WP Rocket hat 7.1 getestet.” Sie haben getestet. Ihre Suite hat den Integer-Key plus die Closure eines zweiten Plugins verpasst. Ginders nackte Installation ist nicht abgestürzt. Die Kombination ist abgestürzt. Die Kombination ist das, was eine Kundensite tatsächlich ist.

In der Produktion halten wir ein benanntes Backup von vor dem Sprung und ein 15-Minuten-Fenster, in dem jemand das Error-Log liest, nicht nur den Uptime-Ping. Ein weißes Frontend mit einem 200 aus dem HTML-Cache ist kein Bestehen. Das Fenster legen wir in die MEZ-Geschäftszeit, nicht auf 03:55. Der erste echte Checkout nach dem Sprung ist der Test, den der Uptime-Check nicht sieht.

Ein typischer Kundenklon in diesem Shop ist WordPress + WooCommerce oder Elementor + WP Rocket + ein Formular-Plugin. Das ist die Kombination, die Ginder und Wordify beschrieben haben. Wir warten nicht auf den Tweet des Vendors “wir haben 7.1 getestet”. Wir spielen 7.1 auf dem Klon ein, rufen / und /wp-admin/ auf und greppen das PHP-Log nach TypeError und Cloudflare.php. Bleibt das Log still und beide URLs liefern 200 ohne Plugin-Skip, darf der Sprung in derselben Reihenfolge in die Produktion.

Die PHP-Version gehört zum Klon. Der TypeError ist ein PHP-8-Strict-Types-Fehler. Ein Hoster, der noch auf PHP 7.4 steht, würde genau diesen Fatal Error nicht werfen. Das ist kein Grund, auf 7.4 zu bleiben. Es ist ein Grund, 8.2 oder 8.3 mit demselben Plugin-Satz zu testen, den Sie in der Produktion fahren, nicht mit einem nackten WordPress. All-Inkl und RAIDBOXES bieten PHP 8.2 und 8.3. Der Test gehört dorthin, wo die Site wirklich läuft.

Das ist der WordPress-Wartungsretainer in einem Absatz. Staging zuerst. Plugin zuerst, wenn der Vendor einen Pin hat. Core danach. Health-Check hinterher. Schriftliches Angebot nach einem kurzen Briefing.

Sitzt die öffentliche Fläche bereits auf Cloudflare Workers oder Pages, tötet der PHP-Fatal trotzdem wp-admin und jede Origin-Route. Edge-HTML-Cache ersetzt kein Plugin, das auf init fatal wird. Der Cloudflare-Edge-Pfeiler ist die Auslieferungsschicht. Dieser Vorfall ist die Origin-Schicht.

#Auto-Updates und 7.1.1

Wordify hat gewarnt, dass 7.1-Auto-Updates in derselben Woche rollten. Eine Site, die niemand angefasst hat, konnte über Nacht von in Ordnung auf down wechseln.

In DACH schalten viele All-Inkl-Kunden Minor-Auto-Updates ein und merken ein Major erst, wenn der Hoster es anbietet oder jemand im wp-admin auf “Aktualisieren” klickt. RAIDBOXES hält Major-Updates oft zurück, bis die Box sie freigibt. Beides schützt nicht vor einem Plugin, das auf init stirbt, sobald 7.1 einmal liegt. Der Schutz ist die Reihenfolge Plugin, dann Core, plus der Klon.

Adam Silverstein hat am 20. August Trac 65920 eröffnet: ein GitHub-Actions-Workflow, der die Top-100-Verzeichnis-Plugins gegen unveröffentlichtes WordPress testet. Draft-PR 13198, Meilenstein 7.2. Er hat im Ticket festgehalten, dass genau dieser Vorfall nicht aufgefallen wäre, weil WP Rocket Premium ist und die Directory-API freie Plugins abdeckt. Dieselbe Klasse von Typwechsel-Fatals kann trotzdem ein freies Plugin mit Millionen Installationen treffen. Das ist der Sinn des Workflows.

Aaron Jorbin hat um Freiwillige für 7.1.x gebeten. 7.1.1 war zwischen dem 1. und 24. September 2026 vorgesehen. Behandeln Sie 7.1.1 genauso: Staging, dann Produktion. Bekommen die Integer-Keys aus 65919 in 7.1.1 einen Kompatibilitäts-Shim, ist das zusätzliche Versicherung. Es ist kein Grund, 3.23.2.2 zu überspringen.

Jeffrey Paul hat Silversteins Ticket gestützt: wiederholte Fatals nach Majors liegen in der Sphäre des Cores, auch wenn die kaputte Datei in einem Plugin sitzt. Das ist die ehrliche Teilung. Der Core kann Verzeichnis-Plugins testen. Der Core kann Premium-Plugins nicht testen, die er nicht hat. Die Site-Inhaberin, oder die Person auf dem Retainer, besitzt weiter den Klon.

#Was wir nicht behaupten

Wir sagen nicht, WP Rocket abzuschalten. 3.23.2.2 ist der aktuelle Build mit dem Cast. Cache-Plugins verdienen ihren Platz auf PHP-Origins weiter.

Wir sagen nicht, WordPress 7.1 zu überspringen. Responsives Styling, clientseitige Medien, die persistente Admin-Leiste und der iframed Editor sind erschienen. Die Roadmap-Notiz listet, was landete und was nicht.

Wir zitieren nicht die Preise von WP Rocket. Drittanbieter-Lizenzgebühren sind deren Liste. Unsere Wartungsarbeit ist ein individuelles Angebot.

Wir erfinden keinen Prozentsatz für “das ganze Internet”. Ginders 37 Prozent sind eine Flotte. Die 10 Prozent von WP Rocket sind deren Schätzung der Nutzerbasis. Beide sind belegt. Keine von beiden ist eine Volkszählung.

Zuletzt aktualisiert am 1. September 2026. Quellen: The Repository (21. und 27. August 2026), Wordifys Stack-Trace-Bericht (20. August), GitHub-Issue 8596 und Pull 8745, Trac 65919 und 65920, WP-Rocket-3.23.2.2-Changelog und Support-Artikel 1927, Austin Ginder auf X, Zitate aus Rémy Lamiots Post-Mortem über The Repository.