We kunnen bijna niks ergers bedenken dan het White Screen of Death (WSoD) tegenkomen terwijl je op je WordPress website zit te browsen. Deze fout haalt je website volledig uit de lucht – voor zowel admins als bezoekers.

Het WSoD kan erg frustrerend zijn, vooral omdat het lastig is informatie te vinden over de mogelijke oorzaak. Tegelijk is het wel een van de meest voorkomende WordPress fouten. Alhoewel het zeker vervelend is, is de fout in de meeste gevallen wel op te lossen.

In dit artikel leggen we uit wat het WordPress WSoD is en wat de meest voorkomende oorzaken zijn. Maar het belangrijkste gedeelte van dit artikel is natuurlijk dat we je negen potentiële oplossingen bieden waarmee je je website snel weer online kunt krijgen.

Laten we dus snel beginnen!

Wat is het WordPress White Screen of Death?

Zoals de naam doet vermoeden is het WordPress White Screen of Death (vaak afgekort tot “WSoD”) een volledig wit scherm dat je te zien krijgt in plaats van de webpagina die je probeerde te bezoeken.

Afhankelijk van de browser die je gebruikt, kun je verschillende foutmeldingen krijgen. Hieronder een voorbeeld uit Google Chrome, dat een HTTP 500 fout bevat met de tekst: “This page isn’t working and is unable to handle the request”:

Het WordPress White Screen of Death in Google Chrome
Het WordPress White Screen of Death in Google Chrome

En als we een White Screen of Death tegenkomen in Mozilla Firefox:

Het WordPress WSoD in Mozilla Firefox
Het WordPress WSoD in Mozilla Firefox

Zoals je kan zien, geeft de WordPress website daar alleen een volledig wit scherm en geen enkele nuttige foutcode of waarschuwing.

Het WordPress White Screen of Death wordt bijna altijd veroorzaakt door PHP fouten of doordat een geheugenlimiet is bereikt.

Een andere mogelijke oorzaak is een slecht thema of plugin. Dat laatste is vooral waarschijnlijk wanneer de front-end van je website niet werkt, maar je WordPress beheerdersgebied wel nog functioneert. Om snel te controleren of het dashboard van je website nog werkt, kun je naar jouwdomein.com/wp-admin gaan.

Hoe los je het WSoD op? Goed dat je het vraagt!

Zo repareer je het WordPress White Screen of Death (9 manieren)

Wanneer je het WordPress White Screen of Death tegenkomt, wil je dit natuurlijk zo snel mogelijk oplossen. Daarom gaan we meteen kijken naar negen mogelijke oplossingen die je kunt uitproberen.

1. Schakel je WordPress plugins uit

Een van de meeste eenvoudige manieren om het WordPress WSoD op te lossen is door simpelweg al je plugins uit te schakelen. Vaak gaat een site offline door een slechte update van een plugin.

Als je nog steeds bij je beheerdersgebied kunt, is deze oplossing eenvoudig uit te voeren door naar Plugins te gaan in je dashboard, alle plugins te selecteren, en op Deactiveren te klikken onder het Bulkacties dropdown-menu:

Alle WordPress plugins in één keer deactiveren
Alle WordPress plugins in één keer deactiveren

Hiermee schakel je al je plugins uit.

Als het probleem nu is opgelost, wil je natuurlijk de precieze boosdoener vinden. Dat doet je door nu alle plugins één voor één weer in te schakelen, en na elke activatie je website te laden. Zodra de front-end weer offline gaat, weet je welke plugin het probleem is.

Vervolgens kun je contact opnemen met de ontwikkelaar van de plugin of een supportticket aanmaken binnen de WordPress Plugin Directory.

Als je niet bij je dashboard kunt, gebruik dan een File Transfer Protocol (FTP) client om bij je bestanden te kunnen.

Onder de wp-content map binnen de hoofdmap van je site, zoek je de map plugins. Geef deze een nieuw naam, bijvoorbeeld “plugins_oud”.

