Er heeft zich een kritieke fout voorgedaan op deze website: wat het betekent en hoe je het oplost

Die melding betekent dat PHP tegen een kritieke fout aanliep tijdens het opbouwen van je pagina, en dat WordPress hem opving voordat het een leeg wit scherm werd. De fout is echt, specifiek en vastgelegd — WordPress weigert hem alleen in de browser te tonen, want een stack trace op een openbare pagina lekt bestandspaden en code naar iedere bezoeker.

De oplossing is dus nooit gokwerk. Hij is: lees de echte fout en handel naar wat er staat.

Wat er werkelijk gebeurt

Sinds WordPress 5.2 zit er een afhandelaar voor kritieke fouten in de core. Als PHP halverwege een request sterft, springt die afhandelaar bij, vervangt de crashuitvoer door dat beleefde algemene zinnetje en probeert — als hij kan achterhalen welke plugin of welk thema de dader is — de sitebeheerder te mailen met een link naar de herstelmodus.

Daarom zie je dit in plaats van het oude witte scherm des doods. Een verbetering, maar het betekent ook dat de diagnostische informatie standaard verborgen blijft. Er bestaan twee varianten van de melding:

Wat je ziet	Waar	Wat het je vertelt
”Er heeft zich een kritieke fout voorgedaan op deze website.”	Voorkant, uitgelogd	Er trad een kritieke fout op, verder geen details zichtbaar
Dezelfde regel plus “Meer informatie over het oplossen van problemen in WordPress”	Voorkant of wp-admin	Dezelfde fout, WordPress verwijst je naar het handboek
”…Controleer de inbox van het beheerdersadres voor instructies.”	Voorkant	De afhandelaar dacht een herstelmail te hebben verstuurd

Die derde variant is de nuttige. Hij betekent dat WordPress de crash aan een specifieke plugin of een specifiek thema heeft toegeschreven en je een ingang probeerde te geven.

Stap 1: controleer de herstelmail

WordPress stuurt de herstellink naar het e-mailadres van de sitebeheerder — het adres onder Instellingen, Algemeen — en dat is vaak niet het adres waarmee je inlogt. Kijk in die inbox, en kijk in de spam.

De e-mail bevat een lange link die eindigt op zoiets als ?action=enter_recovery_mode. Als je die opent, log je in wp-admin in de herstelmodus in. Daar is de veroorzakende plugin of het thema gepauzeerd en gemarkeerd in een rode melding bovenaan. Vanaf daar kun je hem gewoon deactiveren.

Twee eerlijke kanttekeningen. Ten eerste wordt de e-mail gegenereerd door hetzelfde PHP-proces dat net is gecrasht, op een host die misschien helemaal geen werkende maildienst heeft — niet-bezorging komt vaak voor, en het uitblijven ervan zegt niets over de fout. Ten tweede verloopt de herstellink (standaard na ongeveer een dag), dus een oude e-mail in je inbox kan simpelweg niet meer werken; forceer een nieuwe crash door de site opnieuw te laden en wacht op een verse mail.

Wil je dat de e-mail ergens aankomt waar je hem daadwerkelijk leest, zet het adres dan expliciet in wp-config.php:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Stap 2: lees de echte fout

Dit is de stap die van een kapotte site een klusje van vijf minuten maakt. Voeg deze regels toe aan wp-config.php, boven de regel die zegt dat je moet stoppen met bewerken:

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

Dat WP_DEBUG_DISPLAY op false staat, is belangrijk — het houdt de fout uit de browser terwijl hij wel naar schijf wordt geschreven, zodat je tijdens het debuggen geen paden aan bezoekers laat zien.

Laad de kapotte pagina één keer opnieuw en open daarna wp-content/debug.log. De laatste regel ziet er ongeveer zo uit:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Het bestandspad is het antwoord. Wijst het naar wp-content/plugins/, dan is die plugin de oorzaak. Wijst het naar wp-content/themes/, dan is het het thema — heel vaak iets dat kort daarvoor in functions.php is geplakt.

Verschijnt debug.log niet, dan is de map misschien niet beschrijfbaar, of heeft een beveiligingsplugin het loggen ergens anders naartoe verplaatst. Val dan terug op de PHP-foutlog van je host — de meeste bedieningspanelen hebben een sectie “Foutlog” of “Logs”, en dezelfde kritieke fout staat daar met een tijdstempel.

