Lepší debugging ve WordPressu s Acornem: čitelnější chyby než holé WP_DEBUG

WordPress má pro vývojářské prostředí jednoduchý přepínač pro ladění: konstanta WP_DEBUG. Jakmile ji zapneš, začneš okamžitě chytat notice, warningy a výjimky, které by jinak tiše proplouvaly produkcí. Pro lokální vývoj (a obecně pro dev prostředí) by WP_DEBUG měl být prakticky vždy zapnutý — zejména pokud děláš pluginy nebo šablony a chceš vidět problémy co nejdřív.

Problém je, že defaultní výstup WordPressu není zrovna ergonomický. Chyby se typicky vykreslí přímo do HTML stránky a výsledkem bývá blok textu bez kontextu, bez pěkného stack trace a bez nástrojů, které jsme zvyklí používat jinde.

Co přesně dělá WordPress v režimu WP_DEBUG

Když je WP_DEBUG aktivní, WordPress začne hlásit PHP notice a další chyby. V kombinaci s WP_DEBUG_DISPLAY se tyto informace obvykle vypíšou přímo na obrazovku. Je to pořád lepší než nic — v ekosystému WordPressu je až překvapivě běžné, že i rozšířené pluginy a šablony generují notice, které pak komplikují vývoj, testování i nasazení.

Bedrock to má v devu typicky vyřešené už dopředu

Pokud stavíš projekty na Bedrocku (moderní WordPress boilerplate postavený na Composeru), WP_DEBUG bývá v development prostředí zapnutý už v základu. Bedrock to řeší přes environment konfigurace, takže se nemusíš bát, že si omylem přeneseš debug nastavení do produkce.

Kde Acorn posouvá WP_DEBUG o úroveň výš

Acorn je runtime a sada integrací, která do WordPressu přináší část pohodlí z Laravel světa (například helpery a modernější vývojářský zážitek). Jedna z praktických věcí: když máš zapnuté WP_DEBUG a zároveň WP_DEBUG_DISPLAY, Acorn umí výrazně vylepšit podobu a použitelnost chybových stránek.

Výchozí chybová stránka v Acornu: Symfony exception handler

V základní konfiguraci Acorn používá handler ze Symfony. V praxi to znamená čitelnější výpis výjimek, lepší práci se stack trace a celkově strukturovanější zobrazení problému než holý WordPress výpis.

Ignition: Laravel-style error page i ve WordPressu (Acorn v3+)

Pokud máš zkušenost s Laravelem, pravděpodobně znáš Ignition — výchozí error page v Laravelu (od Laravel v9). S Acornem v3 přišla podpora routingu ve stylu Laravelu, a tím pádem i možnost používat Ignition přímo ve WordPress projektu běžícím na Acornu. Výsledkem je výrazně lepší ladicí workflow: přehledné rozhraní, kontext k chybě a rychlejší orientace v tom, co se stalo.

Ignition se instaluje jako dev závislost přes Composer z adresáře, kde je nainstalovaný Acorn:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

Whoops: historická volba pro Acorn v2

Dřív (před Acorn v3) se pro lepší chybové stránky často doporučoval balíček whoops. Pokud jsi stále na Acorn v2, whoops je pořád cesta, jak se dostat k přívětivějšímu zobrazení chyb než přes základní Symfony stránku. Současně ale dává smysl zvážit upgrade na Acorn v3, protože Ignition je v tomhle ohledu velmi příjemný standard.

Nejedeš na Acornu? I tak se dá WP debugging zpříjemnit

Acorn není jediná možnost, jak zlepšit ladění ve WordPressu. Pokud stavíš klasický WordPress bez Acornu, existují pluginy, které ti pomůžou s diagnostikou a viditelností problémů v běhu aplikace — typicky nad rámec toho, co poskytne samotné WP_DEBUG.

• Query Monitor – velmi užitečný nástroj do lokálního prostředí (dotazy do DB, hooky, HTTP requesty, chyby a další diagnostika).
• Debug Bar – jednodušší alternativa pro základní debug panely.

Shrnutí: co si z toho odnést

1. WP_DEBUG v dev prostředí zapínej pravidelně – notice a chyby chceš vidět hned, ne až po nasazení.
2. Defaultní výstup WordPressu je funkční, ale málo čitelný a často tě brzdí.
3. Acorn dokáže chybové stránky výrazně zpřehlednit (minimálně přes Symfony handler).
4. Na Acorn v3 dává velký smysl Ignition: composer require spatie/laravel-ignition --dev.
5. Mimo Acorn se vyplatí sáhnout po Query Monitoru nebo Debug Baru pro lepší diagnostiku běhu WordPressu.