Kritisk fejl i WordPress: sådan finder du den konkrete PHP-fejl

Kort svar: En kritisk WordPress-fejl er normalt en fatal PHP-fejl, som stopper requesten. Start med Recovery Mode-mailen og serverens PHP-log; find fil, linje og tidspunkt, der matcher fejlen. Rul derefter den seneste relevante plugin-, tema- eller kodeændring tilbage. Aktivér kun debug-logning kortvarigt med visning slået fra. Et højere memory limit eller deaktivering af alt er ikke en diagnose.

Fagligt gennemgået: 2. oktober 2026

Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. Et kontrolleret kritisk PHP-scenarie er efterprøvet med Hostious Article Lab 1.4.1; plugin, fil og linjenummer i et virkeligt tilfælde skal komme fra den aktuelle log.

En kritisk fejl i WordPress viser sig som den samme korte besked hver gang: ”Der har været en kritisk fejl på dette websted” – eller på engelsk ”There has been a critical error on this website”. WordPress holder beskeden neutral for ikke at afsløre tekniske detaljer for besøgende. Den konkrete forklaring findes derfor i Recovery Mode-mailen eller i PHP-/WordPress-loggen – og det er den, denne guide hjælper dig med at finde.

Før du ændrer noget: Tag fil- og databasebackup. Gem fejlens URL og tidspunkt. Del aldrig en Recovery Mode-adgangsadresse offentligt; linket er en midlertidig sikkerhedsoplysning.

Bekræft om fejlen er global eller knyttet til én handling

Test forsiden, en almindelig underside, /wp-admin/ og den handling, der udløste fejlen. Notér også, hvad der skete umiddelbart før: opdatering, kodeændring, PHP-skift, import eller planlagt job.

Symptom	Sandsynlig retning	Første kontrol
Fejlen kom efter pluginopdatering	Fatal i plugin eller afhængighed	Recovery-mail/PHP-log
Kun én skabelon eller URL fejler	Tema, template eller dataafhængig kode	Fil/linje i loggen
Kun admin/import fejler	Memory, timeout eller adminhook	PHP-log for samme request
Fejlen opstår i cron/background job	Recovery Mode aktiveres muligvis ikke	Server-/cronlog
Siden er helt hvid uden besked	Output stoppet før handler eller skjult fatal	Hvid skærm-guiden

1. Brug Recovery Mode, hvis mailen er kommet

WordPress kan sende administratoren en mail med den berørte komponent og et særligt loginlink. I Recovery Mode pauses den fejlende komponent for din adminsession, så du kan undersøge sitet uden nødvendigvis at ændre oplevelsen for alle besøgende.

1. Kontrollér afsender og det præcise domæne i linket.
2. Log ind gennem Recovery Mode-linket.
3. Læs WordPress' besked om plugin eller tema.
4. Deaktivér eller rul kun den udpegede komponent tilbage.
5. Forlad Recovery Mode efter rettelsen og test i en normal session.

Hvis mailen ikke kommer, er det ikke bevis for, at der ingen fatal fejl er. Fejlen kan opstå før mailpluginet indlæses, i cron eller på en server, der ikke leverer mailen.

2. Find den første matchende fatal-loglinje

Brug hostingens PHP-log, hvis den er tilgængelig. Ellers kan WordPress logge midlertidigt:

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

Placér konstanterne før “stop editing”-linjen i wp-config.php. På live må errors ikke vises i HTML. Beskyt logfilen, gentag fejlen én gang, og slå logningen tilbage efter dataindsamlingen.

Læs fatallinjen som fire felter:

• fejltype, f.eks. undefined function eller type error;
• fil og linje;
• call stack/den handling, der førte dertil;
• timestamp.

Det er ikke nødvendigvis den øverste fil i stacken, der ejer fejlen. En pluginhook kan kalde core korrekt, men sende en forkert værdi. Gem derfor hele den relevante stack internt, mens et offentligt screenshot kun viser det nødvendige og anonymiserede udsnit.

Læs fejltypen før du vælger løsning

