Als je je weg naar dit artikel hebt gevonden, neem ik aan dat je een fout bent tegengekomen op je WordPress website. Of dat je een persoon bent die regelmatig onderhoud pleegt en verwacht een bug tegen te komen. Hoe dan ook, ik wil je er eerst aan herinneren dat het schrijven van code en het schrijven van bugs hand in hand gaan. Zelfs de beste ontwikkelaars maken fouten. Ik heb deze gids voor WordPress debug mode geschreven, zodat jij niet in paniek hoeft te raken door deze fouten. Dit is een zeer nuttig instrument voor het ontdekken en begrijpen van fouten in WordPress. 

De eerste stap bij het debuggen van je code 

Leun achterover in je stoel, haal een paar keer diep adem en adem uit, en realiseer je dat alle ontwikkelaars wel eens buggy code hebben geschreven. Elke keer dat je buggy code schrijft, leer je iets – en als je iets leert, zul je je vaardigheden blijven ontwikkelen en verbeteren. 

Hoewel het kan voelen alsof een bug er alleen is om je gek te maken, is dat gelukkig relatief onwaarschijnlijk 😉 Het goede is: tenzij je te maken hebt met de allernieuwste technologie, is de kans groot dat iemand anders al tegen dezelfde bug is aangelopen. 

Wat is debugging? 

Als je niet bekend bent met de term debugging, dan zit het letterlijk in de term verstopt: de – bugging. In computertaal wordt een fout in je code een bug genoemd. Je code debuggen betekent dus: fouten uit je code halen. Hoewel mensen graag aannemen dat bugs worden veroorzaakt door hun eigen personeel of slecht doordachte software-updates, is de waarheid dat veel bugs je eigen handschrift dragen – en het is het beste om er vroeg mee aan de slag te gaan.

Waarom PHP debugging ingewikkelder lijkt dan JavaScript debuggen

Misschien ben je gewend om in een andere taal te debuggen, bijvoorbeeld JavaScript. Een beetje verwarrend is dat JavaScript pas wordt uitgevoerd nadat je website is gerenderd – dit is althans de standaard op het web en de reden waarom je je .js-bestand aan het eind van het HTML-document invoegt. Dit betekent dat je website nog steeds kan worden weergegeven, zelfs als er JavaScript-fouten zijn. Als je dit niet opmerkt of je console-log niet controleert, weet je misschien niet eens dat er een fout is opgetreden. 

PHP is echter een serverzijdige taal en wordt gebruikt om je website te bouwen (hoewel het veel meer kan dan dat). Dus als er een fout in je PHP-code zit, kan het zijn dat je website niet laadt en dat bezoekers geen inhoud te zien krijgen. PHP-fouten vallen dus meestal meer op. 

Debuggen in WordPress met WP-Debug 

Wat is de WordPress debug modus?

Als de WP debug modus (soms ook wp-debugger of wp-debug genoemd) is geactiveerd, laat het de fouten, hints en waarschuwingen zien die door het WordPress systeem worden gerapporteerd. Standaard is de wp-debugger uitgeschakeld. De PHP-constante wp_debug is de globale variabele die de toestand van de WordPress debugmodus aangeeft via een Boolean, d.w.z. of hij aan of uit staat. 

Waarom zou je de debugmodus WordPress gebruiken?

Omdat WordPress een paar verschillende kerncomponenten gebruikt: 

Frontend – HTML / CSS

Backend – PHP / Database

Plugins – PHP-toepassingen die door derden gemaakt zijn

Het kan dus vrij moeilijk zijn om te achterhalen wat de oorzaak is van een probleem op je website. De wp-debugger is een tool waarmee je de fouten kunt bekijken of loggen. 

Voordat je begint met debuggen, maak een back-up! 

Er is een oud gezegde: "Voorkomen is beter dan genezen". Dit betekent dat het het beste is om een probleem niet in de eerste plaats te laten ontstaan. Voor jou betekent dit: beveilig je gegevens!

Een 30-minuten durende onderhoudsklus kan snel veranderen in een 5 uur durende nachtmerrie, alleen omdat er geen backup gemaakt is voordat iemand met de interne bestanden geknoeid heeft.

Gelukkig, als je je website bij Raidboxes host, wordt de back-up automatisch gedaan! Ga gewoon naar je Dashboard, klik op het tabblad "Back-ups" en bekijk al je dagelijkse back-ups. 

Als je wijzigingen wilt aanbrengen en een handmatige back-up moet maken, klik dan op de knop "Handmatige back-up maken" en geef de back-up een naam. Tip: Kies een naam die logisch is, zodat je de back-up later kunt herkennen. Nu kun je zoveel met je website spelen als je wilt! Als er iets misgaat, zet je gewoon je back-up terug. 

Schakel de debugmodus van WordPress in bij Raidboxes

In je Raidboxes Dashboard kun je de wp-debugger in de instellingen van je Box met één klik aanzetten: 

Als je na het activeren van de WP Debug Mode klikt op WordPress Debug Log kun je in het Live Log zien welke fouten worden uitgegeven door je WordPress website. Je kunt het debug log zelf bereiken via de instellingen in het WP Debug item (zie screenshot) of via het BOX overzicht. Je kunt ook toegang krijgen tot de WP Debug Log bestanden via FTP: de logbestanden worden opgeslagen onder /wp-content/ in het bestand debug.log.

Je kunt meer informatie vinden over de foutenanalyse van je WordPress website bij Raidboxes in ons helpcentrum.

