Oppdater WP Rocket til 3.23.2.2 før WordPress 7.1

#Hva som krasjet

Du oppdaterte til WordPress 7.1, og nettstedet ble hvitt. wp-admin er nede. admin-ajax er nede. REST er nede. WP-CLI dør med samme stack. PHP-loggen gjentar én linje på hver forespørsel:

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 reproduserte det fra ende til annen på et testnettsted og publiserte stacken 20. august 2026. Den fatale feilen fyrer på init, mens WordPress fortsatt starter, så forsiden og dashbordet dør sammen. Å slå på WP_DEBUG skriver ikke alltid noe på skjermen. Feilloggen er det pålitelige stedet.

Dette er en WP Rocket-feil, ikke en vertfeil, og ikke «WordPress 7.1 er ødelagt». Nettsteder uten WP Rocket traff ikke denne TypeError. Nettsteder på WP Rocket 3.23.2.2 treffer den ikke. Changelog-linjen er: “Fixed the Fatal Type Error appearing after update to WordPress Core 7.1 in some configurations.”

Kodebanen ligger i Cloudflare-kompatibilitetsmodulen. Du trenger ikke en Cloudflare-sone for at den skal kjøre. Wordify var tydelig: modulen kjører på hver forespørsel, enten Cloudflare-pluginet er installert eller ikke.

#Tre brikker som er ufarlige hver for seg

WordPress 7.1 endret hvordan ID-er for hook-tilbakekall bygges. Trac-sak 65919 er kjerneendringen. Fram til 7.0.x brukte _wp_filter_build_unique_id() spl_object_hash(), en 32-tegns heksadesimal streng. 7.1 byttet til spl_object_id(), et lite heltall castet til streng. David Levine hos rtCamp pekte senere på samme sak da den offisielle WordPress-kontoen på X skrev «this wasn’t a bug in 7.1». TypeError ligger i pluginen. Typen på nøkkelen endret seg i kjernen. Begge setningene kan være sanne.

PHP lagrer deretter numeriske strengnøkler som heltall. Når "5292" brukes som arraynøkkel i $wp_filter, beholder PHP den som 5292. Etter 7.1 har en closure hengt på en action en heltallsnøkkel. Før 7.1 var hver nøkkel en streng.

WP Rocket antar at de nøklene er strenger, med strict_types=1 i Cloudflare.php. På init går den gjennom tilbakekall på deleted_post og transition_post_status og kaller substr() på hver nøkkel. Strenge typer nekter å caste heltallet. Fatal.

Wordify publiserte løkken:

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

En ren WordPress pluss WP Rocket overlever ofte. Austin Ginder fant det. Legg til et plugin som henger en closure på deleted_post med prioritet 10, eller på transition_post_status med PHP_INT_MAX, og neste forespørsel dør. Elementor Pro er det utbredte eksempelet. Contact Form 7 Redirection er et annet. Det andre pluginet gjør ingenting galt. Å henge en closure er vanlig WordPress.

Matt Cromwell noterte ironien på X: kjerneendringen var en ytelsesforbedring, som er produktet WP Rocket selger.

#GitHub-rapporten som lå i seks uker

wp-media/wp-rocket issue 8596 ble opprettet 6. juli 2026, under 7.1-betaen. Rapporten navnga TypeError og foreslo en typecast til streng på én linje. The Repository, 21. august: WP Rocket gikk gjennom den samme dag, QA klarte ikke å reprodusere den i automatiserte tester, og saken falt. Den fikk aldri en eier.

WordPress 7.1 ble lansert 19. august 2026, avslutningsdagen av WordCamp US i Phoenix. Ginder skrev samme dag: WP Rocket-nettsteder i Anchor Hosting-parken gikk offline etter 7.1-hoppet. Han lappet pluginen for hånd for å få dem opp igjen.