Je plugins map een andere naam geven
Je plugins map een andere naam geven

Controleer vervolgens de front-end van je website. Als dit werkt, moet je ook alle plugins één voor één activeren. Zet de naam van je plugin map weer terug naar “plugins”, en geef nu één voor één elke pluginmap binnen de grote map een andere naam, totdat je het probleem gevonden hebt.

2. Switch naar een standaard WordPress thema

Wanneer het probleem niet door een plugin veroorzaakt wordt, kan je WordPress thema de oorzaak zijn van het witte scherm. Om dit te controleren, kun je je thema vervangen door een standaard thema.

Kun je nog bij je beheerdersschermen, ga dan binnen je dashboard naar Weergave > Thema’s. Vind en activeer een standaard WordPress thema, bijvoorbeeld Twenty Twenty:

Het Twenty Twenty WordPress thema
Het Twenty Twenty WordPress thema

Test vervolgens je website. Werkt je website nu wel, dan wordt het probleem dus veroorzaakt door je thema.

Kun je niet bij je dashboard, dan gebruik je hetzelfde trucje als met de plugins.

Gebruik FTP om bij de bestanden van je site te komen, en hernoem je wp-content/themes map tot iets anders:

Je themes map een andere naam geven
Je themes map een andere naam geven

WordPress zal vervolgens automatisch teruggaan naar het laatste standaardthema, waarschijnlijk Twenty Twenty. Als je geen andere thema’s hebt, kun je er eentje downloaden van de WordPress Theme Directory en uploaden naar je themes map.

Daarna kun je alsnog je website checken. Werkt alles, dan veroorzaakt je thema wellicht een conflict of had het een slechte update. Als dat het geval is moet je contact opnemen met de developer van het thema of een andere thema kiezen.

3. Leeg de cache van je browser en WordPress plugins

Als je toegang hebt tot de back-end van je WordPress website, maar nog altijd het WSoD ziet op de frond-end, kan dat komen door een probleem met je cache.

Om dit op te lossen, kun je de cache van je webbrowser legen. Daarnaast moet je zorgen dat je de cache leegt van je WordPress cachingplugin (als je die hebt).

Heb je inderdaad een cachingplugin geïnstalleerd op je WordPress website, bijvoorbeeld WP Rocket of WP Super Cache, dan bieden die vaak via de instellingen van de plugin een makkelijke manier om de cache te legen.

We gebruiken WP Super Cache even als voorbeeld. In je WordPress dashboard ga je naar Instellingen > WP Super Cache > Delete Cache:

De WP Super Cache plugin instellingen
De WP Super Cache plugin instellingen

Zo leeg je je cache in MyKinsta

Ben je een Kinsta gebruiker, dan is er een eenvoudige manier om je cache te legen via MyKinsta. Hiervoor log in je op je account. Klik op Tools, en vervolgens op Cache legen onder het deel Site Cache:

De optie Cache legen in MyKinsta
De optie Cache legen in MyKinsta

Nadat je de cache hebt geleegd, sla je alle wijzigingen op. Vervolgens bezoek je je website om te kijken of het probleem opgelost is. Zo niet, dan is het tijd voor de volgende poging:

4. Schakel de debuggingmodus in

Zie je nog altijd het WordPress White Screen of Death, kun je niet bij je beheerderssectie of denk je het probleem gevonden te hebben, maar wil je het zekere voor het onzekere nemen? Dan kun je de debuggingmodus inschakelen. Dit zal alle fouten op je website weergeven.

Om debugging in te schakelen, open je het wp-config.php bestand van je WordPress installatie. Daarin vind je de volgende regel code:

define( 'WP_DEBUG', false )

Verander “false” naar “true” en laad je website opnieuw. Als deze regel niet te vinden is in het bestand, kun je deze toevoegen bovenaan in het bestand.

In plaats van het witte scherm, krijg je nu een wit scherm en een aantal foutmeldingen. Dat is een goed begin. De WSoD foutmelding moet melden welk bestand het probleem veroorzaakt, bijvoorbeeld zo:

