Er gaat iets mis op uw website. Een pagina blijft wit, een formulier doet niets of er verschijnt een vage melding over een kritieke fout. U kijkt in WordPress rond, ziet niets bijzonders, en de hosting zegt dat het aan uw site ligt. Frustrerend, want er is nergens uitleg te vinden.

Die uitleg is er wel, alleen staat hij ergens waar u nog nooit heeft gekeken. Het WordPress-foutenlog is een simpel tekstbestand waarin de server opschrijft wat er misging, in welk bestand en op welke regel. U hoeft geen programmeur te zijn om er iets aan te hebben. Als u drie dingen leert herkennen, kunt u in de meeste gevallen zelf aanwijzen welke plugin de veroorzaker is, en dat is precies de informatie waar een oplossing mee begint.

Het log aanzetten

Standaard schrijft WordPress geen foutenbestand weg. Dat zet u aan in het bestand wp-config.php, dat in de hoofdmap van uw website staat. U komt daar via de bestandsbeheerder in uw hostingpaneel of via FTP.

  1. Maak eerst een kopie van wp-config.php op uw eigen computer. Gaat er iets mis, dan zet u die terug.
  2. Zoek in het bestand naar de regel met de tekst That’s all, stop editing!. Alles wat u toevoegt, komt daarboven.
  3. Staat er ergens een regel met WP_DEBUG op false, verwijder die dan of zet er twee schuine strepen voor.
  4. Voeg deze drie regels toe: define( ‘WP_DEBUG’, true ); gevolgd door define( ‘WP_DEBUG_LOG’, true ); en define( ‘WP_DEBUG_DISPLAY’, false );
  5. Sla het bestand op en laad uw website opnieuw.

Die derde regel is belangrijk. Die zorgt dat fouten worden weggeschreven maar niet op het scherm verschijnen. Zonder die regel zien uw bezoekers ineens rode technische meldingen boven aan uw pagina’s, en dat is een slechte vertoning en bovendien onverstandig: zulke meldingen verraden paden en versienummers. Meer daarover leest u in het artikel over zichtbare PHP-fouten.

Het logbestand verschijnt in de map wp-content onder de naam debug.log. Het bestaat pas zodra er daadwerkelijk iets fout gaat, dus als het er niet meteen staat, bezoek dan eerst de pagina waar het probleem zich voordoet.

Zo leest u een regel

Elke regel in het log heeft dezelfde opbouw: een datum en tijd, het soort melding, een omschrijving, en dan het bestand en het regelnummer. Dat laatste stuk is voor u het belangrijkst, want daar staat welke plugin of welk thema de fout veroorzaakt. Ziet u in het pad iets als wp-content/plugins/naam-van-plugin/, dan weet u genoeg.

Het soort melding vertelt u hoe erg het is:

  • Fatal error. Dit is de ernstige. De uitvoering stopt hier, en dit is wat een wit scherm of een kritieke fout veroorzaakt. Ga altijd eerst hierop af.
  • Warning. Er ging iets mis, maar de pagina laadt verder. Kan de oorzaak zijn van een blok dat niet verschijnt of een lijst die leeg blijft.
  • Notice en Deprecated. Meldingen dat code iets doet wat niet netjes of niet meer ondersteund is. Meestal onschuldig, maar honderden deprecated-regels van dezelfde plugin zijn een teken dat die plugin achterloopt op uw PHP-versie.

Een paar veelvoorkomende omschrijvingen in gewone taal. “Allowed memory size exhausted” betekent dat het geheugen op is; dat lost u meestal op door de PHP-geheugenlimiet te verhogen. “Call to undefined function” betekent dat er code wordt aangeroepen die niet bestaat, vaak omdat een plugin een andere plugin verwacht die is uitgeschakeld. “Maximum execution time exceeded” betekent dat een taak te lang duurde. En “Cannot modify header information” duidt bijna altijd op een overbodige spatie of lege regel in een bestand dat iemand heeft aangepast.

Van log naar oorzaak, in vier stappen

  1. Kijk naar de tijdstempel. Alleen regels van rond het moment dat het probleem optrad zijn interessant. Alles van vorige maand negeert u.
  2. Zoek de eerste fatal error van dat tijdstip. Wat daarna komt, is vaak een gevolg en geen oorzaak.
  3. Lees het pad. Staat er een pluginnaam in, dan heeft u uw verdachte. Staat er wp-content/themes/, dan zit het in uw thema. Staat er wp-includes/, kijk dan wie die code aanriep; het probleem ligt zelden in WordPress zelf.
  4. Test uw vermoeden. Schakel de betreffende plugin uit en kijk of het probleem verdwijnt. Zo ja, dan weet u het zeker. Hoe u dat systematisch aanpakt, leest u in het artikel over pluginconflicten opsporen.

Een voorbeeld. Een sportschool in Eindhoven zag na een update dat de lesroosterpagina leeg bleef. Het log gaf één regel: een fatal error in de map van een oude kalenderplugin, met de melding dat een functie niet bestond. Die plugin bleek gebruik te maken van een functie die in de nieuwe PHP-versie was verwijderd. Vijf minuten lezen leverde meteen de juiste vraag op, en dat scheelde een middag zoeken.

Waar u nog meer kunt kijken

Het debug.log gaat over PHP-fouten in WordPress zelf. Er zijn twee andere plekken die vaak net zoveel vertellen.

Ten eerste het serverlog van uw hosting. In DirectAdmin, cPanel of Plesk vindt u onder de noemer logs of foutenlogboek de meldingen van de webserver. Daar staan zaken die WordPress nooit bereikt: geweigerde bestanden, geheugenproblemen op serverniveau en tijdslimieten. Dit log is ook uw ingang bij een foutmelding met een getal in de vijfhonderd.

Ten tweede de console van uw browser. Rechtermuisknop, Inspecteren, tabblad Console. Daar staan fouten in JavaScript, en die verklaren dingen die er raar uitzien terwijl de server geen fout meldt: een menu dat niet openklapt, een slider die stilstaat of een knop die niets doet.

Zet het daarna weer uit

Dit is de stap die het vaakst wordt vergeten en die u niet mag overslaan. Laat u het loggen aanstaan, dan groeit debug.log op een drukke site razendsnel; wij hebben bestanden van meerdere gigabytes gezien die de schijfruimte volledig hadden opgesoupeerd. Bovendien is het bestand op veel servers gewoon via de browser op te vragen, en dan geeft u paden en versienummers weg aan wie ernaar zoekt.

Zet WP_DEBUG dus terug op false zodra u klaar bent, en verwijder het logbestand. Wilt u het langer aan laten staan om een sluipend probleem te vangen, verplaats het log dan naar een map buiten de openbare webmap; uw hostingpartij kan u vertellen hoe.

Concrete volgende stap: zet het log aan, herhaal de handeling waarbij het misgaat, en lees de eerste fatal error. Weet u daarna welke plugin het betreft maar niet hoe u het oplost, dan heeft u in elk geval de informatie waarmee elke hulplijn direct verder kan. Bij een terugkerende of onduidelijke fout is dat log precies waar iedereen die uw website beheert als eerste naar vraagt, en bij WebMaintor is het de standaard eerste stap bij elke storingsmelding.