To GitHub-saker til, 8740 og 8741, kom dagen etter lansering. WP Rocket la ut et varsel: ikke oppdater til 7.1 før en fiks er klar, med en støtteartikkel på docs.wp-rocket.me/article/1927. Senere 20. august sendte de ut 3.23.2.2, typecasten på én linje fra julirapporten. Wordify verifiserte fiksen på samme krasj de hadde satt opp på nytt med 3.23.2.1.

GitHub-pullen er wp-media/wp-rocket#8745.

#Hvem som gikk ned

Ginders park-tall, 20. august: 124 av 332 produksjonsnettsteder som kjørte WP Rocket kastet fatal feil, 37 prosent. Hvert krasj var WordPress 7.1 + PHP 8.x + Cloudflare.php.

WP Rockets senere etteranalyse, dekket av The Repository 27. august, anslo om lag 27 prosent av brukerbasen i risikosonen og om lag 10 prosent faktisk rammet. Administrerende direktør Rémy Lamiot sa at Elementor Pro, tross installasjonsbasen og tross at det var én av utløserne, ikke sto på kompatibilitetslisten de testet. Julirapporten hadde ingen eier. «This cost real time and real trust,» skrev han.

De to prosentene er ikke samme måling. Ginder telte en administrert park som allerede kjørte WP Rocket. WP Rocket telte hele brukerbasen, inkludert nettsteder som aldri tok 7.1 den uken og nettsteder uten det andre pluginet. Siter begge. Ikke trekk gjennomsnitt av dem.

Wordifys første kundenettsted oppdaterte kjernen kl. 01:55 UTC. Den første fatale feilen traff loggen tre sekunder senere. Support deaktiverte pluginen. Om lag 35 minutter fra ende til annen, mesteparten diagnose, fordi ingen ennå hadde knyttet «7.1» til «WP Rocket».

Andrew Hoyer skrev at han hadde advart teamet sitt om 7.1 og likevel våknet til dusinvis av ødelagte nettsteder. Linjen hans: test alpha, beta og RC på din egen stack, framfor å stole på leverandøren. Steve Jones spurte om folk oppdaterte produksjon i timen en major landet, uten tilbakerulling. Begge spørsmålene er jobben til en vedlikeholdsavtale. De er ikke et merkevareargument.

#Trygg rekkefølge

Hvis nettstedet fortsatt står på WordPress 7.0.x og WP Rocket er eldre enn 3.23.2.2:

1. Klone til staging.
2. Oppdater WP Rocket til 3.23.2.2 på staging. Bekreft at wp-admin og en utlogget forside laster.
3. Ta deretter WordPress 7.1 på staging. Treff innlogging, kasse hvis WooCommerce, et skjema, cron.
4. Gjenta samme rekkefølge i produksjon: plugin først, kjerne deretter.

Hvis automatiske oppdateringer allerede har tatt 7.1 og nettstedet er hvitt, hopp over den vanlige rekkefølgen. Deaktiver først.

Ikke aktiver 3.23.2.1 på nytt på 7.1. WP Medias støtteartikkel er eksplisitt: hvis ingen oppdatering vises i pluginlisten, følg guiden deres for manglende oppdatering. Å aktivere den ødelagte versjonen tar nettstedet ned igjen.

Svært gamle WP Rocket-bygg som er eldre enn Cloudflare.php-løkken, rammes ikke. Wordify satte det berørte båndet til grovt 3.16 til og med 3.23.2.1. Er du usikker, oppdater til 3.23.2.2 likevel. Det er versjonen med typecasten til streng.

Vi har allerede dekket hva 7.1 faktisk lanserte, og hva som ble kuttet, i veikartnotatet for WordPress 7.1. Innleggseditoren i iframe er et eget utviklerbrudd. Detaljene ligger i notatet om innleggseditoren i iframe. Denne teksten handler bare om Rocket-feilen.

#Hvis wp-admin allerede er hvit

Ikke slett Cloudflare.php. Wordify: klassen er koblet inn i pluginets container, og å fjerne filen bytter denne fatale feilen med en annen.

