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: 28. august 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.
WordPress viser den neutrale besked for ikke at afsløre tekniske detaljer for besøgende. Den konkrete forklaring findes derfor i Recovery Mode-mailen eller i PHP-/WordPress-loggen.
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.
På denne side
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 |
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.
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.
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:
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.
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.
Hvis filen tilhører en komponent, der netop blev opdateret:
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.
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.
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.
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.
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.
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.
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.
En fungerende forside er ikke nok, hvis fatallen kun opstod i en baggrundsopgave.
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.
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.
Gem kun de udsnit, der forbinder den synlige fejl med den ansvarlige komponent:
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.
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.
Å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.
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.