De debug-modus inschakelen (en weer uit)

Een website die het niet doet, vertelt zelden waarom. Een wit scherm. Een “critical error” zonder details. Een formulier dat niets doet. WordPress weet op dat moment precies wat er misging, tot op de regel code nauwkeurig, maar houdt dat standaard voor zich. Dat is verstandig voor bezoekers, en onhandig voor u.

De WordPress debug modus inschakelen betekent dat u WordPress vraagt die informatie wél op te schrijven. Niet op het scherm, maar in een logbestand dat alleen u leest. Daarmee wordt “de site doet het niet” opeens “regel 214 van plugin X vraagt om een functie die niet bestaat”. Dat verschil is het verschil tussen gokken en weten. In dit artikel zet u het aan, leest u het log en, minstens zo belangrijk, zet u het weer uit.

Wat de debug-modus doet en wat de risico’s zijn

WordPress heeft een handvol instellingen in het bestand wp-config.php die bepalen hoe met fouten wordt omgegaan. De drie die ertoe doen:

• WP_DEBUG zet het melden van fouten aan. Zonder de volgende twee instellingen komen die meldingen op het scherm terecht, ook bij bezoekers.
• WP_DEBUG_LOG schrijft de meldingen naar een bestand, standaard wp-content/debug.log.
• WP_DEBUG_DISPLAY bepaalt of de meldingen op het scherm worden getoond. Die wilt u op false.

Het risico van alleen WP_DEBUG aanzetten is dat bezoekers foutmeldingen zien met bestandspaden, pluginnamen en soms databasegegevens. Dat is slordig en geeft aanvallers gratis informatie. Het risico van het log is dat het bestand op een voorspelbare plek staat en door iedereen is op te vragen als de server het niet afschermt. Beide risico’s zijn eenvoudig te ondervangen, mits u het goed instelt en daarna weer uitzet.

Stap 1: wp-config.php veilig aanpassen

1. Maak via FTP of de bestandsbeheerder van uw hosting een kopie van wp-config.php (bijvoorbeeld wp-config-kopie.txt). Een typefout in dit bestand legt de hele site plat, en met een kopie zet u dat in tien seconden terug.
2. Open het bestand in een kale teksteditor. Zoek de regel define( ‘WP_DEBUG’, false );. Staat die er niet, zoek dan de regel met /* That’s all, stop editing! */; daarboven komen uw regels.
3. Vervang of voeg toe:
   • define( ‘WP_DEBUG’, true );
   • define( ‘WP_DEBUG_LOG’, true );
   • define( ‘WP_DEBUG_DISPLAY’, false );
   • @ini_set( ‘display_errors’, 0 );
4. Sla op en upload. Laad de site: hij hoort er precies zo uit te zien als daarvoor. Ziet u nu foutmeldingen op het scherm, dan is WP_DEBUG_DISPLAY niet goed overgenomen.

Wilt u het log op een plek buiten de webroot, geef WP_DEBUG_LOG dan een pad in plaats van true, bijvoorbeeld een map boven public_html. Dan kan niemand het bestand via de browser opvragen. Kan dat niet bij uw hosting, voeg dan in .htaccess een regel toe die toegang tot debug.log weigert; de meeste beveiligingsplugins doen dat al.

Stap 2: de fout uitlokken en het log lezen

Het log vult zich pas als er iets misgaat. Herhaal dus de handeling die het probleem veroorzaakt: open de pagina die wit blijft, verstuur het formulier, sla het bericht op. Open daarna wp-content/debug.log via FTP of de bestandsbeheerder. Elke regel begint met datum en tijd, gevolgd door het type melding en de plek:

[07-Sep-2026 09:14:22 UTC] PHP Fatal error: Uncaught Error: Call to undefined function example_helper() in /home/site/public_html/wp-content/plugins/voorbeeld-plugin/includes/loader.php:214

