Het overkomt ons allemaal; er is een probleem of fout met onze site, en we moeten gaan troubleshooten om erachter te komen wat het probleem veroorzaakt en hoe het op te lossen.

WordPress heeft een ingebouwde debugmodus om je te helpen opsporen wat er aan de hand is door alle PHP fouten, meldingen en waarschuwingen weer te geven. Er zijn ook extra debugopties die nuttig kunnen zijn bij het onderzoeken van specifieke soorten problemen.

Zodra je de bron van een probleem hebt geïdentificeerd, kun je de details melden aan de plugin- of themaontwikkelaar of de ontwikkelaar van je website. Als er geen onmiddellijke oplossing beschikbaar is, moet je de plugin of het thema mogelijk deactiveren totdat het kan worden opgelost.

WP_DEBUG inschakelen

Om WP_DEBUG in te schakelen, log je in op MyKinsta, en selecteer de site en omgeving waarop je het wilt inschakelen.

Ga naar het tabblad Tools en klik op de knop Inschakelen onder WordPress debugging.

WordPress debugging inschakelen in MyKinsta.
WordPress debugging inschakelen in MyKinsta.

Dit zorgt ervoor dat WordPress alle PHP fouten, melden en waarschuwingen op je site laat zien. Deze worden aan elke bezoeker getoond en kunnen zowel op de frontend van je site als in het WordPress dashboard worden weergegeven.

Als je nu het wp-config.php bestand van je site bekijkt, zie je dat de volgende regel net vóór deze regel is toegevoegd: /* That's all, stop editing! Happy blogging. */ regel:

if (! defined('WP_DEBUG') ) { define( 'WP_DEBUG', true ); } // line added by the MyKinsta

Het instellen van WP_DEBUG op true maakt debuggen in WordPress mogelijk.

WB_DEBUG uitbreiden

Er zijn een paar constanten die dienen als handige extra’s voor WP_DEBUG door het inschakelen van extra debugopties.

Debuglog

Als je fouten in een logbestand wilt opslaan, kun je WP_DEBUG_LOG inschakelen door je wp-config.php bestand te bewerken en de volgende regel toe te voegen na de regel die WP_DEBUG inschakelt:

define( 'WP_DEBUG_LOG', true );

Standaard wordt dit logbestand opgeslagen in: wp-content/debug.log op de server. Als je wilt, kun je het pad en de bestandsnaam aanpassen. In dit voorbeeld slaan we het logbestand op in de tmp directory en noemen we het bestand wp-errors.log:

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

Script debug

Het inschakelen van SCRIPT_DEBUG dwingt WordPress om de dev-versies van core CSS- en JavaScript bestanden te gebruiken in plaats van de geminificeerde versies die het meestal laadt:

define( 'SCRIPT_DEBUG', true );

Dit kan handig zijn bij het oplossen van JavaScript- of CSS problemen en als je vermoedt dat er sprake is van een conflict of ander probleem met core JavaScript- of CSS bestanden.

Debuggen van databasequery’s

Als je databasequery’s in een matrix wil opslaan, schakel dan SAVEQUERIES in:

define( 'SAVEQUERIES', true );

Dit zal elke query opslaan met hoe lang elke query duurde om uit te voeren en welke functie de query callde. De array kan worden geopend of weergegeven met de globale $wpdb->-queryies.

Andere debuggingtools en resources

Query Monitor plugin

De Query Monitor plugin is een gratis plugin die met name handig is voor het debuggen van specifieke gebieden in WordPress. Het kan je helpen trage databasequery’s, Ajax calls, REST API verzoeken en nog veel meer op te sporen. Voor meer informatie hebben we een blogpost over het gebruik van de Query Monitor plugin.

Kinsta APM

Kinsta’s APM tool helpt je met het identificeren van PHP performance-knelpunten op je WordPress site, zonder dat je je hiervoor hoeft aan te melden bij een externe monitoringsdienst als New Relic.

New Relic

New Relic is een monitoringtool die je gedetailleerde prestatiestatistieken op een gedetailleerd niveau geeft.

Serverlogs

Logbestanden zijn beschikbaar in MyKinsta en kunnen ook worden gedownload via SFTP. Deze bestanden kunnen nuttig zijn bij het oplossen van fouten of het opsporen van andere problemen op je site.