Het WordPress witte scherm des doods, uitgelegd

Het witte scherm des doods is een kritieke PHP-fout die je niet kunt zien. WordPress liep halverwege het renderen tegen een onherstelbare fout aan, PHP stopte, en omdat het tonen van fouten op productieservers uitstaat, kwam de pagina leeg terug in plaats van de reden af te drukken. De oplossing is bijna nooit giswerk: zet de debug-log aan, open wp-content/debug.log en lees de laatste kritieke regel. Die noemt precies het bestand — vrijwel altijd een plugin of thema — en die ene regel is de hele reparatie.

Waarom het scherm leeg is

PHP heeft een instelling die display_errors heet. Op een ontwikkelmachine staat die meestal aan, dus drukt een kritieke fout een stack trace naar het scherm. Op een echte host staat die standaard uit, want het lekken van bestandspaden en fouten naar bezoekers is een beveiligingsprobleem. Dus als iets een kritieke fout veroorzaakt — een aanroep van een functie die niet meer bestaat, een class die niet geladen is, een syntaxfout in een plugin-update — dan sterft PHP en stuurt niets terug. Je browser rendert een leeg document. Dat is het “witte scherm”.

Sinds WordPress 5.2 is er een afhandelaar voor kritieke fouten (WP_Fatal_Error_Handler) die deze probeert op te vangen. Als dat werkt, krijg je geen lege pagina, maar de melding “Er heeft zich een kritieke fout op deze website voorgedaan”, plus een e-mail naar het beheerdersadres die vaak de daadwerkelijke fout bevat en een link naar de herstelmodus. Een echt leeg scherm betekent meestal dat de fout optrad voordat die afhandelaar kon draaien: een parse-/syntaxfout (opgevangen tijdens het compileren), een kapotte must-use plugin, of een kritieke fout in de functions.php van het actieve thema. Hoe dan ook, de oorzaak staat ergens opgeschreven. Je moet het schrijven alleen even aanzetten.

Los het op, in volgorde

1. Zet de log aan. Bewerk wp-config.php via SFTP en voeg dit toe boven de regel /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Met WP_DEBUG_DISPLAY op false blijven de fouten weg van de openbare pagina, terwijl WP_DEBUG_LOG ze naar wp-content/debug.log schrijft. Herlaad de kapotte pagina één keer om een verse regel te genereren.

2. Lees de laatste kritieke fout. Open wp-content/debug.log en kijk onderaan:

tail -n 30 wp-content/debug.log

Je zoekt naar een regel als deze:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

Het pad noemt de boosdoener: plugins/some-addon. Dat is je antwoord. Als de trace lang is of de melding cryptisch (Allowed memory size exhausted, Cannot redeclare, een classnaam die je niet herkent), plak hem dan in onze error log decoder — die filtert de ruis eruit, vertelt je naar welke plugin of welk thema het pad wijst, en legt uit wat het specifieke fouttype betekent.

3. Deactiveer de genoemde component. Je kunt niet bij /wp-admin, dus doe het via SFTP. Hernoem de map van de betreffende plugin, bijv. some-addon → some-addon.off. WordPress kan een map niet laden die het niet kan vinden, dus deactiveert het de plugin en komt de site terug. Als de log naar je thema wijst, schakel dan over op een standaardthema door de map van het actieve thema te hernoemen — WordPress valt terug op een meegeleverd twentytwentysomething.

4. Als de log niet wil schrijven, dan is wp-content niet beschrijfbaar, of zit de fout op serverniveau. Bekijk in dat geval de PHP-foutlog van de host:

find . -name "error_log" -newermt "-1 hour"

Dezelfde informatie, ander bestand. cPanel/Apache-stacks laten vaak een error_log achter in de rootmap van de site of in de map waar het misgaat.

Wat je niet moet doen

Verhoog niet zomaar de memory limit. Het meest herhaalde advies online is om WP_MEMORY_LIMIT op te schroeven naar 256M of 512M. Dat lost het witte scherm alleen op als de log daadwerkelijk Allowed memory size of N bytes exhausted zegt. Als de fout Call to undefined function is, doet meer geheugen niets — je hebt willekeurig een instelling gewijzigd en het scherm is nog steeds wit. Lees eerst de log en verhoog het geheugen pas als geheugen het aangegeven probleem is.

Wis niet je cache en noem dat een diagnose. Het witte scherm is PHP dat op de server sterft voordat er ook maar HTML bestaat. Een verouderd cachebestand kan geen leeg document veroorzaken. (Een kapotte cachingplugin wel — maar de log noemt die, en daar gaat het om.)

Bewerk of herinstalleer de WordPress-core niet. De kritieke fout zit bijna nooit in wp-includes of wp-admin; hij zit in de plugin of het thema waar de log naar wijst. De core herinstalleren is traag, riskant en behandelt een symptoom dat je nog niet hebt bevestigd.

Schakel niet alle plugins uit om ze blind één voor één weer aan te zetten. Bisecten werkt, maar het is de trage route. De log wijst je in één stap de exacte map aan. Grijp pas naar de “zet alles uit”-methode als er helemaal geen leesbare fout is.

Laat display_errors niet aanstaan in productie. Zodra de site weer werkt, verwijder je de debug-defines (of zet je WP_DEBUG terug op false). Fouten die naar bezoekers worden afgedrukt, onthullen je paden.

Nog steeds vast?

Als de log een plugin noemt maar het uitschakelen ervan het scherm niet wegneemt, zit er een tweede kritieke fout onder de eerste — zet de log weer aan en lees de nieuwe laatste regel; kritieke fouten stapelen op. Als de melding zelf de muur is, gooi hem dan in de error log decoder en laat die het fouttype en het bestandspad voor je vertalen. Het witte scherm blijft alleen een mysterie zolang de log uitstaat.