Kort svar: PHP er programmeringssproget, WordPress er skrevet i. Det kører på serveren og bygger hver dynamisk side ved at hente indhold i databasen og samle HTML til browseren. Som site-ejer møder du især PHP ét sted: versionsvalget. Nyere versioner er hurtigere og får sikkerhedsrettelser, mens gamle bliver sikkerhedsrisici. Pr. oktober 2026 anbefaler WordPress PHP 8.3 eller nyere – kør 8.3 eller 8.4, og opgradér kontrolleret med test og en tilbagevej klar.
Fagligt gennemgået: 2. oktober 2026
PHP er motoren under næsten alle WordPress-sites, men de fleste site-ejere ser den kun som et tal i kontrolpanelet eller en fejlbesked på en dårlig dag. Her får du forklaret, hvad PHP gør, hvorfor versionen betyder noget for både fart og sikkerhed, hvilke indstillinger du kommer til at møde – og hvordan du opgraderer uden at tage sitet ned.
PHP’s rolle i WordPress
Når en besøgende åbner en side, der ikke ligger i cachen, starter serveren PHP: WordPress-kernen indlæses, tema og plugins kører deres kode, databasen spørges, og den færdige HTML sendes retur. Alt, dit site gør – fra menuer til WooCommerce-checkout – er PHP-kode i arbejde.
Det forklarer to hverdagsfænomener: hvorfor flere og tungere plugins gør sitet langsommere (mere kode pr. visning), og hvorfor en „hvid skærm“ typisk er en PHP-fejl – koden gik i stå, før siden blev færdig. Det forklarer også, hvorfor sidecache gør så stor en forskel: en side fra cachen kræver slet ikke PHP.
Versioner: fart og sikkerhed

Hver PHP-version lever i tre stadier: to års aktiv support (fejl og sikkerhed rettes), to års security-only (kun kritiske sikkerhedsrettelser) – og derefter end-of-life, hvor nye sårbarheder forbliver åbne. Samtidig er 8.x-generationen hurtigere end de 7.x-versioner, som en del ældre sites stadig kører på. Det gør versionsvalget til den sjældne optimering, der giver både fart og sikkerhed for prisen af en kontrolleret opgradering.
Status for de understøttede versioner ifølge php.net, pr. oktober 2026:
| Version | Aktiv support til | Sikkerhedsrettelser til | Status |
|---|---|---|---|
| PHP 7.4 og ældre | Udløbet | Udløbet | End-of-life – opgradér |
| PHP 8.0 og 8.1 | Udløbet | Udløbet | End-of-life – opgradér |
| PHP 8.2 | Udløbet | 31. december 2026 | Kun sikkerhed – planlæg opgradering nu |
| PHP 8.3 | Udløbet | 31. december 2027 | Kun sikkerhed – fornuftigt valg |
| PHP 8.4 | 31. december 2026 | 31. december 2028 | Aktiv support – fornuftigt valg |
| PHP 8.5 | 31. december 2027 | 31. december 2029 | Nyeste – tjek plugin-kompatibilitet først |
Den nyeste version er ikke automatisk det rigtige valg. Ældre plugins og temaer halter ofte efter, så 8.3 eller 8.4 er det sikre kompromis for de fleste WordPress-sites, mens 8.5 er værd at teste på staging først.
Sådan finder du din PHP-version
Den nemmeste vej er i WordPress: Værktøjer → Webstedets helbred → Info → Server. Her står den version, PHP faktisk kører med for dit site. Har du SSH-adgang, kan du også tjekke fra terminalen:
php -v
wp --info
Vær opmærksom på, at kommandolinjens PHP kan være en anden version end den, webserveren bruger til sitet. Er der tvivl, er tallet i Webstedets helbred det, der gælder.
Sådan opgraderer du PHP sikkert
Du skifter typisk PHP-version i hostingens kontrolpanel med få klik. Gør det med metode:
- Tag en backup, og opdatér WordPress, tema og plugins først – mange kompatibilitetsfejl er allerede rettet i nyere versioner.
- Tjek, at tema og nøgleplugins understøtter den nye version. Test gerne skiftet på en staging-kopi.
- Skift på et stille tidspunkt, og klik sitet igennem: forside, produktside, kurv, checkout, kontaktformular og wp-admin.
- Hold øje med fejlloggen det første døgn.
- Skift tilbage med det samme, hvis noget fejler – en nedgradering er lige så nem som en opgradering, så længe den gamle version stadig tilbydes.
Går noget alligevel skævt, viser guiden om fejl efter PHP-opgradering vejen fra fejlbesked til løsning. Kører du flere sites, er det en fordel, hvis versionen kan vælges pr. site, så ét gammelt site ikke holder de andre tilbage – spørg din udbyder, om det er muligt.
De fem PHP-indstillinger, du kommer til at møde

