Sådan opgraderer du PHP på kunders WordPress-sites uden at ødelægge dem

PHP’s sikkerhedsudgivelse i oktober 2026 var en nyttig påmindelse: nogle rettelser kommer ikke fra en WordPress-opdatering. Når hullet sidder i selve PHP, er rettelsen en nyere PHP-version på serveren, og sites på en gren, der ikke længere får sikkerhedsrettelser, får slet ingen rettelse. Denne guide er en rutine, du kan køre på hvert kundesite for at flytte det til en understøttet PHP-version uden overraskelser.

Hvorfor PHP-versionen betyder mere, end det ser ud til

Hver PHP-gren får sikkerhedsrettelser i en begrænset periode. Når grenen holder op med at få dem, forbliver ethvert nyt hul åbent, uanset hvor omhyggeligt du opdaterer WordPress, plugins og temaer. PHP 8.1 og ældre får ikke længere officielle sikkerhedsrettelser. Se php.net/supported-versions for de aktuelle datoer for hver gren.

Der er en anden grund. Udviklere af plugins og temaer dropper med tiden understøttelsen af gamle PHP-versioner. Et site, der bliver på en gammel gren, mister langsomt adgangen til plugin-opdateringer og dermed til sikkerhedsrettelser i selve pluginsene.

Trin 1: noter PHP-versionen på hvert site

I WordPress finder du den under Værktøjer → Webstedets helbred → Info → Server. Dit hostingpanel viser den også. Noter for hvert site PHP-versionen, WordPress-versionen, temaet, page builderen, om det kører WooCommerce, og om der er tilpasset kode i et child-tema eller et must-use-plugin.

Sorter derefter listen. Start med de ældste PHP-versioner og inden for dem med de sites, der tjener penge eller samler henvendelser: shops, bookingsites og sites med vigtige formularer.

Trin 2: find det, der vil blokere skiftet

De fleste PHP-opgraderinger går galt på grund af ét gammelt plugin, et forladt tema eller et stykke tilpasset kode. Led efter dem, før du skifter:

• Plugins og temaer, der ikke er blevet opdateret i to år eller mere. Tjek linjerne “Requires PHP” og “Tested up to” på deres pluginside.
• Gamle versioner af page buildere og premium-plugins med udløbet licens, så sitet aldrig fik de versioner, der understøtter nyere PHP.
• Tilpasset kode i functions.php eller must-use-plugins. Funktioner som each() og create_function() blev fjernet i PHP 8.0, og PHP 8.2 advarer om dynamiske properties.
• Kompatibilitetsscannere kan hjælpe, men de giver falske alarmer. Se deres resultat som en startliste, ikke en dom.

Opdater først WordPress, plugins og temaer, mens sitet stadig kører på den nuværende PHP-version. Nyere pluginversioner understøtter som regel nyere PHP. Lav opdateringerne og PHP-skiftet på forskellige dage, så du ved, hvilken ændring der skabte et problem.

Trin 3: test først på en kopi

Lav en staging-kopi af sitet, og sæt den til mål-versionen af PHP. Hos de fleste hosts vælger du PHP-versionen pr. site. Slå WP_DEBUG_LOG til på kopien, så fejl havner i en logfil i stedet for på skærmen.

Klik derefter igennem det, der betyder noget for denne kunde:

• Forsiden og de to eller tre mest besøgte sider, på computer og mobil.
• Hver vigtig formular: send den, og tjek, at e-mailen kommer frem.
• I en shop: læg i kurv, gå til kassen med en testordre, kontosiden.
• I administrationen: editoren og page builderen åbner, upload af medier virker, indstillingssider indlæses.

Læs bagefter wp-content/debug.log. Fatale fejl skal rettes, før du går live. Deprecation-meddelelser er advarsler om næste opgradering; skriv dem ned, de kan vente. Ved at sammenligne skærmbilleder af de vigtigste sider før og efter fanger du de problemer, der ikke giver en fejl, som en slider eller menu, der ikke længere vises.

Trin 4: skift live-sitet på et roligt tidspunkt

Vælg et tidspunkt med lidt trafik. Tag en frisk backup af filer og database lige før skiftet, og noter den nuværende PHP-version. Skift PHP i hostingpanelet, ryd sidecachen og en eventuel objektcache, og lav de samme tjek som på kopien. Lad fejllogning til en fil være slået til en dag eller to, så du fanger den side, ingen besøgte under dit tjek.

Fortæl kunden med en eller to sætninger, hvad du gjorde og hvorfor. En PHP-opgradering er usynlig, når den går godt, og det er godt vedligeholdelsesarbejde, som de bør kende til.

Trin 5: kend vejen tilbage

At rulle en PHP-opgradering tilbage er som regel enkelt: skift versionen tilbage i hostingpanelet. Derfor skrev du den gamle version ned. Viser ét plugin sig at være problemet, har du tre muligheder: opdatere det, erstatte det eller blive kort tid på den forrige understøttede gren, mens du løser det. Bliv aldrig længere end nødvendigt på en gren uden understøttelse.

Når det haster: en sikkerhedsudgivelse til selve PHP

Når der offentliggøres et hul i PHP, løser en WordPress-opdatering det ikke. Spørg din host, om patch-udgivelsen til din gren er installeret. En patch inden for samme gren, for eksempel fra én 8.3-udgivelse til den næste, ødelægger sjældent noget. Det risikable er springet til en ny gren, og det er netop det, denne guide forbereder dig på. Sites på en gren uden sikkerhedsrettelser er dem, du planlægger først.

Opdatering 23. oktober 2026: et andet PHP-problem med lavere risiko. To dage efter den kritiske udgivelse offentliggjorde PHP en informativ advarsel om CVE-2026-115560 i session upload progress (php.net). PHP vurderer udnyttelse som usandsynlig: det kræver flere bestemte indstillinger og kode på samme tid. Der er endnu ingen rettelse; den kommer i den næste almindelige PHP-udgivelse. Indtil da skal du først gøre opdateringerne fra 21. oktober færdige og derefter bede din host om at sætte session.upload_progress.enabled til off i php.ini eller PHP-FPM-puljen og genstarte PHP. Hvis det sættes fra WordPress eller en .user.ini -fil, kan det komme for sent på PHP-FPM.

Sådan håndterer Verploy PHP-opgraderinger

På sites med en gammel PHP-version viser Verploys PHP-opgraderingstjek, hvad der blokerer skiftet, og i hvilken rækkefølge du skal løse det. Hver opdatering bliver tjekket, og de risikable testes først på en kopi. Se, hvordan det passer ind i en fuld vedligeholdelsesrutine, på WordPress-vedligeholdelse for bureauer.