Hvid skærm i WordPress: plugin, tema, PHP eller hukommelse

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: 2. oktober 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.

1. Mål status og body

Å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.

Brug en enkel beslutningsgren

Start med dokumentrequesten – ikke med Console:

1. 5xx: match requestens tidspunkt med PHP-FPM-, PHP- og webserverlog. En fatal eller workerfejl har førsteprioritet.
2. 200 og 0/næsten 0 bytes: se efter tidlig exit, output buffering, en tom template eller en fatal, som serveren skjuler.
3. 200 med normal HTML-størrelse: inspicér DOM og computed styles. Her er serverrenderingen sandsynligvis gennemført.
4. Kun én rolle eller loginstatus: sammenlign cachevariant, capability-betinget hook og adminbar-/sessionkode.
5. Kun én URL: sammenlign template, blokdata og requestparametre med en fungerende URL af samme type.

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.

2. Kontrollér Recovery Mode og PHP-log

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.

3. Rul den seneste ændring tilbage

Hvid skærm lige efter en ændring løses mest sikkert ved at vende den ene ændring:

• gendan den seneste kodefil;
• rul plugin-/temaversion tilbage;
• ret en syntaksfejl via filmanager;
• sæt PHP-version tilbage i et kontrolleret vindue;
• afbryd den import eller batch, der udløser fatallen.

Test samme URL efter rollback. Hvis siden vender tilbage, beholder du den fejlende ændring ude og reproducerer på staging.

4. Isolér plugin uden adgang til wp-admin

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.

5. Test tema og template

Hvis kun frontend eller bestemte posttyper er ramt, er tema/template mere sandsynlig. På staging:

1. bekræft aktivt parent/child-tema;
2. skift midlertidigt til et kompatibelt WordPress-standardtema;
3. test samme URL;
4. hvis problemet forsvinder, genaktivér originaltemaet og isolér template/hook;
5. sammenlign mod den senest fungerende version.

Skift ikke live til et standardtema uden at vide, hvordan header, formularer, checkout og specialposttyper reagerer.

6. Kontrollér memory kun ved en memory-fejl

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.

7. Hvis HTML findes, men siden stadig er hvid

Når Network viser 200 og View Source indeholder normalt indhold:

• slå JavaScript fra i en test eller se Console for runtimefejl;
• inspicér om en fullscreen-overlay dækker siden;
• kontrollér tekstfarve mod baggrund;
• se om hovedcontaineren har nul højde/opacity/display;
• bypass optimeret CSS/JS på staging.

Dette er et renderingproblem, ikke en PHP white screen. Bevar den afgrænsning i supportsagen.

Reproducer sikkert og bevis årsagen

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.

Test en tom 500 og en visuel hvid side forskelligt

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:

• 500-forløbet: 500-status, lille/tom offentlig body og matchende intern loghændelse;
• renderingsforløbet: 200-status, normal HTML/body-størrelse og en målbar CSS-/DOM-årsag;
• efter rettelse: forventet 2xx, synligt hovedindhold og ingen ny fatal ved samme handling.

Brug ikke en kunstig fejlroute på hovedsitet. Testen hører til på et lukket stagingmiljø, og alle midlertidige routes eller snippets skal fjernes bagefter.

Kontroller cache, PHP og baggrundsjob separat

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.

Før/efter-verifikation med faste signaler

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.

Verifikation

• Samme dokumentrequest returnerer forventet 2xx-status og ikke-tom body.
• Frontend og wp-admin testes separat.
• Den oprindelige handling gentages.
• Ingen ny matchende fatal opstår.
• En anden URL/posttype fungerer stadig.
• Anonym og indlogget visning er kontrolleret.

Rollback

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”.

Hvornår skal hosting eller udvikler hjælpe?

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.

Sådan dokumenterer du en hvid side

Skeln visuelt og teknisk mellem en tom respons og en side, der blot gengives hvid:

1. Hvid side + Network-status på testsite.
2. View Source med tom versus eksisterende body som to sammenlignelige crops.
3. Recovery/logudsnit med komponenten markeret.
4. Samme request efter rollback med normal response-størrelse.

Gem HTTP-status, body size og den matchende fatal-loglinje eller det dokumenterede fravær af HTML. Kundestier og persondata fjernes.

Ofte stillede spørgsmål om hvid skærm

Hvad betyder det, når WordPress bare viser en hvid side?

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.

Hvorfor er kun nogle sider hvide, mens resten virker?

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.

Hvordan kommer jeg ind i wp-admin, når alt er hvidt?

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.

Læs også

• Hub: WordPress fejl og fejlfinding
• Kritisk fejl i WordPress
• Allowed memory size exhausted
• Plugin- eller temakonflikt
• Databaseforbindelsesfejl
• WordPress hosting hos Hostious – hosting hvor supporten kender WordPress