Ud over versionen støder de fleste site-ejere på fem indstillinger i kontrolpanelets PHP-sektion:
- memory_limit – hvor meget hukommelse ét script må bruge. 256M er et fornuftigt niveau for WordPress med WooCommerce, og fejlen „Allowed memory size exhausted“ betyder, at grænsen er nået.
- max_execution_time – hvor længe et script må køre, før det stoppes. PHP’s standard er 30 sekunder, og „Maximum execution time exceeded“ er dens fejl.
- upload_max_filesize og post_max_size – hvor store filer der kan uploades. post_max_size skal være mindst lige så stor som upload_max_filesize.
- display_errors – bør være slået fra på et live site, så fejlbeskeder med filstier ikke vises for besøgende. Fejlene skal i loggen (
log_errors), hvor du kan læse dem.
Under Værktøjer → Webstedets helbred → Info → Server viser WordPress de værdier, PHP faktisk kører med. Det er dem, der gælder – ikke dem, der står i en gammel php.ini fra en tidligere server.
OPcache og PHP-workers: det, der gør PHP hurtigt
PHP læser og oversætter i princippet koden forfra ved hver sidevisning. OPcache gemmer den oversatte kode i hukommelsen, så det kun sker én gang, og det giver en mærkbar forskel for sider, der ikke er cachet. OPcache bør være slået til, og den forklarer også, hvorfor en ændring i en PHP-fil nogle gange først kan ses efter et øjeblik.
PHP-workers (eller processer) er antallet af sidevisninger, serveren kan bygge samtidig. Har du fire workers, og der kommer fem besøgende i samme øjeblik til sider, der ikke er i cache, venter den femte – og ved for mange ventende får de en 503 eller 504. Det er den grænse, der oftest mærkes under en kampagne. Hvor mange du har brug for, afhænger af, hvor meget trafik der rammer PHP uden om cachen – en webshop med kurv, checkout og kundekonti har langt flere ucachede visninger end en brochure-side.
Sammen med en sidecache, der holder de fleste besøg helt væk fra PHP, er det dét, hosting reelt leverer på PHP-siden: en understøttet version, OPcache slået til og nok workers til den trafik, du faktisk har. Spørg din udbyder, hvor mange samtidige PHP-processer din plan giver, før en stor kampagne.
Når PHP fejler: fra hvid skærm til fejlbesked
En hvid skærm er en PHP-fejl, der ikke bliver vist. Slå loggen til midlertidigt i wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Genindlæs siden, og læs wp-content/debug.log. Linjen med „Fatal error“ nævner fil og linje, og filstien fortæller, hvilket plugin eller tema der fejlede. De hyppigste fejl efter et versionsskift er „Call to undefined function“ (en funktion, der er fjernet i den nye version) og „Uncaught TypeError“ (strengere typetjek i PHP 8). Løsningen er næsten altid en opdatering af det plugin, der nævnes – og hvis det ikke vedligeholdes længere, en erstatning. Slå debug fra igen bagefter. Se også guiden om kritisk fejl i WordPress.
Læs også
- Ordbog: Hosting-ordbogen
- Fejl efter PHP-opgradering: deprecated, fatal og hvid skærm
- Hvad er en MySQL-database?
- Hvad er LiteSpeed? Webserveren bag hurtig WordPress-hosting
- Hvad er WordPress?
- WordPress hosting hos Hostious – LiteSpeed, NVMe og staging fra WP StartUp
Ofte stillede spørgsmål om PHP
Skal jeg kunne programmere PHP for at bruge WordPress?
Nej. Du møder kun sproget som versionsvalget i kontrolpanelet og i sjældne fejlbeskeder. Kodearbejdet er gjort af WordPress-, tema- og plugin-udviklerne.
Hvor meget hurtigere er en ny PHP-version?
Det afhænger af udgangspunktet. Springet fra 7.4 til 8.x mærkes tydeligt på ucachede sider og i wp-admin, mens spring inden for 8.x er mindre. Gevinsten er størst der, hvor cachen ikke redder dig.
Hvorfor advarer mit site om en gammel PHP-version?
WordPress viser advarslen i Webstedets helbred, når versionen er ældre end anbefalet eller har passeret end-of-life. Pr. oktober 2026 anbefaler WordPress PHP 8.3 eller nyere. Tag advarslen alvorligt, men planlæg opgraderingen: test, skift, verificér.
Hvad er PHP-workers, og hvor mange har jeg brug for?
Det er antallet af sidevisninger, serveren kan bygge samtidig uden om cachen. Behovet afhænger af, hvor meget ucachet trafik du har: en lille brochure-side klarer sig med få, mens en webshop med kampagner har brug for flere. Rammes grænsen, ser besøgende 503- eller 504-fejl under spidsbelastning.
Hvordan finder jeg ud af, hvilket plugin der giver en hvid skærm?
Slå WP_DEBUG og WP_DEBUG_LOG til i wp-config.php, genindlæs siden, og læs wp-content/debug.log. Linjen med „Fatal error“ nævner filen – og filstien indeholder pluginnets navn.
Udgivet 31. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026