En Call to undefined function efter en opdatering peger ofte på manglende afhængighed, forkert load-rækkefølge eller en PHP-extension, som ikke findes i den aktuelle runtime. En TypeError peger på, at en funktion modtog en anden datatype end forventet. En Parse error eller syntax error betyder, at PHP slet ikke kunne læse filen, og den seneste manuelle kodeændring er derfor et naturligt første rollbackpunkt.

Allowed memory size exhausted er en særskilt fejlklasse. Filen i fatallinjen er stedet, hvor den sidste allokering fejlede, men ikke nødvendigvis den komponent, der brugte al hukommelsen. Brug memory-guidens målemetode i stedet for at beskylde den sidste corefil i stacken.

Notices, warnings og deprecated-meddelelser kan være relevante for kompatibilitet, men de er ikke automatisk årsagen til den kritiske fejl. Find den første fatal på samme request og samme tidspunkt. Ellers risikerer du at rette en gammel advarsel, mens den aktuelle fejl fortsætter.

3. Rul den seneste relevante ændring tilbage

Hvis filen tilhører en komponent, der netop blev opdateret:

1. dokumentér aktiv og tidligere version;
2. gendan den tidligere pakke fra en kendt backup eller leverandørkilde;
3. tøm kun den nødvendige opcode-/applikationscache;
4. gentag den fejlende request;
5. behold den nye version deaktiveret, indtil kompatibiliteten er afklaret.

Hvis du selv ændrede kode, gendan den konkrete fil eller commit. Ret ikke direkte i det aktive temas functions.php uden en sikker rollbackkanal; en syntaksfejl kan fjerne både frontend og admin.

4. Hvis du ikke kan åbne wp-admin

Brug filmanager/SSH til at omdøbe kun mappen for den komponent, loggen udpeger, f.eks. fra plugin-navn til plugin-navn.hold. Det får WordPress til at registrere pluginet som utilgængeligt. Omdøb tilbage efter testen, og aktivér kun når den fejlende version er erstattet.

Hvis loggen ikke udpeger en komponent, må bred pluginisolering ske på staging. At omdøbe hele plugins-mappen på live kan slå cache, sikkerhed, formularer og handel fra samtidig og skabe et større problem end den oprindelige fejl.

Et tema skiftes ligeledes først på staging eller via en kontrolleret database/WP-CLI-procedure med backup. Et default-tema skal være installeret, før du forventer fallback.

5. Kontrollér PHP-kompatibilitet og memory ud fra beviset

Hvis loggen viser en manglende/ændret funktion, typefejl eller deprecated-adfærd efter et PHP-skift, sammenlign komponentens kompatibilitet og rul PHP eller komponent tilbage i et kontrolleret vindue.

Hvis loggen siger Allowed memory size ... exhausted, brug memory-guiden. Hæv ikke memory på grund af den generiske kritiske fejlbesked. Den samme besked kan dække mange andre fatals.

6. Kontrollér WordPress core, når loggen peger ind i core

En stack, der slutter i wp-includes, beviser ikke automatisk en core-fejl. Plugin- eller temakode kalder ofte core. Kontrollér først stackens første tredjepartsfil.

Hvis checksums eller deploylog viser ændrede/manglende corefiler, så geninstaller samme WordPress-version fra en betroet pakke eller brug en kontrolleret core-checksum/repair-procedure. Bevar wp-content og wp-config.php; overskriv ikke hele installationen ukritisk.

De syv årsager, loggen oftest peger på

Når du har fundet fatallinjen, fortæller fejltypen og filstien tilsammen, hvad der er sket – og hvad det første skridt er. Tabellen samler de syv mønstre, der står bag langt de fleste kritiske fejl på danske WordPress-sider.

