Kort svar: En hvid WordPress-side kan være en skjult fatal PHP-fejl, en tom 200-response eller output, der stopper i tema/plugin. Kontrollér først HTTP-status og response body i browserens Network-panel. Match derefter tidspunktet i PHP-loggen og brug Recovery Mode eller staging til at isolere den udpegede komponent. Slå aldrig offentlig fejlvisning til som permanent løsning, og omdøb ikke alle plugins på live uden backup.
Fagligt gennemgået: 28. august 2026
Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. En tom 500-respons og en synlig hvid frontend er kontrolleret som to forskellige scenarier; den konkrete årsag skal stadig bekræftes i sitets egen log og HTML-respons.
“Hvid skærm” beskriver udseendet, ikke fejlen. To sider kan se ens ud, mens den ene er en 500 med skjult fatal error og den anden er en 200-response uden indhold. Det første tekniske skel sparer mange gæt.
Før du ændrer noget: Gem URL og tidspunkt, tag backup, og kontrollér om frontend, admin eller begge er ramt. Hav en filmanager/SSH-rollback klar, før du ændrer aktivt tema eller plugin.
På denne side
Åbn Network, genindlæs den hvide side og vælg dokumentrequesten.
| Resultat | Betydning | Næste kontrol |
|---|---|---|
| 500/502/503 med tom/fejl-body | PHP, gateway eller server | PHP/webserverlog |
| 200 med helt tom body | Kode afslutter output eller template renderer intet | PHP-log + theme/plugin-isolation |
| 200 med HTML, men intet synligt | CSS/JS/overlay eller tom template | View Source + computed layout |
| Kun én URL er hvid | Template, shortcode, blok eller datatilstand | Sammenlign fungerende URL |
| Kun wp-admin er hvid | Adminhook, memory eller plugin | Adminrequest + log |
Brug også View Source. Hvis den indeholder fuld HTML, er problemet muligvis visuelt og ikke en klassisk white screen of death. Så skal du inspicere layout/CSS, ikke starte med database repair.
Start med dokumentrequesten – ikke med Console:
exit, output buffering, en tom template eller en fatal, som serveren skjuler.Gem både “Transferred” og faktisk response-body-størrelse fra Network. Komprimering kan gøre den overførte størrelse lille, selv om body indeholder HTML. En eftertest bør sammenligne samme felt før og efter.
Se administratorens mail efter Recovery Mode. Hvis den udpeger et plugin eller tema, følg den målrettede proces i guiden til kritisk fejl.
Hvis der ikke er en mail, brug hostingens PHP-log. Du kan kortvarigt aktivere WordPress debug-log med WP_DEBUG_DISPLAY sat til false, gentage fejlen én gang og derefter slå det tilbage. Offentlig fejlvisning kan afsløre stier, versionsoplysninger og data.
Match loggen på timestamp. Se efter fatal type, fil, linje og memorybesked. Gamle notices uden samme tidspunkt er ikke bevis.
Hvid skærm lige efter en ændring løses mest sikkert ved at vende den ene ændring:
Test samme URL efter rollback. Hvis siden vender tilbage, beholder du den fejlende ændring ude og reproducerer på staging.
Hvis loggen udpeger et plugin, omdøb kun dets mappe midlertidigt. Hvis intet er udpeget, kopier sitet til staging og brug Troubleshooting Mode eller binær aktivering.
At omdøbe hele wp-content/plugins på live kan deaktivere sikkerhed, cache, formularer og handelsfunktioner samtidig. Det bruges kun som nødfald med godkendt driftsvindue, backup og en testplan.
Den fulde metode findes i plugin- og temakonfliktguiden.
Hvis kun frontend eller bestemte posttyper er ramt, er tema/template mere sandsynlig. På staging:
Skift ikke live til et standardtema uden at vide, hvordan header, formularer, checkout og specialposttyper reagerer.
Hvis loggen indeholder Allowed memory size ... exhausted, gå til memory-guiden. Et højere loft kan være en kort test, men en uendelig loop, stor import eller defekt query vil bruge den ekstra hukommelse igen.
Hvis loggen ikke nævner memory, er det ikke fagligt forsvarligt at gøre “256M/512M” til standardløsningen.
Når Network viser 200 og View Source indeholder normalt indhold:
Dette er et renderingproblem, ikke en PHP white screen. Bevar den afgrænsning i supportsagen.
På staging bør du have tre faste kontrol-URL'er: den fejlende side, en anden side med samme template og en enkel side, som ikke bruger den mistænkte funktion. Brug samme browser, rolle og cachetilstand i hver runde.
| Runde | Aktiv kombination | Fejlende URL | Samme template | Enkel kontrolside | Log/request |
|---|---|---|---|---|---|
| Baseline | Kopi af produktion | Hvid | Notér resultat | Notér resultat | Gem T0 |
| Minimal test | Standardtema + nødvendige plugins | Test igen | Test igen | Skal stadig virke | Gem T1 |
| Kandidat tilbage | Minimal + mistænkt komponent | Fejl skal vende tilbage | Sammenlign | Kontrol må ikke bryde | Gem T2 |
| Rettelse | Fuld opsætning + valgt rettelse | Normal | Normal | Normal | Ingen ny matchende fejl |
Det er ikke nok, at siden virker efter en cachepurge eller et tilfældigt plugin-toggle. For at knytte årsagen til en komponent skal du kunne få fejlen til at forsvinde, genopstå og forsvinde igen med samme testtrin på staging. Hvis den ikke kan genfremkaldes, markér konklusionen som sandsynlig og undersøg timing, cache eller eksterne kald videre.
En kontrolleret 500-test på et lukket testsite kan bruges til at kontrollere, at fejlvisning er skjult for besøgende, mens den fulde fatal stadig lander i den interne log. En separat testside med normal HTML, men en bevidst skjult indholdscontainer, demonstrerer det visuelle tilfælde. De to testresultater bør vise:
Brug ikke en kunstig fejlroute på hovedsitet. Testen hører til på et lukket stagingmiljø, og alle midlertidige routes eller snippets skal fjernes bagefter.
Hvis kun anonyme besøgende ser den hvide side, men indloggede brugere ikke gør, så hent en frisk anonym response og sammenlign cacheheaders. Hvis både cached og bypassed origin-response er tomme, er cache ikke den primære årsag. Hvis origin er normal og kun en bestemt cachevariant er tom, purge den præcise variant efter at kildefejlen er rettet.
En cron-, REST- eller CLI-fatal kan samtidig sende mails eller stoppe jobs uden at gøre frontend hvid. Omvendt beviser en normal forside ikke, at admin- eller cronrequesten er sund. Gentag derfor den oprindelige requesttype; test ikke en adminfejl med kun et anonymt homepage-kald.
Registrér URL, rolle, status, body-størrelse, aktiv template, komponentversion og logtimestamp i samme tidszone. Efter rettelsen gentager du præcis samme request tre gange: frisk anonym, relevant indlogget rolle og cachebypass på staging. Først når alle giver det forventede resultat, rulles rettelsen ud i et kontrolleret vindue.
Gendan omdøbte mapper, aktivt tema, PHP-version, debugkonstanter og den ændrede fil til de noterede værdier. Hvis en komponent alene skaber fejlen, behold den deaktiveret og gendan dens kendt fungerende version – aktivér ikke blot for at “se om den går”.
Peger loggen på serveren frem for på tema eller plugin, er det ressourcer eller PHP-konfiguration. Det kan ikke rettes fra WordPress — se WordPress hosting med dedikerede ressourcer.
Hosting skal hjælpe ved tomme 5xx-responses uden tilgængelig log, PHP-FPM-crash eller serverstyret PHP. Udvikleren skal have URL, status, fatal stack og den komponentkombination, der reproducerer fejlen. Hostious WordPress-support kan hjælpe med den første afgrænsning.
Skeln visuelt og teknisk mellem en tom respons og en side, der blot gengives hvid:
Gem HTTP-status, body size og den matchende fatal-loglinje eller det dokumenterede fravær af HTML. Kundestier og persondata fjernes.
At PHP stoppede, før siden blev færdig – typisk en fatal fejl i plugin eller tema, eller opbrugt hukommelse. Fejlen står i PHP-loggen, selv om skærmen er tom.
Fordi fejlen ligger i kode, der kun kører på de sider – fx en bestemt skabelon, shortcode eller widget. Det mønster er værdifuldt: notér hvilke URL’er der fejler, før du tester videre.
Brug linket i Recovery Mode-mailen, eller omdøb det mistænkte plugins mappe via kontrolpanelets filhåndtering. Så starter WordPress uden det fejlende element, og du kan rydde op.