Fejl efter PHP-opgradering: deprecated, fatal og hvid skærm

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 fri for fatal errors. Deprecated-beskeder vælter intet – kun fatal errors gør.

Fagligt gennemgået: 2. oktober 2026

En nyere PHP-version er en af de billigste hastighedsforbedringer, et WordPress-site kan få – og en nødvendighed for sikkerheden, når den gamle version ikke længere får sikkerhedsrettelser. 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 – hvad du gør, hvis skaden allerede er sket, og hvordan du opgraderer sikkert næste gang.

Før du ændrer noget: Notér, hvilken PHP-version sitet kørte på før skiftet, og tag en backup, før du opdaterer plugins eller retter kode. Ret aldrig direkte i et plugins filer på et live site – rettelsen forsvinder ved næste opdatering, og en tastefejl kan vælte hele sitet.

1. Rul tilbage, hvis sitet er nede

Rul tilbage først, diagnosticér bagefter. PHP-versionen vælges i hostingens kontrolpanel, og ændringen virker typisk 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.

WordPress har desuden en indbygget genoprettelsestilstand: ved en fatal fejl sender WordPress en mail til administratoradressen med et særligt login-link. Via linket kan du logge ind og deaktivere det plugin eller tema, der fejler, selvom resten af sitet er nede. Mailen ser ud som beskrevet i guiden om mailen “Der er et teknisk problem med dit websted”.

2. Kend forskel på deprecated, warning og fatal

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. Vises advarsler direkte på siden, er det et tegn på, at fejlvisning er slået til på et live site – det skal slås fra, uanset PHP-version.

3. Find synderen i loggen

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; under wp-content/mu-plugins/ er det et must-use-plugin, som ikke kan slås fra i plugin-oversigten. Du behøver ikke forstå selve fejlen – kun følge stien til det rigtige plugin og tjekke, om der findes en nyere version.

Loggen finder du i kontrolpanelets PHP-fejllog eller som debug.log i wp-content, hvis WordPress’ egen logning er slået til. Den slår du til i wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Med WP_DEBUG_DISPLAY sat til false skrives fejlene kun i loggen og vises ikke for besøgende. Slå logningen fra igen, når du er færdig – en debug.log kan vokse sig stor. Mere om logning står i kritisk fejl-guiden.

Typiske fejlmønstre pr. PHP-version

Skift til	Typisk meddelelse	Hvad der er sket
PHP 8.0	Call to undefined function create_function() eller each()	Funktionerne er fjernet – gammel kode stopper (fatal)
PHP 8.0	Unsupported operand types	Strengere typekontrol ved regning med fx arrays og strenge (fatal)
PHP 8.0	Valgfri parameter før påkrævet	Funktionsdefinitionen er forældet (deprecated)
PHP 8.1	Passing null to parameter … is deprecated	Null sendt til indbyggede funktioner (deprecated)
PHP 8.2	Creation of dynamic property … is deprecated	Klasser opretter egenskaber, der ikke er erklæret (deprecated)
PHP 8.4	Implicitly marking parameter … as nullable is deprecated	Gammel skrivemåde for parametre, der må være null (deprecated)

Mønsteret er tydeligt: springet fra PHP 7.x til 8.x giver flest fatal errors, mens skift mellem 8.x-versioner oftere giver deprecated-linjer. Springer du flere versioner over på én gang, får du alle ændringerne samlet – endnu en grund til at teste på staging.

4. Opgradér i den sikre rækkefølge

1. Opdatér alt først: WordPress, plugins og temaer. Nyere versioner er klar til nyere PHP.
2. Klon til staging: en kopi af sitet, hvor fejl er gratis – se staging-guiden.
3. Skift PHP-version på staging, og klik de vigtigste sider og funktioner igennem: forside, kontaktformular, søgning, login – og for webshops hele købsflowet med en testbetaling.
4. Læs loggen: fatal errors skal væk før skiftet; deprecated-linjer noteres som opfølgning.
5. Skift live på et roligt tidspunkt, og hold øje med loggen den første time.

Har du terminaladgang, kan du lave en hurtig oversigt over plugins med ventende opdateringer, før du starter:

wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version

Udviklere kan desuden scanne koden statisk med PHP_CodeSniffer og regelsættet PHPCompatibilityWP, som markerer kode, der ikke passer til en bestemt PHP-version. En scanning finder ikke alt – den kører ikke koden – så den erstatter ikke testen på staging.

5. Kend de typiske syndere

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.

Tjek plugin-siden på wordpress.org: “Testet op til” og datoen for seneste opdatering siger meget om, hvor aktivt pluginnet vedligeholdes. Til premium-plugins skal du se på udviklerens changelog, om nyere PHP-versioner er nævnt.

6. Når fejlen ikke står i loggen

Nogle problemer efter et PHP-skift ser ikke ud som PHP-fejl:

• Manglende PHP-udvidelse: hver PHP-version har sit eget sæt udvidelser. Mangler fx intl, imagick eller sodium på den nye version, fejler kun de funktioner, der bruger dem. Webstedstilstand under Værktøjer viser manglende udvidelser.
• Egne PHP-indstillinger er nulstillet: værdier som memory_limit og max_execution_time kan være sat pr. version. Tjek, at de er de samme efter skiftet.
• Cache med gammel kode: ryd sitets cache efter skiftet, så du tester det, PHP faktisk leverer nu.
• WP-CLI og cron på en anden version: terminalen og serverens cron kan bruge en anden PHP-version end webserveren. Fejler planlagte opgaver efter skiftet, så tjek versionen dér med wp --info.

7. Verificér opgraderingen

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’ WordPress hosting er staging med fra WP StartUp, så du kan teste skiftet på en kopi, og den danske support hjælper gerne med at læse loggen, hvis et plugin driller.

Læs også

• Hub: WordPress fejl og fejlfinding
• Staging i WordPress
• Kritisk fejl i WordPress
• Mailen “Der er et teknisk problem med dit websted”
• Hvad er PHP?
• WordPress hosting hos Hostious – staging fra WP StartUp og dansk support døgnet rundt

Ofte stillede spørgsmål om PHP-opgradering

Hvilken PHP-version bør WordPress køre?

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.

Er deprecated-beskeder farlige?

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.

Hvor lang tid tager et PHP-skift?

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.

Kan jeg blive på en gammel PHP-version?

Teknisk set et stykke tid, men det er en sikkerhedsrisiko. Versioner uden sikkerhedsopdateringer får ikke rettet nye huller, og nyere plugins holder op med at understøtte dem. Brug tiden til at finde afløsere for de plugins, der holder dig tilbage.