Zo leest u die regel. Fatal error is het type: dit is een fout die de pagina stopt. Warning en Notice (of Deprecated) zijn waarschuwingen; die stoppen niets en mogen u niet afleiden, hoe veel er ook staan. Het pad na in wijst naar het bestand, en dus naar de plugin of het thema. Het getal na de dubbele punt is de regel. U hoeft de code niet te begrijpen; de mapnaam in het pad zegt u welke plugin u tijdelijk moet uitschakelen of welke ontwikkelaar u de regel stuurt.

Zoek in het log naar de laatste Fatal error. Daarboven staan vaak tientallen waarschuwingen van andere plugins die niets met uw probleem te maken hebben. Bij een pluginconflict is de fatale fout de plek om te beginnen; hoe u het conflict daarna verder uitzoekt, staat in onze aanpak om een pluginconflict te vinden.

Stap 3: extra hulpmiddelen als het log niet genoeg zegt

Soms is er geen fatale fout maar gedraagt de site zich vreemd. Dan zijn er twee aanvullingen:

• Query Monitor, een gratis plugin die in de beheerbalk laat zien welke PHP-fouten, trage databasequery’s en falende verzoeken er op de huidige pagina zijn. Handig voor problemen die alleen bij bepaalde pagina’s optreden. Alleen zichtbaar voor ingelogde beheerders.
• SCRIPT_DEBUG, nog een instelling in wp-config.php, die WordPress de niet-gecomprimeerde versies van scripts laat laden. Nuttig bij JavaScript-fouten in het beheer, zoals een editor die niet laadt.

Geeft het log helemaal niets, controleer dan of de map wp-content beschrijfbaar is, en of uw hostingpartij PHP-fouten wellicht op een eigen plek logt (vaak een map logs in het hostingpaneel).

Stap 4: alles weer uitzetten

Dit is de stap die het vaakst wordt vergeten, en dat ziet u in de praktijk terug aan sites met een debug.log van 800 megabyte dat de schijfruimte opslokt en de server vertraagt. Zodra u het probleem heeft gevonden:

1. Zet in wp-config.php WP_DEBUG terug op false. De andere regels mogen blijven staan; zonder WP_DEBUG doen ze niets.
2. Verwijder het bestand debug.log, of bewaar een kopie op uw eigen computer als u de regels nog aan een ontwikkelaar wilt sturen.
3. Controleer de site nog één keer op het scherm.

Noteer in uw documentatie dat u het heeft aan- en uitgezet. Als u de site later overdraagt aan een onderhoudspartij, weten zij dan wat er is gewijzigd.

Wat u zelf doet en wanneer u hulp inschakelt

Het aanzetten en lezen van het log is met een kopie van wp-config.php achter de hand goed te doen. De stap erna, de fout daadwerkelijk oplossen, hangt af van wat u vindt. Een plugin uitschakelen of een update terugdraaien kunt u zelf. Zit de fout in het thema, in een aanpassing van een vorige bouwer of in de server, dan is het tijd voor iemand die de code kan lezen. Een WordPress-bugfixingdienst begint precies waar u nu bent: met het log in de hand, en meestal met een oplossing binnen het uur.

Een bakkerij in Leiden had drie weken een witte bestelpagina en had in die tijd twee plugins vervangen en het thema opnieuw geïnstalleerd. Het log, dat na het inschakelen binnen een minuut gevuld was, wees naar één regel in een verlaten leveringsplugin die de nieuwe PHP-versie niet aankon. Uitzetten, klaar. Al het andere werk was niet nodig geweest.

Conclusie

De debug-modus is het eerste gereedschap bij elke storing die geen uitleg geeft. Zet hem aan met de drie regels in wp-config.php, houd meldingen van het scherm, lok de fout uit, lees de laatste fatale fout, en zet hem daarna weer uit. Wie dat een keer heeft gedaan, kijkt nooit meer op dezelfde manier naar een wit scherm.