WordPress 7.1 wurde am 19. August veröffentlicht. Kurz darauf stießen einige Websites, auf denen WP Rocket lief, auf einen schwerwiegenden Fehler.
Das Problem wurde nicht am Tag der Veröffentlichung entdeckt. Es war bereits öffentlich am 6. Juli gemeldet, während WordPress 7.1 noch in der Alpha-Phase war.
Der Bericht enthielt Schritte zur Reproduktion, identifizierte die Fehlerquelle und schlug eine einzeilige Korrektur vor. Dann vergingen … mehr als sechs Wochen.
Der Zeitraum von 45 Tagen
6. Juli 2026
Der schwerwiegende Fehler wurde öffentlich gemeldet, einschließlich Reproduktionsschritten, der Fehlerquelle und eines Vorschlags für eine einzeilige Korrektur.
15. Juli 2026
WordPress 7.1 Beta 1 wurde veröffentlicht und damit der öffentliche Betatest begonnen.
5. August 2026
WordPress 7.1 ging in die Release-Candidate-Tests über. Das Kompatibilitätsproblem war weiterhin ungelöst.
19. August 2026
WordPress 7.1 wurde veröffentlicht. Auf Websites mit betroffenen WP-Rocket-Konfigurationen trat der schwerwiegende Fehler erstmals auf.
20. August 2026
WP Rocket 3.23.2.2 veröffentlichte die Korrektur, 45 Tage nach dem ursprünglichen Bericht.
Während dieses Zeitraums durchlief WordPress 7.1 vier Betaversionen und vier Release Candidates, laut dem Veröffentlichungsplan. Außerdem veröffentlichte WP Rocket vier Plugin-Updates, bevor die Kompatibilitätskorrektur eintraf.
Dieser Zeitplan wirft berechtigterweise die Frage auf, was Besitzer von WordPress-Websites von den Plugins erwarten sollten, auf die sie angewiesen sind.
Kompatibilität ist Teil der Performance
Fehler treten in jedem Softwareprojekt auf, auch in unserem. Meldungen zu einer Alpha-Version können unvollständig, auf eine Umgebung beschränkt oder durch Änderungen vor der finalen Veröffentlichung beeinflusst sein. Plugin-Entwickler müssen sie sorgfältig untersuchen und priorisieren.
Dieser Bericht war ungewöhnlich präzise. Er identifizierte die genaue Funktion, die den falschen Datentyp erhielt, enthielt Schritte zur Reproduktion des schwerwiegenden Fehlers und schlug eine Korrektur vor.
Es war auch Zeit vorhanden, den Fehler zu testen. WordPress 7.1s öffentlicher Veröffentlichungszyklus umfasste ab dem 15. Juli Betaversionen und ab dem 5. August Release Candidates.
Performance-Plugins arbeiten tief im Inneren von WordPress. Sie verändern, wie Seiten zwischengespeichert, Skripte geladen, CSS ausgeliefert und Ressourcen bereitgestellt werden. Dadurch wird Kompatibilitätsarbeit besonders wichtig.
Eine schnellere Website hilft nicht viel, wenn ein normales WordPress-Update sie offline schalten kann.
Dies war keine offengelegte Sicherheitslücke. Es handelte sich um einen Kompatibilitätsfehler, der die Verfügbarkeit von Websites in bestimmten Konfigurationen beeinträchtigte. Dieser technische Unterschied ist wichtig, aber für den Besitzer einer betroffenen Website war das Ergebnis dennoch schwerwiegend.
Wie Jetpack mit schwerwiegenden Sicherheitsmeldungen umgeht
Das WP-Rocket-Problem wurde nicht als Sicherheitslücke gemeldet, daher wäre es nicht korrekt, es direkt mit einem Exploit zu vergleichen. Unsere Sicherheitsrichtlinien sind dennoch ein gutes Beispiel für den Standard, den wir beim Umgang mit schwerwiegenden Meldungen gesetzt haben.
Jetpack hat eine öffentliche Sicherheitsrichtlinie und nimmt am von Automattic betriebenen HackerOne-Bug-Bounty-Programm. Intern deckt unser Prozess Meldungen ab, die über HackerOne, GitHub und unsere eigenen internen Automattic-Teams eingehen.
- Den Bericht triagieren. Wir prüfen, ob das Problem ausgenutzt werden kann, welche Versionen betroffen sind, wie viele Websites möglicherweise gefährdet sind und ob WordPress.com betroffen ist.
- Die richtigen Teams einbeziehen. Jetpack Engineering stimmt sich mit dem Sicherheitsteam von Automattic sowie mit Support, Kommunikation, Recht, Hosting-Partnern oder WordPress.org ab, wenn die Situation dies erfordert.
- Die Veröffentlichung an den Schweregrad anpassen. Kritische Sicherheitslücken erfordern so schnell wie möglich einen Hotfix sowie Backports für betroffene Veröffentlichungen. Probleme mit hohem Schweregrad erhalten ein Point-Release. Probleme mit geringerem Risiko erhalten dennoch einen klaren Veröffentlichungsweg.
- Die Korrektur überprüfen. Sicherheitspatches werden einer Sicherheitsprüfung unterzogen. Wenn das Risiko dringend ist, können Tests beschleunigt werden, sie werden jedoch nicht übersprungen.
- Kommunizieren und daraus lernen. Bei schwerwiegenden Vorfällen gibt es klare Verantwortliche für Entwicklung, Benutzerkommunikation und Support. Anschließend prüfen wir, was passiert ist und was geändert werden sollte.
Keine Richtlinie macht ein Softwareteam perfekt. Sie sorgt jedoch für klare Erwartungen. Ein glaubwürdiger Bericht braucht eine verantwortliche Person, eine Schweregradentscheidung, einen Veröffentlichungsweg und konsequente Nachverfolgung.
Jetzt ist ein guter Zeitpunkt, deine Performance-Konfiguration zu überprüfen
WordPress-Performance-Konfigurationen wachsen im Laufe der Zeit meist an. Zuerst wird ein Caching-Plugin hinzugefügt. Dann folgen Bildoptimierung, ein CDN, das Zurückstellen von Skripten, Critical CSS und ein weiteres Tool zur Messung der Ergebnisse.
Schließlich können mehrere Plugins dieselben Teile einer Website verändern.
Wenn du WP Rocket hauptsächlich für Caching und Frontend-Optimierung verwendest, Jetpack Boost deckt viele dieser Aufgaben ebenfalls ab:
- Seiten-Caching
- Critical CSS
- Nicht notwendiges JavaScript zurückstellen
- CSS und JavaScript zusammenfassen und minimieren
- Bildoptimierung über das globale CDN von Jetpack
- Integrierte Performance-Bewertungen
Diese Funktionen können einzeln aktiviert werden, sodass leichter zu verstehen ist, was jede Änderung bewirkt. Die kostenlose Version umfasst Seiten-Caching, die manuelle Erstellung von Critical CSS, das Zurückstellen von JavaScript, Bild-CDN, sowie die Zusammenfassung von CSS und JavaScript.
Du möchtest nicht alles, was Jetpack bietet? Kein Problem. Jetpack Boost ist auch ein eigenständiges Plugin. Du musst nicht das zentrale Jetpack-Plugin installieren, um es zu verwenden.
So wechselst du von WP Rocket zu Jetpack Boost
Bevor du Performance-Plugins änderst, sichere deine Website oder teste die Änderung auf einer Staging-Website.
Wenn deine Website bereits vom schwerwiegenden Fehler in WordPress 7.1 betroffen ist, aktualisiere WP Rocket zuerst auf Version 3.23.2.2. Sobald die Website wieder funktioniert:
- Zeichne deine aktuellen Performance-Ergebnisse auf, damit du einen Ausgangswert hast.
- Deaktiviere WP Rocket und leere alle verbleibenden Server- oder CDN-Caches.
- Installiere und aktiviere Jetpack Boost.
- Aktiviere die Performance-Module nacheinander.
- Teste nach jeder Änderung deine Startseite, Beiträge, Formulare, Suche, Anmeldung, den Checkout und andere wichtige Abläufe.
- Vergleiche die Ergebnisse mit deinem ursprünglichen Ausgangswert.
Vermeide es, dieselbe Optimierung in mehreren Plugins zu aktivieren. Zwei Tools, die versuchen, dasselbe JavaScript zurückzustellen oder denselben Cache zu verwalten, können neue Kompatibilitätsprobleme verursachen.
Jede WordPress-Website ist anders, daher messen Sie das Ergebnis, statt anzunehmen, dass jede Optimierung hilfreich sein wird.
Plugin-Updates erfordern Vertrauen
Website-Betreiber verlassen sich darauf, dass Plugin-Teams die Entwicklung von WordPress verfolgen, bevorstehende Veröffentlichungen testen und glaubwürdige Kompatibilitätsberichte untersuchen, bevor diese Veröffentlichungen die Produktionsumgebung erreichen.
Bei dem Problem mit WP Rocket geht es nicht darum, fehlerfreie Software zu erwarten. Es geht darum, was passiert, nachdem ein ernstes Problem bereits gemeldet wurde und die vorgeschlagene Lösung bekannt ist.
Wenn dieser Vorfall Sie dazu bringt, WP Rocket noch einmal zu überdenken, bietet Jetpack Boost Ihnen einen praktischen Weg, Ihr Performance-Setup zu vereinfachen und dabei die für Ihre Website erforderlichen Optimierungen beizubehalten.
Jetpack 