WP Rocket Fatal Error nach WordPress 7.1: Soforthilfe und dauerhafte Lösung

Die Fehlermeldung

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

Je nach Server-Konfiguration siehst du diese Meldung im Klartext, eine generische Meldung wie „Auf dieser Website ist ein kritischer Fehler aufgetreten“ oder schlicht eine weiße Seite. In der debug.log steht in allen drei Fällen dasselbe.

Wer ist betroffen?

Drei Bedingungen müssen gleichzeitig zutreffen. Fehlt eine davon, tritt der Fehler nicht auf.

In der Praxis trifft die dritte Bedingung auf sehr verbreitete Plugins zu, unter anderem Elementor Pro und Redirection for Contact Form 7. WP Rocket beziffert im eigenen Post-Mortem, dass rund 27 Prozent der Nutzerbasis gefährdet waren und bei etwa 10 Prozent der Fehler tatsächlich auftrat.

Wichtig und oft missverstanden: Das Cloudflare-Add-on von WP Rocket muss nicht aktiv sein. Das Kompatibilitätsmodul lädt bei jedem Request, unabhängig davon, ob du Cloudflare überhaupt einsetzt.

Mehrere Installationen auf einmal prüfen

Wer ein Portfolio betreut, will nicht in vierzig Backends klicken. Liegen die Installationen unter einem gemeinsamen Verzeichnis, reicht eine Schleife über WP-CLI:

