Kort svar: Går sitet i stykker efter et PHP-skift, så rul PHP-versionen tilbage i kontrolpanelet – det tager sekunder og fjerner presset. Find derefter synderen i PHP-loggen: stien i fejllinjen udpeger det plugin eller tema, der ikke er klar til den nye version. Opdatér eller udskift det, test hele skiftet på staging, og opgradér først live, når loggen er ren. Deprecated-beskeder vælter intet – kun fatal errors gør.
En nyere PHP-version er en af de billigste hastighedsforbedringer, et WordPress-site kan få – men skiftet kan vælte gamle plugins og temaer. Forskellen på et smertefrit skift og en hvid skærm ligger i rækkefølgen: test først, skift bagefter. Denne guide viser begge dele – og hvad du gør, hvis skaden allerede er sket.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Diagrammet er en diagnoseillustration af arbejdsgangen – ikke en måling af hostious.io.
Rul tilbage først, diagnosticér bagefter. PHP-versionen skiftes pr. site i hostingens kontrolpanel, og ændringen virker med det samme – vælg den version, sitet kørte på før, og bekræft at forsiden og wp-admin svarer igen. Så kan du undersøge fejlen i ro, mens sitet kører. Står du med en hvid skærm eller beskeden om en kritisk fejl, dækker hvid skærm-guiden og kritisk fejl-guiden de akutte trin.
| Loglinje starter med | Betydning | Hvor travlt har du? |
|---|---|---|
| PHP Deprecated | Koden bruger noget, der forsvinder i en senere PHP-version | Ingen hast – men en opgaveliste til plugin-opdateringer |
| PHP Warning / Notice | Noget er skævt, men koden kører videre | Undersøg ved lejlighed; hold øje med mønstre |
| PHP Fatal error | Koden stoppede – det er den, der vælter siden | Nu. Stien i linjen udpeger synderen |
Et site kan sagtens køre fejlfrit for besøgende, mens loggen får deprecated-linjer – det er normalt i månederne efter en ny PHP-udgivelse. Fatal errors er de eneste, der kræver handling med det samme.
Fejllinjen nævner altid en fil med fuld sti. Ligger filen under wp-content/plugins/navn/, er det pluginnet; under wp-content/themes/navn/, er det temaet. Typiske PHP 8-fejlmønstre: Call to undefined function create_function(), Unsupported operand types og fejl omkring valgfrie parametre før påkrævede. Du behøver ikke forstå dem – kun at aimé stien til det rigtige plugin og tjekke, om der findes en nyere version.
Loggen finder du som debug.log i wp-content (hvis WP_DEBUG_LOG er slået til) eller i kontrolpanelets PHP-fejllog. Fremgangsmåden til at slå logning til står i kritisk fejl-guiden.
Mønsteret er næsten altid det samme: plugins uden opdateringer i flere år, gamle temaer købt uden for de store markedspladser, hjemmelavede code snippets i functions.php og ældre premium-plugins, hvor licensen – og dermed opdateringerne – er udløbet. Find alternativet før opgraderingen, så skiftet ikke strander på ét dødt plugin. Er pluginnet forladt af udvikleren, er udskiftning den eneste holdbare vej – en lokal rettelse forsvinder ved næste opdatering.
Opgraderingen er i mål, når sitet kører på den nye version uden fatal errors i loggen i mindst et døgn, alle kritiske funktioner er testet, og deprecated-listen er omsat til konkrete plugin-opdateringer. Mål gerne TTFB før og efter – nyere PHP-versioner giver ofte målbart hurtigere svartider; TTFB-guiden viser hvordan. På Hostious skiftes PHP-version pr. site i kontrolpanelet, og supporten hjælper gerne med at læse loggen, hvis et plugin driller.
Den nyeste version, dine plugins og dit tema understøtter – for de fleste vedligeholdte sites er det PHP 8.3 eller 8.4. WordPress-kernen selv kører fint på 8.4; det er næsten altid tredjepartskode, der sætter grænsen.
Nej – de vælter intet i dag. De er varsler om, at koden holder op med at virke i en senere PHP-version. Behandl dem som en opgaveliste: opdater eller udskift de plugins, der producerer dem.
Selve skiftet tager sekunder i kontrolpanelet og kan rulles tilbage lige så hurtigt. Det egentlige arbejde er testen på staging – sæt en time af til et almindeligt site og mere til en webshop.
