WordPress debug.log aanzetten en lezen (WP_DEBUG uitgelegd)
Laatst bijgewerkt:
Als WordPress een kritieke fout, een wit scherm of vreemd gedrag geeft, staat de echte oorzaak bijna altijd in een PHP-foutregel. Met de ingebouwde debugfunctie van WordPress schrijf je die regels weg naar een bestand, zonder dat je bezoekers ze te zien krijgen. Hier lees je welke instellingen je nodig hebt, hoe je de log leest en wat je achteraf opruimt.
De instellingen in wp-config.php
Open wp-config.php in de hoofdmap van je site (via bestandsbeheer, FTP of SSH). Staat er al een regel met WP_DEBUG, pas die dan aan in plaats van een tweede toe te voegen. Zet het geheel boven “That's all, stop editing!”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );| Constante | Wat het doet |
|---|---|
WP_DEBUG | Zet de debugmodus aan. Zonder deze staan de andere twee uit. |
WP_DEBUG_LOG | Schrijft fouten naar wp-content/debug.log. Je kunt ook een eigen pad opgeven, bijvoorbeeld een map buiten de webroot: define( 'WP_DEBUG_LOG', '/pad/buiten/webroot/wp-fouten.log' ); |
WP_DEBUG_DISPLAY | Toont fouten op de pagina. Op een live site altijd false: bezoekers zien anders paden en details van je site. |
SCRIPT_DEBUG | Laadt de niet-verkleinde CSS- en JavaScript-bestanden van WordPress. Alleen nodig bij problemen in het beheer of de blokeditor. |
SAVEQUERIES | Bewaart alle databasevragen per pagina. Maakt de site trager; alleen kort gebruiken. |
Zo lees je debug.log
Laad de pagina met het probleem opnieuw en open wp-content/debug.log. Een regel ziet er zo uit:
[21-Oct-2026 10:15:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined
function voorbeeld() in /home/…/wp-content/plugins/voorbeeld-plugin/voorbeeld.php:42- Tijdstip (in UTC): kijk naar de regels van het moment dat jij de pagina laadde.
- Soort fout:
Fatal errorstopt de pagina en is de oorzaak van een kritieke fout.Warning,NoticeenDeprecatedzijn waarschuwingen; die laten de site meestal werken. - Pad:
/plugins/naam/wijst naar een plugin,/themes/naam/naar je thema,/wp-includes/naar WordPress zelf (vaak aangeroepen door een plugin; kijk dan verder in de “Stack trace”-regels eronder).
Veelvoorkomende regels en wat je ermee doet
| Regel | Betekenis en actie |
|---|---|
Allowed memory size of … bytes exhausted | Te weinig geheugen. Zie geheugenlimiet verhogen. |
Maximum execution time of 30 seconds exceeded | Taak duurde te lang. Zie maximum execution time. |
Call to undefined function / Uncaught TypeError | Vaak een plugin of thema dat niet past bij de PHP-versie. Zie PHP-versie updaten. |
Cannot redeclare … | Twee plugins (of een plugin en je thema) met dezelfde functienaam, of een plugin die twee keer is geïnstalleerd. |
Function _load_textdomain_just_in_time was called incorrectly | “Vertaling laden … werd te vroeg geactiveerd”. Een melding sinds WordPress 6.7 over een plugin of thema dat vertalingen te vroeg laadt. Onschuldig voor bezoekers; de maker moet het oplossen. |
WordPress database error | Een databasevraag mislukt, bijvoorbeeld door een ontbrekende tabel na een mislukte update. Zie ook databasefout in WordPress. |
Geen debug.log? Controleer dit
- Staat er maar één
WP_DEBUG-regel inwp-config.php, en staat die boven “That's all, stop editing!”? - Mag WordPress schrijven in
wp-content? Bij verkeerde bestandsrechten wordt het bestand niet aangemaakt. - Gebeurt de fout vóór WordPress geladen is (bijvoorbeeld een fout in
wp-config.phpzelf)? Kijk dan in de PHP-foutlog van je hostingpaneel. - Treedt de fout alleen in het beheer op? Laad dan juist die beheerpagina opnieuw.
Andere manieren om fouten te zien
- Herstelmodus-mail: bij een fatale fout mailt WordPress de beheerder met de foutregel. Zie kritieke fout oplossen.
- Query Monitor: toont PHP-fouten, trage databasevragen en geheugengebruik per pagina, alleen voor ingelogde beheerders.
- Sitestatus (Gereedschap → Sitestatus): geeft geen foutregels, maar wel kritieke problemen zoals verouderde PHP of ontbrekende extensies.
- WP-CLI:
wp eval 'echo WP_DEBUG ? "aan" : "uit";'laat zien of de debugmodus aan staat.
Na afloop: opruimen
Zet WP_DEBUG weer op false zodra je de oorzaak hebt. Verwijder of leeg wp-content/debug.log: het bestand is vaak via de browser op te vragen en bevat paden en soms gegevens van je site. Laat je de log langer aan, gebruik dan een eigen pad buiten de webroot en houd de grootte in de gaten.
Veelgestelde vragen
Waar staat debug.log in WordPress?
Standaard in de map wp-content, als wp-content/debug.log. Heb je bij WP_DEBUG_LOG een eigen pad opgegeven, dan staat het daar.
Is WP_DEBUG veilig op een live website?
Ja, als je WP_DEBUG_DISPLAY op false zet, zodat bezoekers geen fouten zien, en de log na afloop weer uitzet en verwijdert. Fouten tonen op de pagina is op een live site niet verstandig.
Waarom wordt er geen debug.log aangemaakt?
Vaak staat WP_DEBUG twee keer in wp-config.php, staan de regels onder "That's all, stop editing!", of mag WordPress niet schrijven in wp-content. Ook fouten die optreden voordat WordPress geladen is, komen niet in debug.log maar in de PHP-foutlog van je hosting.
Moet ik iets doen met Deprecated- en Notice-meldingen?
Niet direct: ze breken de site niet. Ze laten wel zien welke plugin of welk thema verouderde code gebruikt. Houd die in de gaten bij een volgende PHP-update.
Snap je de foutregel niet?
Stuur ons de regel uit debug.log; wij vertellen je wat het is en lossen het op als je dat wilt.
Hulp aanvragen Site plat? SpoedhulpLees ook: kritieke fout in WordPress · wit scherm · 500-fout · geheugenlimiet verhogen · PHP-versie updaten · Query Monitor