Så uppgraderar du PHP på kunders WordPress-sajter utan att förstöra dem

PHP:s säkerhetsversion i oktober 2026 var en nyttig påminnelse: vissa rättningar kommer inte från en WordPress-uppdatering. När bristen sitter i PHP självt är rättningen en nyare PHP-version på servern, och sajter på en gren som inte längre får säkerhetsrättningar får ingen rättning alls. Den här guiden är en rutin du kan köra på varje kundsajt för att flytta den till en PHP-version med stöd, utan överraskningar.

Varför PHP-versionen spelar större roll än det ser ut

Varje PHP-gren får säkerhetsrättningar under en begränsad tid. När grenen slutar få dem förblir varje ny brist öppen, hur noga du än uppdaterar WordPress, plugins och teman. PHP 8.1 och äldre får inte längre officiella säkerhetsrättningar. Se php.net/supported-versions för aktuella datum för varje gren.

Det finns ett andra skäl. Utvecklare av plugins och teman slutar med tiden att stödja gamla PHP-versioner. En sajt som stannar på en gammal gren förlorar sakta tillgången till plugin-uppdateringar och därmed till säkerhetsrättningar i själva pluginen.

Steg 1: anteckna PHP-versionen för varje sajt

I WordPress hittar du den under Verktyg → Webbplatsens hälsa → Info → Server. Din hostingpanel visar den också. Anteckna för varje sajt PHP-versionen, WordPress-versionen, temat, sidbyggaren, om WooCommerce körs och om det finns egen kod i ett barntema eller ett must-use-plugin.

Sortera sedan listan. Börja med de äldsta PHP-versionerna och inom dem med sajterna som drar in pengar eller förfrågningar: butiker, bokningssajter och sajter med viktiga formulär.

Steg 2: hitta det som kommer att blockera bytet

De flesta PHP-uppgraderingar fastnar på ett gammalt plugin, ett övergivet tema eller en bit egen kod. Leta efter dem innan du byter:

• Plugins och teman som inte har uppdaterats på två år eller mer. Kontrollera raderna ”Requires PHP” och ”Tested up to” på deras pluginsida.
• Gamla versioner av sidbyggare och premiumplugins med utgången licens, så att sajten aldrig fick versionerna som stödjer nyare PHP.
• Egen kod i functions.php eller must-use-plugins. Funktioner som each() och create_function() togs bort i PHP 8.0, och PHP 8.2 varnar för dynamiska egenskaper.
• Kompatibilitetsskannrar kan hjälpa, men de ger falsklarm. Se deras resultat som en startlista, inte ett utslag.

Uppdatera först WordPress, plugins och teman medan sajten fortfarande kör den nuvarande PHP-versionen. Nyare pluginversioner stödjer oftast nyare PHP. Gör uppdateringarna och PHP-bytet på olika dagar, så att du vet vilken ändring som orsakade ett problem.

Steg 3: testa först på en kopia

Gör en stagingkopia av sajten och ställ in den på mål-versionen av PHP. Hos de flesta webbhotell väljer du PHP-version per sajt. Slå på WP_DEBUG_LOG på kopian så att fel hamnar i en loggfil i stället för på skärmen.

Klicka sedan igenom det som är viktigt för den här kunden:

• Startsidan och de två eller tre mest besökta sidorna, på dator och mobil.
• Varje viktigt formulär: skicka det och kontrollera att mejlet kommer fram.
• I en butik: lägg i varukorgen, gå till kassan med en testorder, kontosidan.
• I adminpanelen: redigeraren och sidbyggaren öppnas, uppladdning av media fungerar, inställningssidor laddas.

Läs efteråt wp-content/debug.log. Fatala fel måste åtgärdas innan du går live. Deprecation-meddelanden är varningar inför nästa uppgradering; skriv ner dem, de kan vänta. Att jämföra skärmdumpar av de viktigaste sidorna före och efter fångar problemen som inte ger något fel, som en slider eller meny som inte längre visas.

Steg 4: byt på livesajten vid ett lugnt tillfälle

Välj ett tillfälle med lite trafik. Ta en färsk säkerhetskopia av filer och databas precis före bytet och anteckna den nuvarande PHP-versionen. Byt PHP i hostingpanelen, töm sidcachen och en eventuell objektcache och gör samma kontroller som på kopian. Låt felloggning till fil vara påslagen en dag eller två, så att du fångar sidan som ingen besökte under din kontroll.

Berätta för kunden med en eller två meningar vad du gjorde och varför. En PHP-uppgradering är osynlig när den går bra, och det är bra underhållsarbete som de bör känna till.

Steg 5: känn vägen tillbaka

Att backa en PHP-uppgradering är oftast enkelt: byt tillbaka versionen i hostingpanelen. Det är därför du antecknade den gamla versionen. Visar sig ett plugin vara problemet har du tre alternativ: uppdatera det, ersätta det eller stanna en kort tid på den föregående grenen med stöd medan du löser det. Stanna aldrig längre än nödvändigt på en gren utan stöd.

När det är brådskande: en säkerhetsversion för PHP självt

När en brist i PHP publiceras löser en WordPress-uppdatering den inte. Fråga ditt webbhotell om patchversionen för din gren har installerats. En patch inom samma gren, till exempel från en 8.3-version till nästa, förstör sällan något. Det riskabla är hoppet till en ny gren, och det är precis det den här guiden förbereder dig för. Sajter på en gren utan säkerhetsrättningar är de du planerar först.

Uppdatering 23 oktober 2026: ett andra PHP-problem med lägre risk. Två dagar efter den kritiska versionen publicerade PHP ett informativt meddelande om CVE-2026-115560 i session upload progress (php.net). PHP bedömer att utnyttjande är osannolikt: det kräver flera specifika inställningar och kod samtidigt. Det finns ingen rättning än; den kommer i nästa ordinarie PHP-version. Gör till dess först klart uppdateringarna från 21 oktober och be sedan ditt webbhotell att sätta session.upload_progress.enabled till off i php.ini eller PHP-FPM-poolen och starta om PHP. Att ställa in det från WordPress eller en .user.ini -fil kan komma för sent med PHP-FPM.

Så hanterar Verploy PHP-uppgraderingar

På sajter med en gammal PHP-version visar Verploys PHP-uppgraderingskontroll vad som blockerar bytet och i vilken ordning du åtgärdar det. Varje uppdatering kontrolleras, och de riskabla testas först på en kopia. Se hur det passar in i en fullständig underhållsrutin på WordPress-underhåll för byråer.