--- title: "По-добър WordPress debugging с Acorn: WP_DEBUG, Symfony, Ignition и реално четими грешки" url: "https://helloblog.io/bg/po-dobar-wordpress-debugging-s-acorn/" date: "2023-02-14" modified: "2026-01-20" author: "Мария Иванова" language: "bg_BG" categories: ["Екосистема WordPress"] tags: ["Acorn", "Bedrock", "Debugging", "WordPress", "WP_DEBUG"] featured_image: "https://helloblog.io/app/uploads/sites/21/2026/01/featured-3-1024x572.png" excerpt: "WP_DEBUG върши работа, но дефолтният му изход често е шумен и труден за четене. С Acorn можеш да получиш модерни error pages в WordPress и да дебъгваш много по-бързо локално." --- # По-добър 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, изписани директно върху страницата](https://helloblog.io/app/uploads/sites/21/2026/01/wp_debug-default-scaled.png) *Дефолтният 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](https://helloblog.io/app/uploads/sites/21/2026/01/wp_debug-acorn-symfony-scaled.png) *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](https://helloblog.io/app/uploads/sites/21/2026/01/wp_debug-acorn-ignition-scaled.png) *Ignition върху WordPress (чрез Acorn): най-приятният вариант за exception страници локално. — *Forrás: Roots.io** ### Инсталация на Ignition (dev dependency) За да активираш Ignition в WordPress проект с Acorn, се добавя dev dependency през Composer от директорията, където е инсталиран Acorn: ``` 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: по-добра визуализация на грешки от стандартния режим](https://helloblog.io/app/uploads/sites/21/2026/01/wp_debug-acorn-whoops-scaled.png) *Whoops е работеща алтернатива, но при Acorn v3 фокусът е върху Ignition. — *Forrás: Roots.io** ## Ако не ползваш Acorn: плъгини, които помагат при debugging Не всеки проект е с Acorn/Bedrock и това е окей. Ако си на класическа WordPress инсталация, пак можеш да си подобриш debugging-а с утвърдени плъгини, които дават допълнителна телеметрия и контекст (заявки към базата, hooks, HTTP заявки и др.). - [Query Monitor](https://querymonitor.com/) — един от най-полезните инструменти за локална WordPress среда. - [Debug Bar](https://wordpress.org/plugins/debug-bar/) — класически вариант за базова диагностична информация. ## Кратко обобщение: какво да избереш на практика 1. Винаги дръж `WP_DEBUG` включен локално, за да хващаш notices/warnings навреме. 2. Ако работиш с Acorn, получаваш по-четими exception страници още по подразбиране (Symfony handler), когато `WP_DEBUG` и `WP_DEBUG_DISPLAY` са активни. 3. За най-добро debugging изживяване в Acorn-базирани WordPress проекти, добави Ignition като dev dependency чрез Composer. 4. Ако не използваш Acorn, Query Monitor и Debug Bar са практични алтернативи за диагностика. ## Препратки / Източници - [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/) - [whoops](https://github.com/filp/whoops)