Locatie van de WordPress debug log: waar debug.log staat en hoe je hem verplaatst

WordPress schrijft zijn debug log standaard naar wp-content/debug.log — op schijf een absoluut pad als /pad/naar/je/site/wp-content/debug.log. Het bestand bestaat pas als er daadwerkelijk iets gelogd wordt, en er wordt sowieso alleen naar geschreven als WP_DEBUG op true staat en WP_DEBUG_LOG is ingeschakeld in wp-config.php. Die standaardlocatie is ook een reëel beveiligingsprobleem, want op de meeste hosts kan iedereen het bestand in een browser ophalen.

De drie constanten en wat elk ervan doet

Alle drie horen in wp-config.php, boven de regel /* That's all, stop editing! Happy blogging. */. Alles wat je onder die regel toevoegt, draait nadat WordPress al is opgestart en wordt genegeerd.

Constante	Standaard	Wat het doet
WP_DEBUG	false	Hoofdschakelaar. Zet de foutrapportage van PHP hoger zodat notices, waarschuwingen en deprecations verschijnen. Zonder deze werkt niets anders uit deze lijst.
WP_DEBUG_LOG	false	Stuurt fouten naar een bestand. true betekent wp-content/debug.log. Een tekstwaarde wordt gelezen als het pad waarnaar geschreven moet worden.
WP_DEBUG_DISPLAY	true	Drukt fouten af in de HTML van de pagina, zichtbaar voor elke bezoeker.

De onderlinge afhankelijkheid is wat mensen fout doen. WP_DEBUG_LOG wordt uitgelezen binnen de WP_DEBUG-tak van de opstartcode van WordPress. Staat WP_DEBUG op false, dan doet WP_DEBUG_LOG op true zetten helemaal niets — geen bestand, geen fout, geen waarschuwing. Heb je WP_DEBUG_LOG toegevoegd en verscheen er geen log, controleer dan eerst WP_DEBUG.

Een werkende configuratie voor een live site:

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

Staat WP_DEBUG al hoger in het bestand gedefinieerd — meestal wel, op false — pas dan die bestaande regel aan in plaats van een tweede define() toe te voegen. Dezelfde constante twee keer definiëren levert een PHP-waarschuwing op, en op een site waar tonen aanstaat, belandt die pal boven aan je pagina.

Waarom WP_DEBUG_DISPLAY op productie uit moet

Met tonen aan worden PHP-fouten in het HTML-antwoord geëchood. Eén enkele deprecation-melding uit een thema drukt het absolute pad op je server af voor elke bezoeker. Een databasefout drukt tabelnamen en fragmenten van queries af. Erger nog: uitvoer die vóór de headers verschijnt, breekt redirects, breekt REST- en AJAX-antwoorden die schone JSON verwachten, en kan het witte scherm veroorzaken waar mensen vervolgens een plugin de schuld van geven.

Eén subtiliteit is het waard: WP_DEBUG_DISPLAY op null zetten is niet hetzelfde als false. Met null laat WordPress de display_errors-instelling van PHP met rust en neemt het over wat de server heeft ingesteld. Met false wordt hij actief uitgezet. Gebruik op een productiesite false en voeg de ini_set-regel hierboven toe als extra zekerheid, want een plugin kan display_errors later in het verzoek alsnog weer aanzetten.

De standaardlocatie is publiek op te vragen

wp-content/debug.log staat binnen de webroot. Niets in een standaard WordPress-installatie blokkeert directe verzoeken ernaartoe. Op een gangbare Apache- of nginx-opzet geeft https://jouwsite.nl/wp-content/debug.log het bestand gewoon terug als platte tekst. Debug logs bevatten absolute serverpaden, interne details van plugins en thema’s, databasefouten met echte querytekst en soms waarden die door mislukkende functies zijn doorgegeven. Dat is gratis verkenningswerk voor iedereen die de URL raadt — en het is een van de eerste URL’s die geautomatiseerde scanners proberen.

Er zijn twee manieren om dit aan te pakken. De betere is de log verplaatsen.

Verplaats de log met een pad

