По-добър WordPress debugging с Acorn: WP_DEBUG, Symfony, Ignition и реално четими грешки

В WordPress дебъгването традиционно започва и свършва с WP_DEBUG. Това е напълно окей като минимум — особено ако правиш теми и плъгини и искаш да хващаш notices и warnings навреме. Проблемът е, че стандартният изход на WP_DEBUG често е неприятен за четене, а понякога и направо пречи: грешките се „изливат“ върху страницата, без контекст, без удобна навигация и без добър stack trace.

Ако работиш по по-модерни WordPress проекти (например със стек като Bedrock + Composer), има и по-приятен път: Acorn. Acorn е слой, който вкарва Laravel-подобни удобства в WordPress (helpers, service container и т.н.) и — важното за тази тема — подобрява начина, по който виждаш exception-ите, когато WP_DEBUG е включен.

Защо дефолтният WP_DEBUG изход не е достатъчен

WP_DEBUG се активира чрез константа в конфигурацията и е добра практика да е включен във всички локални среди. WordPress екосистемата е пълна с код, който хвърля notices/warnings (понякога от плъгини, понякога от теми), а без WP_DEBUG тези проблеми лесно остават скрити до production.

Самият output обаче е базов: текстови съобщения директно в HTML-а. Това помага да разбереш, че „нещо се чупи“, но не помага особено да стигнеш бързо до причината, особено когато exception-ът е по-дълбоко в call stack-а.

Стандартен изход на WP_DEBUG: грешки и notices, изписани директно върху страницата — Дефолтният WP_DEBUG output: полезен, но труден за четене при по-сложни проблеми. — *Forrás: Roots.io*

Как Acorn подобрява WP_DEBUG (Symfony exception handler)

Acorn „закача“ по-добър exception handler, когато WP_DEBUG и WP_DEBUG_DISPLAY са активни. По подразбиране Acorn използва Symfony exception handler, което дава значително по-четим екран при изключения: по-ясно форматиране, стек, контекст и обикновено по-малко визуален шум.

Acorn показва exception-и с Symfony exception handler, по-четим от стандартния WP_DEBUG output — Acorn по подразбиране: Symfony exception handler вместо гол текст върху страницата. — *Forrás: Roots.io*

Ignition в WordPress чрез Acorn: най-доброто изживяване за error pages

Ако идваш от Laravel, вероятно познаваш Ignition — default error page-ът на Laravel (от Laravel v9 насам). С Acorn v3 се появява поддръжка за routing по Laravel-ски, а това отваря вратата и за Ignition в WordPress проекти, които използват Acorn.

Практическият резултат е много по-силен debugging UX: по-добра навигация в stack trace-а, по-удобно разглеждане на контекст и като цяло изживяване, което е по-близко до това, което PHP разработчиците очакват от съвременен framework.

WP_DEBUG output през Acorn с Ignition: модерна error страница с удобен stack trace — Ignition върху WordPress (чрез Acorn): най-приятният вариант за exception страници локално. — *Forrás: Roots.io*

Инсталация на Ignition (dev dependency)

За да активираш Ignition в WordPress проект с Acorn, се добавя dev dependency през Composer от директорията, където е инсталиран Acorn:

composer require spatie/laravel-ignition --dev

composer require spatie/laravel-ignition --dev

Контекст за WP_DEBUG

Acorn подобрява визуализацията на грешките, но не заменя добрите практики: дръж WP_DEBUG включен локално и внимавай какво се показва публично. Подобреният handler е най-смислен в dev среда.

Whoops: по-старият препоръчан вариант (особено ако си на Acorn v2)

Преди Acorn v3 често се използваше whoops (популярен PHP error handler) за по-добри error pages. Ако по някаква причина си останал на Acorn v2, whoops все още може да ти даде по-добро изживяване спрямо базовия екран.

WP_DEBUG output през Acorn с whoops: по-добра визуализация на грешки от стандартния режим — Whoops е работеща алтернатива, но при Acorn v3 фокусът е върху Ignition. — *Forrás: Roots.io*

Ако не ползваш Acorn: плъгини, които помагат при debugging

Не всеки проект е с Acorn/Bedrock и това е окей. Ако си на класическа WordPress инсталация, пак можеш да си подобриш debugging-а с утвърдени плъгини, които дават допълнителна телеметрия и контекст (заявки към базата, hooks, HTTP заявки и др.).

Query Monitor — един от най-полезните инструменти за локална WordPress среда.
Debug Bar — класически вариант за базова диагностична информация.

Кратко обобщение: какво да избереш на практика

Винаги дръж WP_DEBUG включен локално, за да хващаш notices/warnings навреме.
Ако работиш с Acorn, получаваш по-четими exception страници още по подразбиране (Symfony handler), когато WP_DEBUG и WP_DEBUG_DISPLAY са активни.
За най-добро debugging изживяване в Acorn-базирани WordPress проекти, добави Ignition като dev dependency чрез Composer.
Ако не използваш Acorn, Query Monitor и Debug Bar са практични алтернативи за диагностика.