WordPress debuggen in 8 stappen!

WordPress maakt het zelf beheren van je website stukken makkelijker! Daarom is het niet per se nodig een webbouwer in de arm te nemen of dit zelf te zijn. Maar als niet-webbouwer vraag jij je wellicht af wat je moet doen, als je website na een update of wijziging niet meer werkt. We leggen je daarom graag uit hoe WordPress debuggen werkt!

WordPress debuggen in 8 stappen!

Voor we dieper op het debuggen van je WordPress-website ingaan eerst wat algemeen advies. Het is altijd goed om een actuele backup achter de hand te hebben. Nu hoef je natuurlijk niet bij iedere tekstuele wijziging een nieuwe backup te maken, maar bij updates van plugins, thema’s of het CMS zelf is dat zeker aan te raden.

Antagonist Backups
Op onze Slim-, Plus- en Pro-pakketten heb je altijd de beschikking over actuele herstelpunten. Foutjes zijn daarmee gemakkelijk te herstellen. Ook als je dus zelf geen backup hebt gemaakt!

1. Wat gaat er mis?

Om een probleem te kunnen troubleshooten, is het goed om eerst te bekijken wat er mis gaat. Heb je bijvoorbeeld een slider die ineens stil blijft staan? Of krijg je alleen een witte pagina te zien, waar normaal je website in volle glorie te bekijken was? Het is daarom handig om het volgende duidelijk te hebben:

  • wat had je verwacht dat er zou gebeuren;
  • en wat gebeurt er nu?

2. Wat is er veranderd?

Goed, je hebt nu vastgesteld dat iets anders werkt dan dat je zou verwachten. Nu wil je natuurlijk weten waardoor dat komt. Want hoewel het soms zo kan lijken, komt het ineens niet meer werken van je website niet uit de lucht vallen. Als er écht niets was gewijzigd, dan had je immers nog een werkende website.

Het is dus belangrijk allereerst na te gaan wat er gewijzigd is. Als je net een instelling hebt aangepast, een bestand hebt verwijderd of een nieuwe plugin hebt geactiveerd, dan is de oorzaak gemakkelijk aan te wijzen. Helaas is het niet altijd zo duidelijk en is verder onderzoek nodig. Troubleshooten dus!

3. Raadpleeg de error log

Bij het troubleshooten van website-gerelateerde zaken is de error log een enorm belangrijke bron van informatie. In DirectAdmin, de technische beheeromgeving van je hostingpakket, kom je bij je error log via Your AccountSite Summary / Statistics / LogsFull Error Log. Je kunt ook de laatste 10 of 100 regels via diezelfde pagina openen.

Bij het bekijken van de error log zijn er in principe twee mogelijkheden. Je krijgt of een lege pagina of een hoop regels te zien. Als de log geen inhoud toont, dan betekent het niet dat er per definitie geen fouten binnen de website zitten. Een andere belangrijke bron van informatie is namelijk de debug-functie van WordPress zelf.

Laat de debug-functie in WordPress je helpen

Het kan het nodig zijn om een aanpassing te doen in je wp-config.php, omdat foutmeldingen worden onderdrukt en dus niet worden gelogd. Dit kan via een FTP-programma, maar ook vanuit DirectAdmin via de File Manager. Doorgaans zul je wp-config.php vinden in de /public_html/-map van je domeinnaam.

In je wp-config.php staat onder andere deze regel:

define( 'WP_DEBUG', false );

Wijzig dit naar het onderstaande:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Door WP_DEBUG naar ‘true’ te zetten, weet WordPress dat het debuggen is geactiveerd. De instelling WP_DEBUG_LOG zorgt er voor dat foutmeldingen in een error log worden bijgehouden. Dit gebeurt in het bestand debug.log in de map /wp-content/. Let op: dit doet WordPress enkel als je WP_DEBUG ook op ‘true’ hebt gezet.

Als WP_DEBUG op ‘true’ staat, dan worden standaard alle meldingen in de browser weergegeven. Dus tevens meldingen die niet fataal zijn. Bezoekers van je website kunnen ze dus ook te zien en dat wil je uiteraard voorkomen. Door WP_DEBUG_DISPLAY op ‘false’ te zetten, kun jij de errors wel in de log terugvinden en zien bezoekers ze niet.

4. Foutmeldingen in de error log ontcijferen

Of je WordPress laat helpen in het troubleshooten of niet, het wordt lastig oplossen als je niet weet waar je naar kijkt. De type foutmeldingen waar je op kunt letten, zijn parse en fatal errors. Hoe moet je beide interpreteren?

Parse errors begrijpen

Een parse error geeft aan dat er iets onverwachts werd aangetroffen in de code. Hoewel zo’n fout vaak wordt veroorzaakt door iets kleins kan het flinke gevolgen hebben voor de gehele website. Deze error wordt als volgt weergegeven in de debug.log van WordPress:

[Datum en tijdstip] PHP Parse error: syntax error, unexpected 'require' (T_REQUIRE) in /home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-content/plugins/plugin-map/codebestand.php on line 53

Je kunt de volgende zaken uit deze foutmelding halen:

  • er is sprake van een parse error (syntax error);
  • hetgeen dat onverwacht werd aangetroffen, is ‘require’;
  • deze onverwachte ‘require’ staat op regel 53 in het bestand codebestand.php, wat een PHP-bestand is van de plugin in /plugin-map/.

Je kunt die regel dus als volgt lezen:

[Datum en tijd] {Fout type} {wat ging er fout} {bestand waarin de fout zich voordeed} {welke regel}

Fatal errors begrijpen

Een fatal error geeft aan dat er iets flink mis is, zoals het proberen te gebruiken van een functie of class dat niet bestaat. Dat kan komen, doordat bijvoorbeeld de betreffende code per abuis is verwijderd of een typefout in de class-naam is geslopen. Hieronder vind je een voorbeeld van zo’n foutmelding:

[Datum en tijdstip] PHP Fatal error: Uncaught Error: Class 'MijnClassnaam' not found in /home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-content/plugins/plugin-map/codebestand.php:75 Stack trace: #0 
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-includes/class-wp-hook.php(286): custom_load_plugin('') #1 
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array) #2
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-includes/plugin.php(453): WP_Hook->do_action(Array) #3 
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-settings.php(327): do_action('plugins_loaded') #4 
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-config.php(101): require_once('/home/deb1234/dom...') #5
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-load.php(37): require_once('/home/deb1234/dom...') #6
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-admin/admin.php(31): require_o in
/home/deb1234/domains/mijndomeinnaam.nl/public_html/wp-content/plugins/plugin-map/codebestand.php on line 75

Als je niet gewend bent om error logs in te zien, dan kan zo’n lap tekst flink overweldigend zijn. Want wat staat er nou eigenlijk? De informatie die wordt gegeven, is eigenlijk hetzelfde als bij de parse error. De verschillen zijn:

  • het bestand waarin de fout zich voordeed (inclusief regelnummer) wordt dubbel vermeld;
  • middels een stack trace wordt er een uiteenzetting van plekken gegeven, waar op het moment dat het misging in werd gewerkt.

Je kunt deze foutmelding dus als volgt interpreteren:

[Datum en tijd] {Fout type} {wat ging er fout} {bestand waarin de fout zich voordeed:welke regel} {stack trace} {bestand waarin de fout zich voordeed} {welke regel}

Oorzaak gevonden! Wat nu?

Gaat het mis in een bestand van WordPress zelf? Dan kan het opnieuw uploaden van de standaard WordPress-bestanden (alles behalve de map /wp-content/) dit vaak oplossen. Enerzijds kan dit ontbrekende bestanden alsnog aanleveren, anderzijds worden aangepaste (core)bestanden hiermee hersteld.

Als het probleem zich voordoet in een plugin (of het thema), heeft het opnieuw uploaden van de standaard WordPress-bestanden niet veel zin. Hier zit het probleem immers niet in. Het inloggen op je dashboard en via daar de plugin deactiveren, gaat ook wat lastig als je website niet werkt.

Je kunt dan dus het best de mapnaam van de plugin via je FTP-programma of de File Manager in DirectAdmin hernoemen naar iets anders. Je kunt de map van bijvoorbeeld /plugin-naam/ naar /_plugin-naam/ hernoemen. De inhoud zal zo niet geladen kunnen worden, omdat de locatie van de bestanden van de plugin afwijken van toen deze werd geactiveerd.

WordPress debuggen: het hernoemen van een plugin-map.

Je zou nu de website en je dashboard van WordPress weer moeten kunnen bereiken. Als je naar de plugins-pagina in het dashboard gaat, dan zul je een melding krijgen dat de betreffende plugin niet gevonden kon worden en daarom is gedeactiveerd. Daarna kan de mapnaam weer hersteld worden, zonder dat dit verdere gevolgen heeft voor je website.

Als er een update beschikbaar is voor de betreffende plugin (of het thema), dan kan deze doorlopen worden. Zodra dat klaar is, heb je de mogelijkheid om het opnieuw te activeren en te bekijken of het nog problemen geeft.

5. Nergens foutmeldingen te zien?

Het kan voorkomen dat je geen foutmeldingen tegenkomt in de error log van DirectAdmin of WordPress en dat je website het toch niet doet. De kans is groot dat je dan meer informatie kunt vinden in de console van je browser. Om de error log van je browser voor een specifieke pagina in te zien, kun je in Google Chrome kiezen voor ‘Inspecteren’ in het menu van je rechtermuisknop.

Via deze ontwikkelaarstools krijg je toegang tot een hoop informatie (en testmogelijkheden) van de pagina. De snelste manier om te zien of er fouten in script-bestanden zijn, is om in dat nieuwe blok rechts bovenin te kijken. Een geel driehoekje staat voor waarschuwingen, een rood rondje staat voor fouten. Het gaat hierbij dus vooral om het rode rondje.