Årsag	Sådan ser loglinjen typisk ud	Første skridt
Plugin opdateret, men kræver nyere PHP eller et andet plugin	Call to undefined function eller Class ... not found i /wp-content/plugins/	Rul det ene plugin tilbage til den forrige version
PHP-version hævet på serveren	Uncaught TypeError eller Deprecated efterfulgt af en fatal i et ældre plugin	Sæt PHP-versionen tilbage i kontrolpanelet, og opdatér pluginet på staging
Egen kodeændring i temaet	Parse error: syntax error i functions.php	Gendan filen fra backup eller fra din seneste fungerende kopi
Hukommelsen brugt op	Allowed memory size of ... bytes exhausted	Følg memory-guiden – hæv ikke grænsen i blinde
Tema eller plugin slettet, men stadig aktivt	Failed opening required eller No such file or directory	Geninstallér komponenten, eller deaktivér den via databasen eller WP-CLI
Databasen svarer ikke	Error establishing a database connection før fatallen	Databasen først – se guiden til fejl ved oprettelse af databaseforbindelse wordpress
Core-filer ændret eller beskadiget	Fatal i /wp-includes/ eller /wp-admin/ uden tredjepartsfil i stacken	Kør checksum-kontrollen herunder, og geninstallér samme version

Har du adgang til WP-CLI, afgør tre kommandoer på under et minut, om fejlen ligger i WordPress selv, og hvilke versioner udvikleren skal have at vide:

wp core verify-checksums
wp core version
wp eval 'echo PHP_VERSION, PHP_EOL;'

Kør kommandoerne fra WordPress-roden. På delt hosting uden SSH kan supporten køre dem for dig – bed om output fra alle tre, så har du det, udvikleren spørger om først.

Mikroeksempel: Fejlen findes kun ved formularafsendelse

Forsiden og administrationen virker, men indsendelse af en formular giver den kritiske fejl. Loggen viser en TypeError i et integrationsplugin, når en valgfri telefonværdi er tom. Det er ikke et globalt WordPress-nedbrud og heller ikke et memoryproblem; én bestemt inputgren udløser fejlen.

På staging oprettes to testcases: en formular med telefon og en uden. Hvis kun den tomme værdi fejler, har du både positiv og negativ kontrol. Rul den seneste pluginversion tilbage eller ret valideringen i en testbar kodeændring, og gentag begge cases. En rettelse, der kun får den tomme formular til at passere, men bryder den udfyldte, er ikke færdig.

Samme princip gælder planlagte jobs. Hvis fatallen kun opstår i cron, skal verifikationen køre det samme ufarlige testjob. Et besøg på forsiden indlæser ikke nødvendigvis det hook eller de data, der fejlede.

Når flere fatals står i samme minut

En enkelt brugerhandling kan skabe en kæde: det oprindelige POST-kald fejler, en error-handler forsøger at sende mail, og et efterfølgende health-check fejler også. Sortér efter mikrosekund eller request-id, hvis platformen tilbyder det, og find den første årsag i kæden.

Lav en lille korrelationstabel med request, tidspunkt, HTTP-status, første fatal og følgefejl. Ret den første fatal og gentag requesten. Hvis følgefejlene forsvinder uden egne ændringer, var de sekundære. Hvis de bliver, behandles de som en separat sag. Denne rækkefølge forhindrer brede ændringer i tre komponenter på grund af én defekt inputsti.

Undgå at gøre debug til en ny driftsfejl

WP_DEBUG_DISPLAY skal være slået fra på offentlige miljøer, så filstier, SQL-udsnit eller persondata ikke havner i HTML og REST-svar. En debuglog kan vokse hurtigt ved gentagne warnings; kontroller ledig diskplads og begræns testvinduet.

Når materialet er indsamlet, sættes konstanterne tilbage til den dokumenterede starttilstand. Flyt eller beskyt logfilen efter platformens procedure, og gem kun det redigerede udsnit, der er nødvendigt til sagen.

Verificér at fejlen er løst

• Gentag den samme URL/handling mindst tre gange.
• Test anonymt og som relevant adminrolle.
• Bekræft forventet HTTP-status og komplet body.
• Kontroller at ingen ny fatal opstår i loggen.
• Kør den handling, som oprindeligt udløste fejlen: gemning, cron, import eller formular.
• Afslut Recovery Mode og test igen.

En fungerende forside er ikke nok, hvis fatallen kun opstod i en baggrundsopgave.

Rollback

Gendan den noterede plugin-/temaversion, fil eller PHP-indstilling. Sæt debugkonstanterne tilbage, fjern/beskyt debugloggen og reaktivér ikke en kendt fejlende komponent. Hvis rollback ikke genetablerer den tidligere tilstand, stop og gendan den afgrænsede backup frem for at kombinere flere ændringer.

