WordPress 7.1 hat Sites abgeschossen — nicht wegen der Lücke, wegen Plugins

Kurzer Reality-Check: WordPress 7.1 „Mary Lou“ ist seit dem 19. August 2026 draußen. Das ist kein Security-Patch wie 7.0.4. Es ist ein Feature-Release — und bei einem Teil der VPS-Sites stand danach nur noch „Es gab einen kritischen Fehler auf deiner Website“. Nicht weil Core kaputt ist. Weil Plugins Hook-IDs als String behandelt haben, und 7.1 daraus Integer macht.

WP Rocket (bis 3.23.2.1) und WP Activity Log (5.6.5) sind die bekanntesten Fälle. Der Rocket-Fix kam am 20. August als 3.23.2.2. Activity Log hat 5.6.6 nachgelegt. Wer 7.1 per Auto-Update ohne Staging gezogen hat, konnte sich oft nicht mehr ins Backend klicken.

Was passiert ist

WordPress hat die ID-Erzeugung für Hook-Callbacks umgestellt: Performance, spl_object_id statt Hash. Für Core ist das harmlos. Plugins, die diese Keys durch substr() oder strtolower() jagen und einen String erwarten, werfen unter PHP 8 einen Fatal Error — auf jeder Anfrage, Frontend und Admin.

Das ist die andere Seite von „immer sofort updaten“. 7.0.4 musstet ihr einspielen. 7.1 solltet ihr einspielen — aber nicht blind auf Production, wenn Cache- und Audit-Plugins mitlaufen.

Wenn die Site weiß ist

1. Nicht Core zurückdrehen als ersten Schritt. Der Fehler sitzt im Plugin. Downgrade von 7.1 löscht das Symptom und lässt euch auf einem alten Zweig.
2. Zugriff über Dateien, nicht über wp-admin. Im Panel oder per SFTP den Ordner des betroffenen Plugins umbenennen — typisch wp-content/plugins/wp-rocket oder wp-security-audit-log. WordPress lädt ihn dann nicht mehr. Die Site kommt zurück.
3. Einloggen, Plugin aktualisieren, Ordner wieder richtig benennen. Rocket mindestens 3.23.2.2, Activity Log 5.6.6. Danach Cache leeren.
4. PHP-Log lesen, nicht raten. Die Meldung nennt Datei und Plugin. Nur das eine umbenennen, nicht den ganzen plugins-Ordner.

Keine Payloads, keine „so reproduziert ihr den Crash“. Wer eine Site betreibt, braucht den Plugin-Stand und einen Weg zurück ins Backend.

Checkliste, bevor ihr 7.1 das nächste Mal zieht

1. Snapshot plus Datenbank. Auf einem Root oder VPS in Frankfurt entscheidet ihr den Zeitpunkt — nicht der Auto-Updater.
2. Plugins zuerst. Cache, Security, SEO, Page-Builder. „Tested up to 7.1“ ist die Mindesthürde, kein Freibrief.
3. Staging, dann Production. Klon, 7.1 dort, fünf Minuten klicken. Erst dann Live.
4. Auto-Updates für Core eng führen. Security-Minors (7.0.4) dürfen automatisch. Major wie 7.1 gehört in ein Fenster, das ihr selbst anstößt.
5. Imagick/Ghostscript und Autoren-Rechte bleiben das Thema von 7.0.4. 7.1 ersetzt diesen Patch nicht.

Was das für VPS-Kunden heißt

Shared-Hoster spielen 7.1 oft zentral aus und fangen Plugin-Leichen mit. Auf einem selbst verwalteten VPS tut das niemand. Dateizugriff im Panel ist dann der Unterschied zwischen fünf Minuten und einem Ticket um Mitternacht.

V-Server bestellen →
Root-Server Linux · WordPress 7.1 „Mary Lou“ · WP Rocket: 7.1-Fix