WordPress debuggen met behulp van ontwikkelaarstools.

Voor het bekijken van de foutmeldingen en waarschuwingen, klik je op ‘Console’ in het menu van dit deelscherm. De fout wordt op een rode regel weergegeven, met aan de rechterkant het bestand waar het fout ging en op welk regelnummer de fout werd geconstateerd. Als je de pointer van je muis op die bestandsnaam zet, krijg je de volledige URL naar dat bestand te zien. Dit maakt het herkennen van waar dit bestand onderdeel van is wat makkelijker.

Zit de fout in een bestand van WordPress zelf, dan kan het helpen om de standaard bestaanden van WordPress opnieuw naar de server te zetten. Zit de fout in een plugin of thema? Controleer dan of er toevallig een update beschikbaar van is. Het kan immers ook in bekende plugins voorkomen dat er een foutje in is geslopen die de ontwikkelaar ervan heeft opgelost met een nieuwe update.

6. Stap voor stap WordPress debuggen

Je kunt enorm veel informatie uit foutmeldingen halen. Echter, het ontbreken van foutmeldingen kan ook veelzeggend zijn. Mocht je uit de verschillende error logs geen bruikbare informatie kunnen halen, dan kan het daarom handig zijn om alles naar de standaard waarden te zetten. Dit wordt ook wel een vanilla-installatie genoemd.

Thema’s troubleshooten

Het aantal thema’s waar actief gebruik van wordt gemaakt, is hooguit twee (in het geval je een child theme gebruikt). We beginnen daarom daar.

  1. Gebruik je een child theme? Activeer het parent theme als hoofdthema en test opnieuw.
  2. Gebruik je een losstaand thema of maakte het parent theme geen verschil? Activeer een standaard WordPress-thema.

Plugins troubleshooten

Als je met een vanuit WordPress meegeleverd standaard thema ook geen verbetering merkt, dan zal een plugin (of een combinatie van plugins) de oorzaak zijn. Het vinden van die plugin doe je dan met de volgende stappen.

  1. Houd het standaard WordPress-thema actief en deactiveer alle plugins.
  2. Test de website.
    1. Werkt deze nog niet? Er gaat dan wellicht iets in de instellingen van je hostingpakket of de database niet goed. Mogelijk staat er nu wel wat bruikbaars in de error logs.
    2. Werkt de website nu wel goed? Mooi, dan kunnen we door!
  3. Ga naar ‘Recentelijk actief’ bij ‘Plugins’ in je WordPress-dashboard en activeer de bovenste plugin.
  4. Test de website opnieuw.
    1. Werkt de website niet meer? Bingo! Probleem-plugin gevonden.
    2. Werkt de website nog wel? Dan gaan we terug naar stap 3 voor de volgende plugin.

Soms is het opnieuw activeren van de probleem-plugin voldoende. Ook kan het zijn dat de website weer prima werkt, nadat alle plugins opnieuw zijn geactiveerd. In de gaten houden blijft dan uiteraard verstandig. Blijft een plugin problemen geven, dan kan een alternatief zoeken slim zijn.

7. Lukt het niet zelf? Schakel hulp in!

Of het nu gaat om je website of het onderzoeken waarom een stop in huis maar door blijft slaan, in beide gevallen is troubleshooten een kwestie van proberen en uitsluiten. En soms kun je het dan gewoon niet alleen oplossen. Want je bent handig, maar hulp van expert kan af en toe zeer verstandig zijn.

Zoals je een elektriciën raadpleegt bij doorgaande stoppen kun je bij websites overwegen om een webbouwer om hulp te vragen. Het ene CMS is de ander niet. In geval van WordPress kun je dus het beste op zoek naar iemand die daarin is gespecialiseerd.

Hoewel je de oorzaak wellicht niet hebt kunnen vinden, kun je met de opgedane kennis de webbouwer van belangrijke informatie voorzien. En dat zou er maar zo voor kunnen zorgen dat hij of zij voldoende heeft aan een korte blik om je daarna te kunnen voorzien van een passend advies.

8. Zelf gefixt? Tijd voor feest!

Heb je het probleem zelf kunnen achterhalen én oplossen? Maak dan gauw een backup van de website. Gaat er iets mis op een moment dat je geen tijd hebt om oorzaken uit te sluiten, dan heb je een herstelpunt tot je beschikking om op terug te kunnen vallen.

En daarna feest! Je hebt het immers opgelost en tegelijkertijd wat geleerd. Opgelucht achterover leunen met een kop koffie of thee is dan natuurlijk verdiend. Wil je ook aan de slag met WordPress en ben je op zoek naar webhosting? Neem gerust eens een kijkje bij onze pakketten!

Start met WordPress →

Deel Tweet +1 Deel