Plak de regel in de WordPress error log decoder om de PHP-formulering te vertalen naar wat het in de praktijk betekent en naar welk bestand je als eerste moet kijken.

Verwijder deze debugregels als je klaar bent. WP_DEBUG aanlaten op een productiesite vult je schijf, en als WP_DEBUG_DISPLAY ooit weer omgaat, worden serverpaden publiekelijk afgedrukt.

Stap 3: kom weer in wp-admin

Is wp-admin ook onbereikbaar en kwam er geen herstelmail, schakel dan alle plugins uit op bestandsniveau. Maak verbinding via SFTP (of de bestandsbeheerder van je host) en hernoem één map:

mv wp-content/plugins wp-content/plugins-off

WordPress kan de plugins niet vinden, deactiveert ze dus allemaal, en vrijwel altijd komt de beheerderstoegang terug. Vervolgens:

1. Hernoem de map terug naar plugins. Alles blijft gedeactiveerd — WordPress heeft ze als inactief geregistreerd.
2. Activeer de plugins één voor één en laad na elke activering de voorkant.
3. Degene die de fout terugbrengt, is je boosdoener.

Is de site nog steeds kapot met alle plugins uit, dan is het thema de verdachte. Hernoem de map van het actieve thema in wp-content/themes/; WordPress valt dan terug op een standaardthema als dat geïnstalleerd is.

De drie oorzaken die je moet kennen

Een plugin- of thema-update die een kritieke fout geeft. Veruit de meest voorkomende. De log noemt het bestand rechtstreeks. Zet die ene plugin terug naar de vorige versie, of laat hem gedeactiveerd en stuur de ontwikkelaar de logregel.

Een verkeerde PHP-versie. Hosts upgraden PHP volgens een schema, soms zonder veel waarschuwing vooraf. Code die voor oudere PHP is geschreven, kan op een nieuwere versie helemaal niet meer geparseerd worden. Het signaal is dat jij niets veranderd hebt en toch alles tegelijk stukging. PHP één kleine versie terugzetten in je hostingpaneel is een geldige diagnose — maar zie het als tijd kopen, niet als oplossing. Oude PHP-versies krijgen geen beveiligingsupdates meer.

Uitgeput geheugen. De log zegt “Allowed memory size of X bytes exhausted”. De limiet verhogen in wp-config.php is dan redelijk:

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

Wees eerlijk over wat dat doet: het haalt het plafond weg, maar lost niet op wat 256MB opslokte om één pagina te renderen. Moet de limiet steeds omhoog, dan is er iets anders aan de hand — meestal een import, een paginabouwer of een slecht geschreven query.

Advies dat je gerust kunt negeren

“Verhoog gewoon de geheugenlimiet.” Alleen relevant als de log daadwerkelijk zegt dat het geheugen op is. Anders verandert het niets en verhult het dat je de fout nooit gelezen hebt.

“Installeer de WordPress-core opnieuw.” Corebestanden zijn zelden de oorzaak, en ze vervangen kost tijd die je aan het lezen van één logregel had kunnen besteden.

“Zet de afhandelaar voor kritieke fouten uit.” Er bestaat een constante om hem uit te schakelen, en het resultaat is dat de rauwe fout op je openbare site wordt afgedrukt in plaats van opgevangen. Daarmee toon je bestandspaden aan bezoekers. Gebruik in plaats daarvan WP_DEBUG_LOG met WP_DEBUG_DISPLAY uit — dezelfde informatie, zonder de blootstelling.

“Leeg je cache.” Een kritieke fout treedt op in PHP voordat een cacheplugin ook maar iets kan uitleveren. Wordt er een gecachete kopie van de foutpagina getoond, dan helpt legen nadat je de oorzaak hebt verholpen — nooit in plaats daarvan.

Kom je er niet uit?

Wijst de log naar een corebestand in plaats van naar iets in wp-content, dan is de waarschijnlijkere verklaring dat een eerder geladen plugin de toestand heeft gesloopt waar de core op vertrouwt, en niet dat de core beschadigd is. Zet alles uit met de mapnaamtruc, controleer of de site schoon laadt en voeg de plugins daarna één voor één weer toe — de laatste die je inschakelt voordat de fout terugkomt, is degene die je moet melden, met de logregel erbij.