Hvornår skal hosting eller udvikler hjælpe?

Hosting skal hjælpe ved PHP-FPM-crash, manglende extensions, serverstyret PHP-version, diskfejl eller utilgængelige logs. Udvikleren skal have fatal type, fil/linje, stack, versioner og den mindste reproducerbare handling. Hostious WordPress-support kan samle og anonymisere materialet – og med WordPress hosting fra WP StartUp til 89 kr./md. ekskl. moms er en WordPress serviceaftale med, så opdateringer testes på en kopi, før de rulles ud, og en fejlende opdatering rulles tilbage uden ekstra regning.

Vil du hellere slippe for at læse loggen selv? Hos Hostious svarer dansk support døgnet rundt og kan se PHP-loggen på din side med det samme. Fra WP StartUp til 89 kr./md. ekskl. moms er serviceaftalen med: WordPress, tema og plugins opdateres og testes på en kopi først, så en kritisk fejl efter en opdatering ikke når dine besøgende. Ligger siden et andet sted i dag, flytter vi den gratis – se skift hosting.

Sådan dokumenterer du den kritiske fejl

Gem kun de udsnit, der forbinder den synlige fejl med den ansvarlige komponent:

1. Kontrolleret kritisk fejl på testsite uden domæne-/kundedata.
2. Recovery Mode-mail med link og persondata dækket; komponentnavn og fejltype synlige.
3. Recovery Mode-dashboard med den udpegede komponent.
4. Anonymiseret fatal-loglinje før og fravær af ny fatal efter samme request.

Notér timestamp, fatal type, fil og linje samt HTTP-status for samme request. Ingen tokens, absolutte kundestier eller e-mailadresser må indgå i delt materiale.

Læs også

• Hub: WordPress fejl og fejlfinding
• Hvid skærm i WordPress
• Allowed memory size exhausted
• Plugin- eller temakonflikt
• 502 Bad Gateway
• WordPress hosting hos Hostious – hosting hvor supporten kender WordPress
• WP-CLI for begyndere – 10 opgaver, du aldrig mere gør i hånden

Ofte stillede spørgsmål om kritiske fejl

Hvad betyder ”Der har været en kritisk fejl på dette websted”?

WordPress viser beskeden, når PHP stopper med en fatal fejl. Den konkrete årsag står i error loggen eller i mailen fra Recovery Mode – find fil og linje, før du ændrer noget.

Hvor finder jeg den konkrete PHP-fejl?

Åbn error loggen via dit kontrolpanel, eller brug linket i Recovery Mode-mailen. Linjen med ”in /wp-content/…” peger på det plugin eller tema, der udløser fejlen.

Kan jeg bruge WP_DEBUG til at finde fejlen?

Ja, midlertidigt. Sæt WP_DEBUG og WP_DEBUG_LOG til true i wp-config.php, genindlæs siden, og slå det fra igen bagefter. Brug loggen frem for at vise fejl direkte på siden.

Hvorfor kommer der ingen mail fra Recovery Mode?

Fordi fejlen opstår, før WordPress når at sende mailen, fordi serveren ikke kan sende mail, eller fordi fejlen kun rammer et baggrundsjob. Manglende mail er derfor ikke et bevis for, at der ingen fatal fejl er. Gå direkte til PHP-loggen i kontrolpanelet – fatallinjen står der uanset mail.

Kan en kritisk fejl skyldes hostingen?

Ja, i få tilfælde: en PHP-opgradering, serveren har gennemført, en manglende PHP-extension, en fuld disk eller en database, der ikke svarer. Loggen afslører det: står der Deprecated eller TypeError lige efter et versionsskift, eller No space left on device, er det serveren, der skal rettes først – ikke pluginet.

Hvem hjælper, når WordPress viser en kritisk fejl?

Din hostingudbyder kan læse PHP-loggen og rulle PHP-versionen tilbage; en udvikler retter selve koden. Hos Hostious er dansk support med døgnet rundt i alle WordPress-planer fra 39 kr./md. ekskl. moms, og med serviceaftalen fra WP StartUp finder vi det plugin, der fejler, og ruller det tilbage – som en del af aftalen.