# Alle Installationen unter /var/www durchgehen und Core- sowie WP-Rocket-Version ausgeben
for dir in /var/www/*/; do
  [ -f "$dir/wp-config.php" ] || continue
  core=$(wp core version --path="$dir" --skip-plugins --skip-themes 2>/dev/null)
  rocket=$(wp plugin get wp-rocket --field=version --path="$dir" --skip-plugins --skip-themes 2>/dev/null)
  printf '%-40s core=%-8s wp-rocket=%s\n' "$(basename "$dir")" "$core" "${rocket:-nicht installiert}"
done

Die Flags --skip-plugins und --skip-themes sind hier nicht optional. Ohne sie lädt WP-CLI genau die Datei, die den Fehler auslöst, und bricht mit demselben TypeError ab, den du eigentlich diagnostizieren willst.

Betroffen ist jede Zeile, in der core auf 7.1 steht und wp-rocket auf 3.23.2.1 oder niedriger. Wer mit einem zentralen Verwaltungswerkzeug wie MainWP arbeitet, erledigt dasselbe über das Bulk-Plugin-Update, allerdings erst, nachdem die betroffenen Seiten wieder erreichbar sind.

Die technische Ursache

WordPress generiert für jeden registrierten Hook eine interne ID. Bis einschließlich Version 7.0 kam sie bei Closures aus spl_object_hash() und war damit immer ein 32 Zeichen langer Hex-String. WordPress 7.1 stellt auf spl_object_id() um, das eine kleine Zahl liefert, etwa 5292.

Den Rest erledigt PHP von selbst: Wird ein rein numerischer String wie "5292" als Array-Schlüssel verwendet, speichert PHP ihn als Integer. Jede per Closure registrierte Callback hat in der $wp_filter-Tabelle ab 7.1 also einen Integer-Key statt eines Strings.

WP Rocket ging an der betroffenen Stelle davon aus, dass jeder Key ein String ist, und rief substr() direkt darauf auf. Die Datei Cloudflare.php deklariert strict_types=1. Damit ist der Integer kein stillschweigend geduldeter Type-Cast mehr, sondern ein TypeError, und der beendet den Request.

<?php
declare(strict_types=1);

// So sehen die Keys in $wp_filter vor und nach dem Update aus
$callbacks = [
    // bis 7.0: spl_object_hash(), 32 Zeichen Hex, bleibt ein String
    '00000000000014a90000000000000000' => 'callback_eins',
    // ab 7.1: spl_object_id() liefert "5292", PHP macht daraus den Integer 5292
    '5292'                             => 'callback_zwei',
];

foreach ($callbacks as $key => $callback) {
    // Erster Durchlauf unauffällig, zweiter bricht ab:
    // Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given
    $prefix = substr($key, 0, 3);
}

// Robust: explizit casten, bevor eine String-Funktion darauf losgelassen wird
foreach ($callbacks as $key => $callback) {
    $prefix = substr((string) $key, 0, 3);
}

Das ist ein lehrreicher Fall: Der Fehler lag nicht im WordPress-Core und nicht wirklich in WP Rocket allein, sondern in einer Annahme über undokumentiertes Verhalten, die jahrelang zutraf und dann nicht mehr zutraf.

Soforthilfe: Website wieder erreichbar machen

Variante A: Zugang per SFTP vorhanden

1. Per SFTP mit dem Server verbinden.
2. Nach /wp-content/plugins/ navigieren.
3. Den Ordner wp-rocket in wp-rocket.off umbenennen.
4. Website neu laden. Sie ist jetzt wieder erreichbar, allerdings ohne Caching.

Nicht tun: Einzelne Dateien innerhalb des Plugin-Ordners löschen oder bearbeiten. Das erzeugt Folgefehler, die schwerer zu diagnostizieren sind als das ursprüngliche Problem. Das Plugin muss als Ganzes deaktiviert werden.

Variante B: Zugang per WP-CLI vorhanden

wp plugin deactivate wp-rocket --skip-plugins
wp plugin update wp-rocket
wp plugin activate wp-rocket

Das --skip-plugins ist hier entscheidend, weil WP-CLI sonst beim Laden derselben fehlerhaften Datei abbricht.

Variante C: Nur Hosting-Panel vorhanden

Die meisten Hoster bieten einen Dateimanager. Das Vorgehen entspricht Variante A. Bei Managed-WordPress-Hostern lohnt sich vorher ein Blick in den Status: Einige Anbieter rollen den Fix selbst aus.

Dauerhafte Lösung

WP Rocket hat am 20. August 2026 die Version 3.23.2.2 als Hotfix veröffentlicht. Der Changelog-Eintrag nennt genau diesen Fall. Nach dem Update auf diese oder eine neuere Version tritt der Fehler nicht mehr auf.

Weil das Backend bei betroffenen Seiten nicht erreichbar ist, entsteht ein Henne-Ei-Problem: Das Update lässt sich nicht über die Plugin-Oberfläche einspielen. Deshalb zuerst deaktivieren, dann updaten, dann wieder aktivieren. WP Rocket stellt zusätzlich ein Helper-Plugin namens „WP Rocket - Update Notification Recovery“ bereit, das in Umgebungen hilft, in denen die Update-Benachrichtigung hängt.

Was dieser Vorfall über Update-Strategien verrät

Der Fehler war am 6. Juli auf GitHub gemeldet worden, mit korrekter Beschreibung und der richtigen Zeile. WP Rocket konnte ihn zunächst nicht nachstellen, weil dafür die passende Plugin-Kombination nötig ist. Am 15. Juli erschien die Beta von WordPress 7.1, in der die Änderung bereits enthalten war. Am 19. August kam das Release, und mit ihm die Support-Tickets. Zwischen Meldung und Eskalation lagen sechs Wochen.

WP Rocket hat das im eigenen Post-Mortem offen eingeräumt und drei Konsequenzen benannt: verbindliche Zuständigkeit für GitHub-Meldungen, eine Testsuite, die sich an real verbreiteten Plugins orientiert statt an historisch gewachsenen Testfällen, und kürzere Wege zwischen interner Eskalation und öffentlicher Kommunikation.

Für Website-Betreiber ist die praktische Lehre eine andere: Ein Core-Update am Erscheinungstag direkt auf Produktion einzuspielen, ist auch dann riskant, wenn das Update selbst fehlerfrei ist. Das Risiko liegt in der Kombination aus Core, Plugins und Theme, und diese Kombination testet niemand außer dir. Wie ein Ablauf aussieht, der genau das abfängt, habe ich in WordPress-Updates sicher ausrollen ausführlich beschrieben.

Vorbeugung für die Zukunft

• Core-Updates nicht automatisch für Major-Releases aktivieren, Minor- und Security-Releases dagegen schon.
• Staging-Umgebung nutzen und dort die tatsächliche Plugin-Kombination testen, nicht nur „WordPress startet“.
• Ein Zeitfenster von 48 bis 72 Stunden nach einem Major-Release abwarten. Die meisten Inkompatibilitäten dieser Art werden in diesem Fenster sichtbar.
• Uptime-Monitoring einrichten, das den HTTP-Statuscode prüft. Ein Fatal Error liefert 500, das fällt sofort auf.
• Zugang zu SFTP und Datenbank griffbereit halten, bevor du ihn brauchst.

Welche Änderungen in 7.1 sonst noch Bruchpotenzial haben, steht im Überblick zu WordPress 7.1. Der erzwungene iframed Editor betrifft deutlich mehr Installationen als dieser Caching-Fehler, fällt nur weniger spektakulär aus.

Fazit

Der Fehler sieht dramatisch aus, ist aber in unter fünf Minuten behoben, wenn man weiß, wo man ansetzt. Unangenehm wird er dort, wo niemand das Monitoring im Blick hat und die Seite stundenlang mit einem 500er dasteht, oder wo ein Betreiber ohne SFTP-Zugang vor einer toten Seite sitzt.

---

Quellen

• WP Rocket Knowledge Base: Fatal error on WordPress 7.1
• WP Rocket Post-Mortem: The WordPress 7.1 Outage
• GitHub Issue #8596: Fatal TypeError in Cloudflare.php, gemeldet am 6. Juli 2026
• Wordify: Technische Analyse des TypeError