WordPress debuggen zonder hoofdpijn: WP_DEBUG slimmer maken met Acorn

Als je regelmatig aan WordPress-thema’s of plugins sleutelt, ken je het: je zet WP_DEBUG aan, krijgt een onleesbare notice-bingo bovenin je pagina, en je bent alsnog meer tijd kwijt aan zoeken dan aan fixen. WP_DEBUG is essentieel, maar de presentatie van fouten is in core behoorlijk basic.

In deze post laat ik zien wat er precies mis is met de standaard WP_DEBUG-output, en waarom Acorn (Roots) dat op een nette, moderne manier oplost. Werk je met Bedrock (WordPress-boilerplate met Composer)? Dan is dit extra interessant, omdat debuggen daar sowieso al wat strakker is ingericht.

WP_DEBUG in het kort (en waarom je het lokaal altijd aan wilt hebben)

WordPress heeft een ingebouwde debugmodus die je activeert via de WP_DEBUG constant in je configuratie. In lokale development-omgevingen wil je WP_DEBUG eigenlijk altijd aan hebben: je vangt sneller notices, warnings en echte errors, en je voorkomt dat je rommelige edge-cases per ongeluk doorschuift naar staging of productie.

Gebruik je Bedrock (de moderne WordPress setup met Composer)? Dan staat WP_DEBUG volgens de Bedrock-configuratie standaard aan in development-omgevingen. Dat is een fijne default: je hoeft minder vaak te onthouden dat je debug nog uit stond.

Waarom de standaard WP_DEBUG-output vaak niet genoeg is

De standaard output van WP_DEBUG is functioneel, maar niet prettig: foutmeldingen en notices worden direct in de HTML gerenderd. Je krijgt weinig context, het is visueel rommelig, en bij exceptions mist vaak de developer-ervaring die je uit moderne frameworks gewend bent.

Het resultaat: je ziet dat er iets misgaat, maar je workflow blijft: kopiëren, terugzoeken, stacktrace ontwarren, en hopen dat je snel bij de juiste regel uitkomt.

Acorn: WP_DEBUG-output die wél prettig leest

Acorn is het PHP framework van Roots dat Laravel-achtige features naar WordPress brengt. Denk aan helpers, service containers en een modernere developer experience. Een van de meest tastbare verbeteringen: foutafhandeling (error handling) die je debugoutput drastisch leesbaarder maakt.

Belangrijk detail: Acorn verbetert de output wanneer WP_DEBUG én WP_DEBUG_DISPLAY aan staan. Daarna neemt Acorn de presentatie van exceptions over, zodat je in plaats van “platte” meldingen een nette errorpagina krijgt met stacktrace en context.

Acorn standaard: Symfony exception handler

Zonder extra packages gebruikt Acorn standaard de Symfony exception handler. Die geeft je al een veel beter leesbare exception-pagina dan WordPress core. Vooral bij fatals en uncaught exceptions scheelt dit enorm in zoektijd.

Acorn + Ignition: de Laravel-ervaring, maar dan in WordPress

Als je uit de Laravel-hoek komt, is Ignition waarschijnlijk bekend: de errorpagina die sinds Laravel v9 de standaard is. Met Acorn v3 is Ignition ook beschikbaar in WordPress-projecten die Acorn gebruiken. Dat komt doordat Acorn v3 ondersteuning toevoegt voor routing zoals in Laravel, en daarmee ook Ignition kan integreren.

In de praktijk betekent dit: een errorpagina die gemaakt is om snel te debuggen, met een heldere stacktrace en een prettige UI. Roots raadt Ignition aan voor de beste error handling-ervaring in WordPress met Acorn.

Ignition gebruik je als dev dependency. Vanuit dezelfde directory waar Acorn geïnstalleerd is, installeer je het met Composer:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

Acorn + Whoops (met name relevant voor Acorn v2)

Voor Acorn v3 is Ignition de logische keuze. In de periode vóór v3 werd vaak Whoops gebruikt (een PHP error handler die veel projecten inzetten voor nette foutpagina’s). Zit je nog op Acorn v2, dan kun je met Whoops nog steeds een duidelijk betere ervaring krijgen dan de standaard Symfony errorpagina.

Geen Acorn? Dit zijn sterke alternatieven voor lokaal debuggen

Niet elk WordPress-project draait op Acorn/Bedrock, en soms heb je gewoon een klassieke setup. Ook dan kun je je debug-ervaring upgraden met plugins die inzicht geven in wat er onder de motorkap gebeurt.

• Query Monitor – voor veel developers een must-have lokaal: database queries, hooks, HTTP calls, PHP errors en nog veel meer inzichtelijk.
• Debug Bar – een eenvoudiger alternatief om debugging-informatie in je adminbar te tonen.

Samenvatting: wat levert dit je concreet op?

• WP_DEBUG blijft de basis: zet het lokaal standaard aan.
• De standaard WordPress-output is bruikbaar, maar niet gemaakt voor snelle diagnose.
• Acorn verbetert de weergave van exceptions zodra WP_DEBUG en WP_DEBUG_DISPLAY actief zijn.
• Met Acorn v3 + Ignition krijg je een moderne, Laravel-achtige errorpagina in WordPress.
• Zonder Acorn zijn Query Monitor en Debug Bar prima opties om je debug-workflow te verbeteren.