Serhii LypiiEen WordPress error log lezen levert vaak meer op dan drie tickets bij hosting-support, omdat hosting-support naar een ánder log kijkt. Die ene zin verklaart waarom zo veel mensen weken bezig zijn met een onverklaarbare fout die in een logfile al de hele tijd helder staat.
In mijn ervaring loopt dit precies zo: een ondernemer mailt naar hosting-support over een witte pagina, een 500-fout, of een onverwacht 503. Support draait een check op de server-error-log, ziet niets bijzonders, mailt terug “geen fouten gevonden”. Terwijl in de WordPress-eigen debug.log keurig de exacte regel code staat die struikelt. Maar dat log staat los van wat support inkijkt.
Waarom hosting-support vaak “geen fout” zegt
Hosting-support kijkt standaard naar het server-error-log. Bij Apache is dat meestal /var/log/apache2/error.log of een per-domein-variant. Bij Nginx hetzelfde, andere paden. Dat logfile bevat fouten op het niveau van de webserver: 500-statuscodes, 503-fouten, PHP-fatals die het script helemaal opblazen.
Maar er is een tweede categorie fouten die daar niet in komt: WordPress-interne fouten. Een plugin die een notice gooit, een functie die deprecated wordt, een query die niets oplevert maar wel een waarschuwing veroorzaakt. Die staan in wp-content/debug.log, mits je dat logbestand hebt aangezet. Hosting-support komt daar zelden bij.
Het gevolg: support meldt te goeder trouw dat er “niets aan de hand is”, terwijl debug.log de oorzaak letterlijk noemt. Een uur zelf het log inkijken (of door iemand laten inkijken) bespaart vaak een week heen-en-weer mailen.
WordPress error log lezen begint met WP_DEBUG_LOG aanzetten
Standaard staat WordPress-debugging uit. Dat is op productie ook goed: foutmeldingen op de site zelf zijn lelijk én een veiligheidsrisico. Maar het log opslaan zonder ze te tonen is wel verstandig. Daar dienen drie constanten voor in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG zet debug-modus aan. WP_DEBUG_LOG zegt: schrijf fouten naar een logfile (standaard /wp-content/debug.log). WP_DEBUG_DISPLAY = false zorgt dat fouten niet op de pagina zelf verschijnen.
Plaats deze regels boven de regel die zegt /* That's all, stop editing! Happy publishing. */ in wp-config.php. Anders worden ze overschreven door WordPress’ default-instellingen.
Optioneel maar handig is define( 'SCRIPT_DEBUG', true );. Daarmee laadt WordPress unminified versies van core JS en CSS, wat het debugging van front-end-fouten makkelijker maakt. Op productie wel weer uitzetten als je klaar bent, want unminified bestanden zijn groter.
Wat in wp-config.php hoort: de constanten op een rij
Voor productiegebruik is dit mijn standaard-set:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );De @ini_set is een extra zekerheid: hij overrulet eventuele PHP-instellingen die fouten alsnog op het scherm willen tonen. Belt-en-bretels.
Op staging of lokaal mag je WP_DEBUG_DISPLAY op true zetten. Dan zie je fouten direct, wat tijdens ontwikkelen prettig is. Maar op productie: nooit.
Waar debug.log staat en hoe je hem veilig leest
Standaardlocatie: /wp-content/debug.log. Te lezen via FTP, SFTP, of de file manager van je hoster. Met een SSH-toegang ben je nog sneller: tail -f wp-content/debug.log laat hem live meelopen terwijl jij in een andere browser-tab acties uitvoert op de site.
Een belangrijke veiligheidsstap: debug.log is publiek toegankelijk als hij in /wp-content/ staat zonder bescherming. Iemand die https://jouwsite.nl/wp-content/debug.log opent, kan hem lezen. Dat is een lek van interne info: paden, database-tabellen, plugin-namen, soms wachtwoorden uit slecht geschreven plugins.
Twee oplossingen:
Optie A: .htaccess-bescherming. Voeg in wp-content/ een .htaccess toe met:
<Files debug.log>
Order allow,deny
Deny from all
</Files>Optie B: log buiten webroot. Geef in wp-config.php een ander pad op:
define( 'WP_DEBUG_LOG', '/home/jouwgebruiker/logs/wordpress-debug.log' );Dat pad moet bestaan en schrijfbaar zijn voor PHP. Veiliger maar iets meer setup.
Drie type fouten: notice, warning, fatal
Niet elke regel in debug.log is even urgent. Drie niveaus, in toenemende ernst:
Notice. Code-smell. Iets is niet zoals het hoort, maar de code werkt nog. Bijvoorbeeld “Undefined index: foo in /path/to/plugin.php on line 42”. Een plugin probeert een array-key te lezen die niet bestaat. Niet kapot, wel rommelig. Honderden notices in een log betekent vaak: één plugin is sloppy geschreven.
Warning. Waarschuwing. De code voert nog uit, maar het resultaat is mogelijk niet wat je verwacht. “Warning: array_map() expects parameter 2 to be array, null given”. Code zit te wrikken aan een waarde die er niet hoort. Vaak een teken dat een vorige stap (een query, een API-call) iets anders teruggaf dan verwacht.
Fatal. Stuk. De PHP-script stopt direct. “Fatal error: Uncaught Error: Call to undefined function…” of “Maximum execution time of 30 seconds exceeded”. Dit is je 500-fout op de site. Fatals zijn altijd onmiddellijk actie.
Praktische volgorde: fatals oplossen, warnings bekijken op clusters (zelfde plugin? zelfde context?), notices negeren tenzij ze in extreme aantallen voorkomen.
WordPress debug-log helper
Maak een veilige debug-setup en lees je foutmelding
Stel de debug-constanten in zonder fouten aan bezoekers te tonen. Plak daarna een logregel voor een rustige uitleg en volgende stap.
De veilige basis staat al aan. Gebruik de extra opties alleen tijdelijk wanneer je gericht onderzoekt.
Plaats dit boven /* That's all, stop editing! */ in wp-config.php.
Kies het type zelf of plak een volledige regel. Herkenbare patronen krijgen voorrang op je keuze.
Volgende stap:
- Het standaardbestand staat op
wp-content/debug.log. - Lees eerst de eerste relevante fout en noteer bestand, regelnummer en tijdstip.
- Laat het logbestand niet langer dan nodig publiek bereikbaar en verwijder gevoelige logdata na je onderzoek.
- Zet WP_DEBUG, SCRIPT_DEBUG en SAVEQUERIES na de test weer uit.
Een hulpmiddel. Bij een fatal error op een live site zijn een recente back-up en een staging-omgeving aan te raden.
Server-logs versus WordPress-logs
Twee logfiles, twee verschillende stories. Wat staat waar?
WordPress debug.log (/wp-content/debug.log): PHP-fouten die binnen WordPress optreden. Plugin-issues, theme-fouten, queries die niets terugleveren. Wat WordPress zelf ziet en wil melden.
Server-error-log (Apache/Nginx): Fouten op webserver-niveau. 500-statuscodes, request die nooit bij PHP aankwam, fouten in .htaccess-regels, PHP-segfaults die WordPress niet eens kan loggen omdat PHP zelf crasht.
PHP-error-log (per-domein): Fouten in PHP-configuratie, memory limits, geheugen-allocaties. Vaak ergens onder /var/log/php/ of toegankelijk via hosting-paneel (“PHP error log” of “Error logs”).
In mijn ervaring is debug.log de eerste plek om te kijken, server-error-log de tweede, en alleen bij hardnekkige gevallen ook PHP-error-log. Als debug.log leeg is bij een 500-fout, dan zit het probleem buiten WordPress: een .htaccess-regel, een memory-limit, een server-config-issue.
Voor live-monitoring van WordPress-warnings binnen admin is Query Monitor een gratis plugin die naast debug.log werkt. Hij toont warnings, slow queries en hooks per pageload. Handig als je niet voor elke fout een tail in een terminal wil openen.
Wanneer je log opruimt en wanneer je hem bewaart
Een actief debug.log kan snel groot worden. Een zelfde fout die honderden keren per dag wordt gelogd, vult een logfile in een week tot 50 MB en hoger.
Mijn richtlijn:
- Onder 10 MB: prima, laat staan.
- Tussen 10 en 50 MB: scrol naar het einde, kijk welke recente fouten erin staan, en archiveer als je iets specifiek wil oplossen.
- Boven 50 MB: opruimen, of een rotation instellen. Een log van 100 MB is praktisch onleesbaar en kost disk-space.
Voor het oplossen van een specifiek probleem is een schone log handig. Maak een back-up van de huidige debug.log, leeg hem (> debug.log via SSH, of via FTP de inhoud verwijderen), voer de actie uit die de fout veroorzaakt, en lees alleen wat nieuw is binnengekomen.
Verbeteren boven herbouwen geldt ook voor logs lezen: meestal is de oorzaak een specifieke regel in een specifieke plugin, en is daar in een halfuur een fix voor. Een hele site opnieuw bouwen omdat één plugin notices spuit is overkill.
Voor mensen die het regelmatig moeilijk vinden om er zelf doorheen te komen is een doorlopend WordPress onderhoud waarin logs structureel worden gemonitord meestal goedkoper dan elke maand losse uren. Logs lezen voordat het probleem groot wordt is mijn definitie van onderhoud.
Voor wie het exacte WordPress-debug-spec wil lezen is de officiële WordPress debug-documentatie de bron. Daar staan alle constanten plus de minder gebruikte zoals WP_DEBUG_DISPLAY en logging naar specifieke streams.
Tot slot: hetzelfde principe geldt voor andere stacks. Laravel heeft storage/logs/laravel.log, Drupal heeft de dblog-module en Watchdog-tabel, Joomla logt naar zijn eigen logfolder. De tools verschillen, maar het idee is identiek: lees voordat je gokt. Een lokaal aanspreekpunt in Terneuzen helpt vooral als je dat lezen niet zelf wilt doen.