In de volgende sectie leggen we uit hoe je de WP Debug modus kunt inschakelen via wp-config.php als je lokaal ontwikkelt.

Activeer WordPress Debug lokaal 

In je lokale ontwikkeling kun je wp-debug inschakelen door het bewerken van het wp-config.php bestand in de root van je WordPress map en door de volgende code toe te voegen: 

// Dies aktiviert das Debugging.
define( 'WP_DEBUG', true );

Je kunt ook ontdekken dat deze aanwijzing al is toegevoegd, maar dat de waarde false is. Als dat het geval is, zet het dan op true. 

// Dies deaktiviert das Debugging.
define( 'WP_DEBUG', false );

Op dit punt wil ik nogmaals benadrukken hoe belangrijk het is om een back-up te hebben. Nu is een goed moment om dit nog eens te controleren.  

WordPress Debug modus is nu actief – en nu?

Nu de wp-debugger geactiveerd is, worden fouten direct in het browservenster getoond (als WP_DEBUG_DISPLAY op true is gezet) – dit is zowel een vloek als een zegen. Aan de ene kant kun je fouten zien, maar aan de andere kant kunnen alle gebruikers van je website ze zien, wat niet ideaal is. Om je een voorbeeld te geven, heb ik een kleine onbekende functie toegevoegd aan de voettekst van het standaard WordPress theme "Twenty Twenty-One". 

Voor het activeren van wp-debug: 

Na het activeren van wp-debug: 

Je wilt waarschijnlijk niet dat bezoekers van je website dit zien, of wel? De foutmelding verstoort niet alleen het design, maar kan zelfs gevoelige informatie onthullen. Voordat ik wat veranderingen in de uitvoer aangebracht had, werd mijn gebruikersnaam bijvoorbeeld weergegeven en met deze informatie zou elke hacker een aanval kunnen starten. 

Hoe kun je de WordPress debug modus activeren en voorkomen dat fouten worden weergegeven in je HTML code?

Gelukkig is er een oplossing voor dit probleem bij WordPress. Voeg de volgende code toe aan je wp-config.php: 

define( 'WP_DEBUG_DISPLAY', false );

Dit voorkomt dat er fouten in de HTML-code van je website verschijnen en bespaart je gebruikers de nachtmerrie die je misschien hebt veroorzaakt. Het laatste stukje van de puzzel is hoe je kunt controleren op fouten zonder ze te publiceren. Welkom bij error logging! 

Activeer foutregistratie in WordPress 

In het wp-config.php bestand, moet je de error logging van WordPress aanzetten. Dit zal een .log bestand creëren met de logs en details van de fouten die op je website zijn opgetreden. 

define( 'WP_DEBUG_LOG', true );

Je vindt het logbestand meestal in de wp-content map van je WordPress website, tenzij je een geldig bestandspad hebt voor dit logbestand zoals hieronder aangegeven: 

define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );

Maar mijn foutenlog werd geschreven in de WordPress root directory. Dus als je je foutenlogboek niet in de wp-content map kunt vinden, moet je ergens anders zoeken:  

Een foutenlogboek bekijken

Foutlogs geven vrij duidelijke aanwijzingen over wat er fout ging. Maar alleen omdat iets duidelijk is, wil dat nog niet zeggen dat je het begrijpt, dus laten we het verder bekijken. 

1. Tijdstip van de fout: [12-Apr-2021 20:32:47 UTC]
2. Type fout: PHP Fatal Error
3. Oorzaak van de fout: Uncaught Error: Call to undefined function writeMsg() in
4. Waar de fout is opgetreden: /home/XXXXXXX/DEVELOPMENT/wp/wp-content/themes/twentytwentyone/footer.php:73

Voor het geval je je afvraagt wat de fout is die ik erin heb gezet, ik heb een onjuiste methode genaamd writeMsg() gedefinieerd in het bestand footer.php dat een fout veroorzaakt. 

Is het WordPress foutenlogboek te groot?

Foutlogs kunnen na verloop van tijd groeien als ze niet worden gecontroleerd. Vergeet niet dat niet alleen fouten, maar ook waarschuwingen en hints worden gelogd. Wanneer er nieuwe versies van PHP zijn, kunnen bepaalde methoden verouderd raken of zelfs plugins niet langer worden ondersteund. In dat geval zullen meer fouten worden gegenereerd. 

Normaal zou een foutenlog slechts een paar kB groot moeten zijn, maar zelfs dan is het nog vervelend om te doorzoeken. In het ergste geval worden de fouten gelogd in een bestand dat al meerdere MB groot is en duizenden regels tekst bevat. Dit is niet alleen verwarrender, maar leidt ook tot tragere reactietijden van het logbestand en kan het zoeken naar fouten enorm vertragen door de wachttijden bij het laden van het logbestand. Wat kun je dan doen? 

Download het bestand voor de archivering en verwijder deze dan! 

Als de WordPress error logs geactiveerd zijn in wp-config.php en er geen error.log bestand gevonden kan worden, dan maakt WordPress een heel nieuw bestand aan en vult het met de huidige fouten.

Conclusie

Het debuggen van code maakt de ontwikkeling zowel uitdagend als lonend. Omdat fouten jou dwingen om je kennis uit te breiden, een positieve instelling te ontwikkelen en buiten de gebaande paden te denken. Als je vragen hebt of problemen met het debuggen van je WordPress website, voel je vrij om een reactie achter te laten of neem contact met ons op in de support chat. Veel plezier met debuggen!