WordPress debugiranje brez trpljenja: kako ti Acorn polepša WP_DEBUG

Če razvijaš WordPress teme ali vtičnike, je WP_DEBUG praktično osnovna higiena. Problem je, da WordPress privzeto napake in notice-e pogosto “zabije” kar na ekran v obliki surovega izpisa, ki je sicer boljši kot nič, a daleč od izkušnje, ki smo je vajeni v modernih PHP ogrodjih. V praksi to pomeni več časa za brskanje po stack traceu in manj časa za dejansko reševanje problema.

V tem članku pokažem, kaj se v debugiranju spremeni, ko imaš v projektu Roots Acorn (Laravelov ekosistem znotraj WordPressa), in katere alternative imaš, če Acorna ne uporabljaš.

WP_DEBUG: obvezno v lokalnem razvoju (in zakaj je privzeti izpis tečen)

WP_DEBUG je WordPressov debug način, ki ga vklopiš z nastavitvijo konstante WP_DEBUG v konfiguraciji. V lokalnih okoljih bi moral biti vedno vključen, ker te hitro opozori na notice-e, deprecated klice, warninge in exceptione, ki jih sicer spregledaš — dokler ne eksplodirajo na produkciji.

Težava je v tem, da je privzeti output pogosto samo blok besedila na strani. Videti je surovo, brez konteksta in brez ergonomije, ki bi ti pomagala v par sekundah priti do prave vrstice kode.

Kaj Acorn naredi drugače pri WP_DEBUG

Roots Acorn je plast, ki v WordPress projekt pripelje velik del Laravel izkušnje (container, service providerji, helperji, routing ipd.). Ena zelo praktična posledica: ko sta omogočena WP_DEBUG in WP_DEBUG_DISPLAY, Acorn zamenja privzeto izpisovanje napak z bolj razumnim exception handlerjem.

1) Privzeto v Acornu: Symfony exception handler

Out of the box Acorn uporabi Symfonyjev exception handler. V praksi to pomeni bistveno bolj berljiv prikaz exceptionov in stack tracea, z jasnejšim fokusom na to, kje je problem nastal.

2) Najboljša izkušnja: Ignition (Laravel-style error page)

Če prihajaš iz Laravel sveta, ti je Ignition verjetno domač: to je error page, ki je v Laravelu privzeta od v9 dalje. Z Acorn v3 (po navedbah projekta) je dodana podpora za Laravel routing, kar odpre vrata tudi Ignitionu v WordPress projektih, ki uporabljajo Acorn.

Rezultat je zelo “framework” izkušnja: pregledna napaka, uporaben stack trace in bistveno manj ugibanja, kaj se je zgodilo.

Namestitev Ignitiona je preprosta, ker gre za Composer paket. Za razvojno odvisnost ga dodaš v isti direktorij, kjer je nameščen Acorn:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

3) Starejši pristop (Acorn v2): whoops

Pred Acorn v3 je bil pogosto priporočen whoops (priljubljen PHP error handler). Če si še na Acorn v2, lahko z whoops še vedno dobiš bolj prijazen prikaz napak kot s privzetim WordPress outputom. Vseeno je po priporočilih projekta bolj smiselno nadgraditi na Acorn v3, kjer je Ignition podprt bolj nativno.

Če Acorna nimaš: dve vtičniški klasiki za boljši debugging

Ni vsak WordPress projekt postavljen na Bedrock + Acorn (čeprav je to zelo udobna kombinacija, sploh če ti je všeč bolj moderna PHP struktura in Laravel helperji). Če delaš na bolj klasičnem WordPress setupu, lahko še vedno bistveno izboljšaš debugging s preverjenimi vtičniki.

• Query Monitor – praktično obvezna oprema za lokalno okolje: pomaga pri vpogledih v queryje, hooks, HTTP klice, napake in še marsikaj.
• Debug Bar – lažja alternativa, ki doda debug panel v admin toolbar in olajša osnovno diagnostiko.

Praktičen zaključek: kaj se splača nastaviti

Za hitrejše reševanje napak v WordPressu sta ključni dve stvari: WP_DEBUG mora biti v lokalnem razvoju vedno vklopljen, izpis napak pa mora biti dovolj dober, da ti ne krade časa. Acorn tu naredi veliko razliko že s privzetim Symfony handlerjem, še bolj pa z Ignitionom, ki WordPress debug izkušnjo približa Laravelu.

Če Acorna ne uporabljaš, je najmanj, kar se splača narediti, namestitev Query Monitorja, ker ti da zelo konkreten vpogled v to, kaj se dogaja v runtime-u. Pri kompleksnejših projektih je to pogosto razlika med “brskanjem na slepo” in sistematičnim debugiranjem.