WP-CLI. WP-CLI laster plugins, så et rent wp plugin deactivate wp-rocket uten hopp-flagg dør. Hopp over pluginen mens du deaktiverer den:

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

SFTP. Gi wp-content/plugins/wp-rocket navnet wp-rocket.off. WordPress behandler en omdøpt mappe som deaktivert på neste forespørsel.

Oppdater deretter til 3.23.2.2 fra wp-admin, som er oppe igjen, og aktiver.

Tilbakerulling til 7.0.4 fra en sikkerhetskopi tatt før oppdateringen gjenoppretter også nettstedet. Det er den tregere stien. Den kaster 7.1-filene du allerede skrev til disk. Bruk den når du ikke når SFTP eller WP-CLI.

En sidecache på verten (LiteSpeed, nginx FastCGI, Cloudflare-cache av HTML) kan fortsette å servere en siste god side til anonyme besøkende mens wp-admin er død. Det skjuler bruddet for noen kunder og forsinker saken. Sjekk feilloggen, ikke bare forsiden.

En typisk norsk Woo-butikk hos Domeneshop treffer nøyaktig denne kombinasjonen: WordPress, WooCommerce, WP Rocket, ofte Elementor Pro, og Vipps i kassen. Automatisk kjerneoppdatering kan ta 7.1 over natten. Forsiden ser da frisk ut fordi vertens sidecache fortsatt serverer HTML, mens kassen og wp-admin er hvite. På delt Domeneshop-plan uten SSH er SFTP-omdøpingen av mappen veien. På Domeneshop VPS med root er WP-CLI raskere: samme kommando som over, wp plugin deactivate wp-rocket --skip-plugins=wp-rocket. Deretter 3.23.2.2, deretter aktivering. Ikke rør Cloudflare.php alene der heller.

#Slik tester vi en kjerneoppdatering

WPPoland (Mariusz Szatkowski) behandler en major som en sjekk i tre lag, ikke som en kalenderhendelse.

Staging er en klone, ikke en underkatalog på produksjon. Samme PHP, samme objektcache, samme plugins. Vi tar pluginoppdateringene som har kjent inkompatibilitet først. For 7.1 startet den listen med WP Rocket 3.23.2.2. Deretter kjerne. Deretter en røyktest: innlogging, et lagring i innleggseditoren (nå alltid i iframe), WooCommerce-handlekurv og kasse hvis nettstedet har dem, en skjemapost, et cron-kjøring.

Vi stoler ikke på «WP Rocket sa de testet 7.1». De testet. Suiten deres gikk glipp av heltallsnøkkelen pluss en closure fra et annet plugin. Ginders rene installasjon krasjet ikke. Kombinasjonen gjorde det. Kombinasjonen er det et kundenettsted faktisk er.

I produksjon tar vi en navngitt sikkerhetskopi fra før hoppet og et vindu på 15 minutter der noen følger feilloggen, ikke bare oppetids-ping. En hvit forside med 200 fra HTML-cache er ikke godkjent.

En typisk kundeklone i denne butikken er WordPress + WooCommerce eller Elementor + WP Rocket + et skjemaplugin. Det er kombinasjonen Ginder og Wordify beskrev. Vi venter ikke på leverandørens «we tested 7.1»-tweet. Vi tar 7.1 på klonen, ber om / og /wp-admin/, og greper PHP-loggen etter TypeError og Cloudflare.php. Er loggen stille og begge URL-ene returnerer 200 uten plugin-hopp, kan hoppet gå til produksjon i samme rekkefølge.

På en norsk Woo-butikk hos Domeneshop er røyktesten konkret: innlogging, en vare i handlekurven, kasse med Vipps, et kontaktskjema, cron. WP-CLI på VPS-en er både diagnose og gjenoppretting. wp plugin list viser versjonen før hoppet. Etter 3.23.2.2 kjører vi wp plugin get wp-rocket --field=version og leser feilloggen på nytt. Delt Domeneshop uten SSH får samme rekkefølge via SFTP og panelet. Verktøyet endrer seg. Rekkefølgen gjør det ikke.