Cannot redeclare get_posts() (previously declared in 
/var/www/html/wordpress/wp-includes/post.php:1874) in 
/var/www/html/wordpress/wp-content/plugins/my-test-plugin/my-test-plugin.php on line 38

Je ziet aan het einde van dit bericht dat het probleem veroorzaakt wordt op regel 38 van een plugin die my-test-plugin heet. Je kan het probleem dus oplossen door die plugin te deactiveren.

Als je geen foutmeldingen ziet na het inschakelen van de debugmodus, kan je het beste contact opnemen met je webhost. Mogelijk is debugging niet goed geconfigureerd binnen je server.

Kinsta klanten hebben ook de mogelijkheid om de ingebouwde debuggingtool te gebruiken. Binnen het MyKinsta dashboard klik je daarvoor op de naam van de website, en vervolgens op Tools. Onder WordPress debugging selecteer je Inschakelen:

Inschakelen van WordPress debugging in MyKinsta
Inschakelen van WordPress debugging in MyKinsta

Daarna kun je de fout log vinden onder Logs in je MyKinsta dashboard om meer informatie over het probleem te krijgen.

Onthoud wel dat het inschakelen van debuggingmodus informatie over je website zichtbaar maakt, ook aan niet-goedgekeurde gebruikers. Zorg dus dat je het ook altijd weer uitschakelt zodra je klaar bent.

5. Verhoog je geheugenlimiet

Heb je de bovenstaande oplossing geprobeerd, maar zie je nog steeds die verschrikkelijke lege pagina, of krijg je meteen een foutmelding over geheugenlimieten, dan moet je meer geheugen toewijzen aan de applicatie.

Dit kan via het wp-config.php bestand binnen de meeste WordPress installaties. Open het bestand en voeg de volgende code toe:

define('WP_MEMORY_LIMIT', '64M');

Als dat niet lijkt te werken, zijn er nog een paar manieren om hetzelfde te bereiken. In een normale omgeving kun je je .htaccess bestand gebruiken om het geheugenlimiet te verhogen. Voeg gewoon de volgende regel toe aan het bestand:

php_value memory_limit 64M

Kun je niet bij je .htaccess bestand, dan kun je ook het php.ini bestand gebruiken om het geheugenlimiet te verhogen.

Dit kun je doen door via FTP verbinding te maken met je server. In de hoofdmap van je site zoek je het php.ini bestand op. Daarin voeg je ergens de volgende regel code toe:

memory_limit = 64M

Raakt je geheugen nog steeds op, dan is er waarschijnlijk een probleem met de applicatie zelf. Mogelijk gebruikt je thema of één van je plugins een extreme hoeveelheid geheugen.

Om dat op te lossen kun je wellicht het beste een developer inhuren en hem of haar vragen om ernaar te kijken. Ook je host kan je wellicht helpen, door je de SQL logs en andere statistieken voor je website te geven.

6. Controleer of er problemen zijn met bestandsrechten

Nog een andere mogelijke oorzaak van het WSoD zijn problemen met bestands- en eigendomsrechten. Het is mogelijk om dit zelf op te lossen, maar tenzij je echt goed weet wat je doet, zouden we je dit niet aanraden. Je kan namelijk per ongeluk kwetsbaarheden creëren waar aanvallers misbruik van kunnen maken.

Waar het gaat om rechten binnen WordPress, zijn er drie eenvoudige regels die je moet volgen:

  • Bestanden moeten altijd ingesteld staan op 664 of 644.
  • Mappen moeten ingesteld staan op 775 of 755.
  • Het wp-config.php bestand moet ingesteld zijn op 660, 600 of 644.

Als je SSH toegang tot je server hebt, dan kun je de juiste regels toepassen via de volgende opdracht, die je uitvoert vanaf de hoofdmap van je WordPress installatie:

sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
sudo chmod 660 wp-config.php

Weet je niet precies hoe je dit moet doen of ben je bang fouten te maken, vraag dan vooral even je webhost om hulp.

