--- title: "Felsök WordPress-debuggningen med Acorn: från WP_DEBUG-kaos till läsbara fel" url: "https://helloblog.io/sv/felsok-wordpress-debuggningen-med-acorn/" date: "2023-02-14" modified: "2026-01-20" author: "Maja Lindberg" language: "sv_SE" categories: ["WordPress"] tags: ["Acorn", "Bedrock", "Composer", "WordPress", "WP_DEBUG"] featured_image: "https://helloblog.io/app/uploads/sites/13/2026/01/featured-3-1024x572.png" excerpt: "WP_DEBUG gör jobbet – men standardutskriften i WordPress gör det ofta onödigt svårt att förstå vad som faktiskt gick fel. Med Acorn kan du få en modern felvy (Symfony, Ignition eller whoops) som känns mer som ett samtida PHP-projekt." --- # 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. ![Standardutskrift från WP_DEBUG där notices och fel visas direkt på sidan](https://helloblog.io/app/uploads/sites/13/2026/01/wp_debug-default-scaled.png) *WordPress standardvisning av WP_DEBUG: fel direkt i outputen. — *Forrás: Roots.io** ## 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. ![Acorns standardfelvy via Symfony exception handler med tydligare stack trace](https://helloblog.io/app/uploads/sites/13/2026/01/wp_debug-acorn-symfony-scaled.png) *Acorn förbättrar WP_DEBUG med Symfonys exception handler som standard. — *Forrás: Roots.io** ### 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. ![Acorns WP_DEBUG-felvy med Ignition, liknande Laravels moderna error page](https://helloblog.io/app/uploads/sites/13/2026/01/wp_debug-acorn-ignition-scaled.png) *Ignition ger en Laravel-lik felvy även i WordPress när du använder Acorn v3. — *Forrás: Roots.io** #### 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 ``` #### Var kör jag kommandot? Kör det i samma katalog som Acorn är installerat (där din `composer.json` för projektet ligger). ### 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. ![Acorns WP_DEBUG-felvy med whoops som ger en mer utvecklarvänlig stack trace](https://helloblog.io/app/uploads/sites/13/2026/01/wp_debug-acorn-whoops-scaled.png) *whoops var länge det smidigaste sättet att få en bättre debugvy i Acorn-projekt. — *Forrás: Roots.io** #### Om du är på Acorn v2 Enligt Roots rekommendationer är Acorn v3 vägen framåt, men whoops kan fortfarande höja debug-upplevelsen om du inte kan uppgradera direkt. ## 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. ## Referenser / Källor - [Better WordPress Debugging with Acorn](https://roots.io/better-wordpress-debugging-with-acorn/) - [Bedrock](https://roots.io/bedrock/) - [Query Monitor](https://querymonitor.com/) - [Debug Bar](https://wordpress.org/plugins/debug-bar/)