Felsök WordPress-debuggningen med Acorn: från WP_DEBUG-kaos till läsbara fel

När man jobbar med WordPress lokalt är WP_DEBUG fortfarande den snabbaste vägen till att fånga upp notices, warnings och rena fel tidigt. Problemet är att WordPress standardbeteende ofta känns som 2008: en varning spottas ut rakt i markupen, layouten spricker och du får en stack trace som är mer frustrerande än hjälpsam.

Om du bygger med Roots-stacken (särskilt Bedrock + Acorn) går det att få en betydligt trevligare debug-upplevelse utan att ändra hur WordPress funkar i grunden. Poängen är enkel: behåll WP_DEBUG, men byt ut den mänskligt svårlästa felvisningen mot något som faktiskt hjälper dig åtgärda felet.

Vad WP_DEBUG gör – och varför standardutskriften är ett problem

WP_DEBUG är WordPress inbyggda debugläge. När det är aktivt får du fel och notices som annars kan döljas. Det är ovärderligt i utvecklingsmiljöer eftersom WordPress-ekosystemet (teman, plugins, mu-plugins) ofta råkar släppa igenom notices som du vill upptäcka direkt.

Men standardutskriften är brutal: meddelanden skrivs direkt på sidan. Det gör att HTML-renderingen påverkas, och du får ofta en blandning av fel, markup och ibland svårnavigerade spårningar. Det är bättre än ingenting – men långt ifrån optimalt när du vill felsöka snabbt.

Acorn som felhanterare: bättre läsbarhet utan att uppfinna hjulet

Acorn är Roots brygga som tar in delar av Laravel-ekosystemet i WordPress (t.ex. helpers och modernare struktur). I debug-sammanhang är det intressanta att Acorn kan förbättra hur exceptions presenteras när WP_DEBUG är på – mer specifikt när WP_DEBUG && WP_DEBUG_DISPLAY är aktiverat.

I praktiken betyder det att du går från ett spretigt felutskrift i HTML till en sammanhållen felvy med tydligare stack trace, fil-/rad-information och kontext.

Acorns standard: Symfony exception handler

Default i Acorn är att använda Symfonys exception handler. Du får en renare, mer strukturerad felvy som är lättare att skumma och förstå, särskilt när felet kommer från ett djupt call stack i WordPress eller ett plugin.

Ignition: Laravel-känsla i WordPress (via Acorn v3)

Om du jobbat i Laravel de senaste åren har du nästan garanterat sett Ignition – Laravels standardfelvy sedan v9. En stor grej med Acorn v3 är att den har stöd för routing à la Laravel, vilket också öppnar för Ignition på WordPress-sajter som kör Acorn.

Det här är i praktiken det mest “moderna” felsökningsläget du kan få i WordPress: en felvy som är byggd för att guida dig till rätt fil, rätt rad och rätt kontext, i stället för att bara visa att något gick sönder.

Installera Ignition (dev-beroende via Composer)

För att komma igång med Ignition i ett WordPress-projekt där Acorn redan är installerat kan du lägga till paketet som ett dev-beroende med Composer (dvs bara för utveckling):

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

whoops: alternativet för äldre Acorn-versioner

Innan Acorn v3 var rekommendationen ofta att använda whoops för en bättre felvy än standardläget. whoops ger en mer utvecklarvänlig presentation än WordPress standardutskrift och kan fortfarande vara relevant om du sitter kvar på Acorn v2.

Bedrock: WP_DEBUG är ofta redan rätt inställt lokalt

Kör du Bedrock (Roots moderna WordPress-boilerplate med Composer) är debug ofta enklare att få “rätt” från början. I Bedrocks utvecklingsmiljö är WP_DEBUG aktiverat som standard, vilket gör att du slipper den klassiska situationen där ett team råkar utveckla vidare med debug avslaget.

Om du inte kör Acorn: två plugins som förbättrar felsökning

Allt är inte Bedrock/Acorn, och ibland måste man felsöka i en mer traditionell WordPress-installation. Då finns det plugins som kan göra din lokala debugmiljö vassare utan att du behöver bygga om projektet.

• Query Monitor – i praktiken standardverktyget lokalt för att inspektera queries, hooks, HTTP-anrop, PHP-fel m.m.
• Debug Bar – en enklare debugpanel som kan ge snabb överblick i admin

Praktisk tumregel: aktivera debug, men gör den läsbar

För lokal utveckling är det sällan diskussion om WP_DEBUG ska vara på – det ska den. Skillnaden mellan en frustrerande och en effektiv felsökningssession ligger oftast i hur felen presenteras och hur snabbt du kan gå från symptom till faktisk kodrad.

Med Acorn får du en modern felhantering ovanpå WordPress, och med Ignition får du en exception-sida som många redan är vana vid från Laravel. Resultatet är mindre tid på att tolka brus, och mer tid på att fixa problemet.