PHP-versjon er del av klonen. TypeError er en PHP 8-feil med strenge typer. En vert som fortsatt står på PHP 7.4 ville ikke kastet akkurat denne fatale feilen. Det er ikke en grunn til å bli på 7.4. Det er en grunn til å teste 8.2 eller 8.3 med samme pluginsett du kjører i produksjon, ikke med en bar WordPress.

Det er WordPress-vedlikehold i ett avsnitt. Staging først. Plugin først når leverandøren har en kjent versjonsbinding. Kjerne deretter. Helsesjekk etterpå. Skriftlig tilbud etter en kort oppstart.

Hvis den offentlige flaten allerede ligger på Cloudflare Workers eller Pages, dreper PHP-feilen likevel wp-admin og enhver origin-rute. Kant-HTML-cache er ikke en erstatning for et plugin som kaster fatal feil på init. Cloudflare-edge-pillaren er leveringslaget. Denne hendelsen er origin-laget.

#Automatiske oppdateringer og 7.1.1

Wordify advarte om at 7.1-autooppdateringer rullet ut samme uke. Et nettsted ingen rørte, kunne likevel gå fra friskt til nede over natten.

Adam Silverstein åpnet Trac 65920 20. august: en GitHub Actions-arbeidsflyt for å teste de 100 største katalog-pluginene mot uutsendt WordPress. Utkast-PR 13198, med milepæl 7.2. Han noterte i saken at akkurat denne hendelsen ikke ville blitt fanget, fordi WP Rocket er premium og katalog-API-et dekker gratis plugins. Samme klasse av typeendrings-feil kan likevel treffe et gratis plugin med millioner av installasjoner. Det er poenget med arbeidsflyten.

Aaron Jorbin etterlyste frivillige til å styre 7.1.x. 7.1.1 var skissert mellom 1. og 24. september 2026. Behandle 7.1.1 på samme måte: staging, deretter produksjon. Hvis 65919s heltallsnøkler får en kompatibilitetslapp i 7.1.1, er det ekstra forsikring. Det er ikke en grunn til å hoppe over 3.23.2.2.

Jeffrey Paul støttet Silversteins sak: gjentatte fatale feil etter majore ligger innenfor kjernens bekymringssfære, selv når den ødelagte filen sitter i et plugin. Det er den ærlige splittelsen. Kjernen kan teste katalog-plugins. Kjernen kan ikke teste premium-plugins den ikke har. Nettstedseieren, eller den som sitter på vedlikeholdsavtalen, eier fortsatt klonen.

#Det vi ikke hevder

Vi sier ikke dump WP Rocket. 3.23.2.2 er gjeldende bygg med typecasten. Cache-plugins gjør fortsatt nytten sin på PHP-origin.

Vi sier ikke hopp over WordPress 7.1. Responsiv styling, klientsidig media, den vedvarende administrasjonslinjen og editoren i iframe ble lansert. Veikartnotatet lister hva som landet og hva som ikke gjorde det.

Vi siterer ikke WP Rockets priser. Tredjeparts lisensavgifter er listen deres. Vedlikeholdsarbeidet vårt er et individuelt tilbud.

Vi finner ikke opp en prosent for «hele internett». Ginders 37 prosent er en park. WP Rockets 10 prosent er deres anslag for brukerbasen. Begge er kildebelagte. Ingen av dem er en folketelling.

Sist oppdatert 1. september 2026. Kilder: The Repository (21. og 27. august 2026), Wordifys stack-spor-gjennomgang (20. august), GitHub-sak 8596 og pull 8745, Trac 65919 og 65920, WP Rocket 3.23.2.2 changelog og støtteartikkel 1927, Austin Ginder på X, Rémy Lamiots etteranalyse sitert via The Repository.