Sinds WordPress 5.1 accepteert WP_DEBUG_LOG een tekstpad in plaats van een boolean. Wijs naar een plek buiten de documentroot:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Drie regels voor dat pad. Gebruik een absoluut pad — een relatief pad wordt afgehandeld ten opzichte van de werkmap van PHP, die per verzoek en per server verschilt, dus je raakt het spoor van het bestand bijster. De map moet al bestaan; PHP maakt hem niet aan, en als het bestand niet geopend kan worden, mislukt het geruisloos. En de map moet beschrijfbaar zijn voor de PHP-gebruiker, wat op shared hosting niet hetzelfde account is als waarmee jij via SFTP inlogt.

Houdt je hosting je binnen de webroot en is er nergens boven die map iets te schrijven, hou dan het standaardpad aan en blokkeer de toegang op serverniveau. Apache:

<Files "debug.log">
  Require all denied
</Files>

Dat hoort in een .htaccess-bestand binnen wp-content, niet in die van de hoofdmap — WordPress herschrijft de .htaccess in de hoofdmap zodra je permalinks opslaat en kan je toevoeging wissen. Op nginx doet .htaccess helemaal niets; daar heb je een location-blok in de serverconfiguratie nodig, wat bij managed hosting meestal betekent dat je de support moet vragen.

Wees eerlijk over wat blokkeren je oplevert: het bestand staat nog steeds op schijf, in een map die de webserver uitlevert. Een path-traversal-bug in een willekeurige plugin kan het alsnog uitlezen. Het buiten de webroot halen is de sterkere oplossing.

Het bestand lezen en live volgen

Via SSH volg je hem live terwijl je de bug nabootst:

tail -f wp-content/debug.log

Roep de fout op in een ander tabblad en de nieuwe regels verschijnen terwijl ze geschreven worden. Om alleen te zien wat er recent gebeurd is, of om op één plugin te filteren:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP schrijft achteraan het bestand, dus lees van onder naar boven. Elke regel heeft een tijdstempel in UTC, wat niet overeenkomt met de tijdzone-instelling van je WordPress — laat dat je niet in de waan brengen dat je naar oude regels kijkt.

Met WP-CLI kun je de constanten omzetten zonder het bestand met de hand te bewerken:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

De vlag --raw is essentieel — zonder die vlag wordt de waarde weggeschreven als de tekst "true" in plaats van als boolean. Voor de padvariant laat je --raw juist weg, zodat hij als tekst tussen aanhalingstekens komt te staan.

Geen SSH? Download het bestand via SFTP of open het in de bestandsbeheerder van je host. Vermijd plugins die de log binnen wp-admin tonen, tenzij je ze volledig vertrouwt; je geeft zo’n plugin leestoegang tot een bestand vol interne servergegevens.

Wil je het exacte wp-config-blok voor jouw situatie, inclusief een veilig pad buiten de webroot en de bijbehorende serverregel, dan bouwt de WordPress debug log generator hem voor je.

Zet het uit als je klaar bent

Niets in de WordPress-core roteert of leegt debug.log. Op een site die bij elke paginalading een notice geeft, groeit hij ongelimiteerd en kan hij de schijf vullen — wat de site harder onderuithaalt dan de bug die je aan het opsporen was. Zet het loggen aan, boots het probleem na, lees de log en zet WP_DEBUG daarna terug op false.

Om het bestand te legen zonder het te verwijderen:

: > wp-content/debug.log

Als de log leeg blijft

Werk deze op volgorde af. WP_DEBUG staat op false — veruit de meest voorkomende oorzaak, en het schakelt geruisloos al het andere uit. De constante staat onder de regel “stop editing” in wp-config.php. Bestandsrechten — PHP kan niet schrijven naar wp-content, of naar de eigen map die je hebt opgegeven. Een kritieke fout voordat wp-config klaar is met laden, zoals een syntaxfout in het configuratiebestand zelf, gebeurt te vroeg voor het loggen van WordPress; die belandt in de eigen PHP-foutlog van de server. Je host overschrijft het — sommige managed platformen zetten de error_log-instelling van PHP vast of sturen het loggen naar hun eigen dashboard, en dan staan jouw constanten gewoon goed en staat de uitvoer ergens anders. Kijk in de logviewer van je host voordat je aanneemt dat je configuratie kapot is.