Debugging mai bun în WordPress cu WP_DEBUG + Acorn (Symfony, Ignition, Whoops)

În WordPress, primul pas când vrei să prinzi rapid notice-uri, warnings și erori fatale este să rulezi cu WP_DEBUG activ. Problema: output-ul standard e minimal și, în practică, te pune să scanezi un perete de text direct în pagină. Dacă lucrezi pe un stack modern cu Bedrock + Acorn, poți transforma complet experiența de debugging fără să schimbi modul în care scrii pluginuri/teme.

Mai jos trecem prin: cum arată output-ul default WP_DEBUG, ce aduce Acorn peste el (Symfony exception handler), cum obții pagina de erori Ignition (Spatie/Laravel) în WordPress și ce alternative ai dacă nu folosești Acorn.

WP_DEBUG: de ce merită să fie mereu ON în development

WP_DEBUG este modul de debug al WordPress, activat prin constanta WP_DEBUG din configurație. În local (și, în general, în medii de development), e bine să fie activ permanent ca să prinzi din timp problemele care altfel ajung în producție sub formă de bug-uri greu de reprodus.

Dacă folosești Bedrock (boilerplate modern pentru WordPress, cu Composer), WP_DEBUG este deja activat implicit în mediul de development, conform configurației din Bedrock.

Problema cu output-ul implicit WP_DEBUG

Când activezi WP_DEBUG, WordPress îți afișează erorile/notificările direct în HTML-ul paginii. E mai bine decât nimic, dar devine rapid greu de urmărit: ai puțin context, stack trace-ul nu e prezentat prietenos, iar debug-ul într-un proiect mai mare devine obositor.

Cum îți schimbă Acorn experiența de debugging

Acorn îmbunătățește output-ul de debug atunci când sunt active WP_DEBUG și WP_DEBUG_DISPLAY (adică atunci când erorile sunt afișate în pagină). În locul afișării brute, Acorn folosește, implicit, handler-ul de excepții din Symfony, care face mesajele și stack trace-ul mult mai lizibile.

1) Output-ul implicit Acorn (Symfony exception handler)

În setup-ul standard, Acorn se bazează pe Symfony pentru pagina de excepții. Câștigi imediat: structură mai clară, accent pe cauza erorii, stack trace mai ușor de parcurs.

2) Ignition în WordPress (pentru cine vine din Laravel)

Dacă ai lucrat cu Laravel, probabil ți-e familiar Ignition: pagina de erori introdusă ca default în Laravel (începând cu v9). Odată cu Acorn v3, suportul pentru routing în stil Laravel deschide ușa pentru Ignition și în proiectele WordPress care rulează pe Acorn.

Practic, obții o experiență de debugging foarte apropiată de cea din Laravel: prezentare modernă a excepțiilor, context mai bun și navigare mai comodă prin stack trace.

Instalarea Ignition (varianta recomandată în articolul Roots) se face ca dependență de development, cu Composer, din același director în care este instalat Acorn:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

3) Whoops: opțiunea clasică (mai ales pentru Acorn v2)

Înainte de Acorn v3, recomandarea comună în ecosistemul Roots era whoops (o librărie populară de error handling în PHP). Dacă ești încă pe Acorn v2, whoops rămâne o soluție care poate oferi o experiență mai plăcută decât pagina Symfony, deși recomandarea generală este migrarea la Acorn v3.

Dacă nu folosești Acorn: alternative utile în WordPress

Nu toate proiectele WordPress sunt pe Bedrock/Acorn, iar asta e perfect ok. Dacă vrei totuși un debugging mai bun decât ce oferă WP_DEBUG out of the box, există pluginuri care te ajută să investighezi ce se întâmplă în runtime.

• Query Monitor – foarte util în medii locale: interogări, hooks, erori PHP, request-uri etc.
• Debug Bar – o variantă clasică pentru a expune informații de debug în admin bar.

Concluzie: un workflow de debug mai aproape de „modern PHP”

WordPress îți dă un comutator simplu pentru debugging (WP_DEBUG), dar experiența standard rămâne rudimentară. Cu Acorn, erorile devin mai ușor de citit (Symfony) și, în setup-urile compatibile, poți ajunge la nivelul de ergonomie oferit de Ignition. Iar dacă Acorn nu e în stack-ul tău, Query Monitor și Debug Bar rămân două opțiuni solide pentru un mediu local sănătos.