Tvarkingesnis WordPress klaidų gaudymas su Acorn: nuo WP_DEBUG iki Ignition

Kai dirbi su WordPress lokaliai, WP_DEBUG turėtų būti įjungtas praktiškai visada: taip greičiau pamatai notice, warning ir fatal klaidas, kurios kitu atveju tyliai sugadintų funkcionalumą arba „užsikrautų“ į produkciją. Problema ta, kad numatytas WordPress klaidų išvedimas į ekraną yra gana primityvus: gauni tekstą be konteksto, be tvarkingo stack trace, o kartais ir be aiškaus kelio iki vietos, kurią reikia taisyti.

Jei tavo projektas paremtas Roots ekosistema (Bedrock + Acorn), situaciją galima smarkiai pagerinti be papildomų „magijų“. Acorn (Roots framework, į WordPress atnešantis dalį Laravel patogumų) sugeba perimti WP_DEBUG klaidų atvaizdavimą ir parodyti jas žymiai suprantamiau.

Kas iš tikrųjų daro WP_DEBUG (ir kodėl to neužtenka)

WP_DEBUG – tai WordPress konstantos pagrindu įjungiamas debug režimas. Praktiškai tai reiškia, kad WordPress pradeda rodyti PHP pranešimus ir klaidas (priklausomai nuo konfigūracijos, pvz. WP_DEBUG_DISPLAY). Tai geriau nei nieko, ypač kuriant temas ir įskiepius, nes WordPress ekosistemoje vis dar apstu kodo, kuris generuoja notices ir kitus įspėjimus.

Tačiau numatytas išvedimas į naršyklę dažnai atrodo kaip „plika“ žinutė be ergonomikos: sunku greitai perskaityti, sunku atsirinkti, kur tikroji problema, o kur tiesiog triukšmas.

Acorn: geresnė WP_DEBUG patirtis be papildomų įskiepių

Acorn pagerina WP_DEBUG išvedimą tada, kai įjungti WP_DEBUG ir WP_DEBUG_DISPLAY. Vietoje to, kad pamatytum tik tekstinę klaidą, gauni aiškiau suformatuotą exception puslapį su stack trace ir kontekstu.

Pagal nutylėjimą Acorn naudoja Symfony exception handler’į (klaidų gaudyklę). Symfony ekosistemoje tai įprasta praktika, ir rezultatas WordPress’e tampa gerokai „žmogiškesnis“.

Ignition WordPress’e: kai nori Laravel lygio klaidų puslapio

Jei esi dirbęs su Laravel, greičiausiai pažįsti Ignition – tai Laravel numatytasis error page nuo Laravel v9. Roots Acorn v3 kontekste atsirado svarbus pokytis: Acorn turi routing palaikymą Laravel stiliumi, o tai reiškia, kad Ignition dabar gali veikti ir WordPress projektuose, kuriuose naudojamas Acorn.

Praktinis rezultatas – labai patogus klaidų ekranas su aiškiu stack trace, kontekstu ir geresne navigacija po klaidos priežastis. Jei tavo komanda maišo WordPress ir Laravel patirtis, Ignition tampa natūraliu pasirinkimu.

Kaip įsidiegti Ignition (tik dev aplinkai)

Ignition diegiamas per Composer kaip development priklausomybė (kad nebūtų diegiama į produkciją). Komandą vykdyk tame pačiame kataloge, kur įdiegtas Acorn:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

Kas su whoops? (aktualu, jei dar sėdi ant Acorn v2)

Iki Acorn v3 dažnai buvo rekomenduojama naudoti whoops (populiari PHP klaidų atvaizdavimo biblioteka). Jei projekte dar naudojamas Acorn v2, whoops vis dar gali suteikti geresnį rezultatą nei bazinis Symfony puslapis. Visgi Roots rekomenduoja judėti į Acorn v3, nes ten Ignition integracija tampa natūralesnė.

Jei nenaudoji Acorn: dvi praktiškos alternatyvos WordPress’e

Ne visi WordPress projektai turi Acorn – kartais tai klasikinė tema, kartais įskiepių kūrimas, kartais paveldėtas kodas. Tokiu atveju vis tiek galima susitvarkyti debug patirtį su gerai žinomais įrankiais:

• Query Monitor – vienas naudingiausių įrankių lokaliai: užklausos, hook’ai, HTTP užklausos, klaidos ir daug kitų diagnostikos duomenų.
• Debug Bar – lengvesnis variantas su pagrindine diagnostika ir debug informacija.

Santrauka: ką pasirinkti realiame projekte

1. Visada įjunk WP_DEBUG lokaliai – tai greičiausias būdas pamatyti triukšmą, kurį WordPress pasaulis generuoja kasdien.
2. Jei naudoji Acorn, gausi tvarkingesnį exception vaizdą automatiškai (su Symfony handler’iu).
3. Jei nori geriausios klaidų puslapio patirties ir tau artimas Laravel darbo stilius, Acorn v3 + Ignition yra labai stiprus derinys.
4. Jei Acorn nenaudoji, Query Monitor dažniausiai duoda didžiausią naudą per mažiausią laiką.