7. Controleer of er gefaalde auto-updates zijn

Soms gaat er iets fout wanneer WordPress een update uit wil voeren, maar dit niet lukt, bijvoorbeeld wanneer er een server time-out plaatsvindt terwijl een update wordt uitgevoerd. Meestal lost dit probleem zichzelf wel weer op, maar in sommige gevallen kan het leiden tot het WordPress White Screen of Death.

Het eerst wat je moet doen is naar je WordPress hoofdmap gaan en kijken of daar een .maintenance bestand staat (wellicht is de naam afgekort).

Probeer dat bestand te verwijderen en je website opnieuw te laden.

Als de update was gelukt, maar het probleem werd veroorzaakt doordat WordPress het .maintenance bestand niet kon verwijderen, dan zou alles nu weer normaal moeten zijn.

Was de update niet gelukt, dan wordt die nu automatisch herstart. Dit zou het probleem dus ook op moeten lossen.

Mocht het allemaal niet lukken, kijk dan even hier hoe je WordPress handmatig updatet om het probleem op deze manier op te lossen.

8. Los syntax-fouten op of gebruik een herstelpunt

Nog een veel voorkomende oorzaak voor het WordPress WSoD is wanneer je de code van je WordPress website bewerkt en per ongeluk een typefout maakt of de verkeerde syntax gebruikt.

Eén teken op de verkeerde plek kan in principe je hele website laten crashen, wat precies de reden is dat je nooit de code van je live website moet bewerken.

Maar maak je geen zorgen. Je kunt altijd via FTP verbinding maken met je website en de wijziging handmatig terugdraaien. Weet je niet precies welke verandering het probleem veroorzaakt hebben, dan is dit het moment dat je blij bent dat je netjes je WordPress back-ups maakt.

Hier bij Kinsta kun met een enkele klik je je website herstellen. Dit doe je via het MyKinsta dashboard, onder Back-ups:

De backup feature in MyKinsta
De back-up feature in MyKinsta

Vergeet niet dat als je eerder de debuggingmodus in WordPress had ingeschakeld, er nu een foutmelding kan optreden met een parse syntax fout. Als je dat ziet, wordt erbij vermeld waar de oorzaak zit.

9. Vergroot de PHP capaciteit om tekst te verwerken

Mocht je WSoD nog altijd niet opgelost zijn, dan is er nog een ding wat je kan proberen. Heel soms kan het witte scherm veroorzaakt worden doordat een pagina of artikel extreem lang is.

Mocht dat het geval zijn, dan kun je de PHP capaciteit voor het verwerken van tekst vergroten door de backtrack en recursion limieten te verhogen. Dat doe je door de volgende code in je wp-config.php bestand te plakken:

/* Trick for long posts /
ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

Na het toevoegen, sla je het bestand op. Vervolgens laad je je website opnieuw en hopelijk werkt het dan allemaal weer.

Samenvatting

Het WordPress White Screen of Death kan voor heel wat frustratie zorgen en menig website-eigenaar angst inboezemen. Er zijn verschillende dingen die het kunnen veroorzaken, maar gelukkig is de situatie meestal niet zo erg als dat het lijkt.

Een eenvoudige plugin- en themacheck lost het WSoD probleem meestal op. Ook de inzichten uit de WordPress debuggingmodus kunnen helpen om een idee van het probleem te krijgen en makkelijker tot een oplossing te komen.

Heb je nog andere gevallen van het WordPress White Screen of Death gezien? Laat het ons dan weten zodat we ervan kunnen leren!

Daniel Pataki

Hi, my name is Daniel, I'm the CTO here at Kinsta. You may know me from Smashing Magazine, WPMU Dev, Tuts+ and other WordPress/Development magazines. Aside from WordPress and PHP I spend most of my time around Node, React, GraphQL and other technologies in the Javascript space.

When not working on making the best hosting solution in the Universe I collect board games, play table football in the office, travel or play guitar and sing in a pretty bad band.