{"id":123,"date":"2023-02-14T00:00:00","date_gmt":"2023-02-13T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/pl\/debugowanie-wordpressa-z-acorn-czytelne-bledy-zamiast-surowego-wp-debug\/"},"modified":"2026-01-20T06:32:51","modified_gmt":"2026-01-20T05:32:51","slug":"debugowanie-wordpressa-z-acorn-czytelne-bledy-zamiast-surowego-wp-debug","status":"publish","type":"post","link":"https:\/\/helloblog.io\/pl\/debugowanie-wordpressa-z-acorn-czytelne-bledy-zamiast-surowego-wp-debug\/","title":{"rendered":"Debugowanie WordPressa z Acorn: czytelne b\u0142\u0119dy zamiast surowego WP_DEBUG"},"content":{"rendered":"\n

W WordPressie debugowanie zwykle zaczyna si\u0119 i ko\u0144czy na sta\u0142ej WP_DEBUG<\/code>. I s\u0142usznie \u2014 lokalnie to powinien by\u0107 absolutny standard, bo pozwala szybko wy\u0142apa\u0107 notice<\/em>, warning<\/em> i b\u0142\u0119dy, kt\u00f3re w innym przypadku potrafi\u0105 ukrywa\u0107 si\u0119 tygodniami. Problem w tym, \u017ce domy\u015blny output WordPressa jest\u2026 ma\u0142o przyjazny. W praktyce dostajesz zrzut komunikatu na ekran, cz\u0119sto bez kontekstu, bez \u0142adnego stack trace i bez sensownej prezentacji danych.<\/p>\n\n\n\n

Je\u015bli budujesz projekty na stacku Roots (np. Bedrock + Acorn), mo\u017cesz to znacz\u0105co poprawi\u0107. Acorn \u2014 czyli warstwa integruj\u0105ca spor\u0105 cz\u0119\u015b\u0107 ekosystemu Laravel z WordPressem \u2014 potrafi podmieni\u0107 obs\u0142ug\u0119 wyj\u0105tk\u00f3w i wy\u015bwietla\u0107 b\u0142\u0119dy w formie, do kt\u00f3rej przyzwyczai\u0142y nas nowoczesne frameworki PHP.<\/p>\n\n\n\n

WP_DEBUG w praktyce: co daje i dlaczego warto go mie\u0107 zawsze lokalnie<\/h2>\n\n\n\n

WP_DEBUG<\/code> to prze\u0142\u0105cznik trybu debug w WordPressie. Po jego w\u0142\u0105czeniu WordPress i PHP zaczynaj\u0105 raportowa\u0107 m.in. b\u0142\u0119dy, ostrze\u017cenia i notatki (notices), kt\u00f3re cz\u0119sto sygnalizuj\u0105 problemy jako\u015bciowe w kodzie: u\u017cycie nieistniej\u0105cej zmiennej, wywo\u0142anie przestarza\u0142ej funkcji, nieprawid\u0142owy typ argumentu itp.<\/p>\n\n\n\n

W projektach opartych o Bedrock (nowoczesny boilerplate WordPressa zarz\u0105dzany przez Composer) tryb debug w \u015brodowisku developerskim jest ju\u017c sensownie ustawiony domy\u015blnie \u2014 dzi\u0119ki osobnym plikom konfiguracyjnym per \u015brodowisko. To oszcz\u0119dza czas i ogranicza ryzyko, \u017ce kto\u015b \u201ezapomni\u201d o debugowaniu lokalnie.<\/p>\n\n\n\n

Dlaczego domy\u015blny output WP_DEBUG bywa niewystarczaj\u0105cy<\/h2>\n\n\n\n

WordPress w najprostszym wariancie wy\u015bwietla komunikat bezpo\u015brednio na stronie. To lepsze ni\u017c cisza, ale przy realnych b\u0142\u0119dach (zw\u0142aszcza w z\u0142o\u017conych motywach i wtyczkach) szybko pojawiaj\u0105 si\u0119 typowe problemy:<\/p>\n\n\n\n

    \n\n
  • ma\u0142o czytelny stack trace albo jego brak (zale\u017cnie od kontekstu i konfiguracji PHP)<\/li>\n\n\n
  • trudno znale\u017a\u0107 \u017ar\u00f3d\u0142o b\u0142\u0119du w kodzie, gdy wyj\u0105tek wyp\u0142ywa g\u0142\u0119boko z hook\u00f3w WordPressa<\/li>\n\n\n
  • brak dodatkowego kontekstu w stylu \u201eco to za request\u201d, \u201ejakie by\u0142y dane wej\u015bciowe\u201d, \u201eco jest w zmiennych\u201d<\/li>\n\n<\/ul>\n\n\n\n

    W efekcie debugowanie zamienia si\u0119 w r\u0119czne dorzucanie error_log()<\/code>, var_dump()<\/code> albo w bieganie z Xdebug \u2014 co jest OK, ale nie zawsze najszybsze na start.<\/p>\n\n\n\n

    Co zmienia Acorn: lepsza obs\u0142uga wyj\u0105tk\u00f3w przy WP_DEBUG<\/h2>\n\n\n\n

    Acorn poprawia do\u015bwiadczenie debugowania, gdy masz aktywne WP_DEBUG<\/code> oraz WP_DEBUG_DISPLAY<\/code>. Innymi s\u0142owy: gdy WordPress ma debugowa\u0107 i ma prawo co\u015b wy\u015bwietli\u0107 w przegl\u0105darce, Acorn przejmuje obs\u0142ug\u0119 wyj\u0105tk\u00f3w i pokazuje je w czytelniejszej formie.<\/p>\n\n\n\n

    Warto doprecyzowa\u0107 poj\u0119cia: exception handler<\/em> (obs\u0142uga wyj\u0105tk\u00f3w) to komponent, kt\u00f3ry decyduje jak aplikacja reaguje na wyj\u0105tki \u2014 czy tylko je loguje, czy zwraca HTML, jaki pokazuje stack trace, jak formatuje dane itd. WordPress historycznie nie by\u0142 projektowany jako framework aplikacyjny, wi\u0119c jego domy\u015blna ergonomia w tym obszarze jest ograniczona.<\/p>\n\n\n\n

    Domy\u015blne strony b\u0142\u0119d\u00f3w w Acorn: handler Symfony<\/h3>\n\n\n\n

    Domy\u015blnie Acorn wykorzystuje mechanizm obs\u0142ugi wyj\u0105tk\u00f3w z ekosystemu Symfony. W praktyce oznacza to bardziej uporz\u0105dkowan\u0105 stron\u0119 b\u0142\u0119du: czytelny komunikat, plik i linia, oraz stack trace, kt\u00f3ry da si\u0119 normalnie przejrze\u0107.<\/p>\n\n\n\n

    Ignition w WordPressie (Acorn v3): do\u015bwiadczenie jak w Laravelu<\/h3>\n\n\n\n

    Je\u015bli pracujesz z Laravelem, Ignition prawdopodobnie kojarzysz jako domy\u015bln\u0105 stron\u0119 b\u0142\u0119du w Laravelu (od wersji 9). W Acorn v3 pojawi\u0142o si\u0119 wsparcie dla routingu w stylu Laravel, a razem z nim mo\u017cliwo\u015b\u0107 u\u017cywania Ignition tak\u017ce w projektach WordPressowych opartych o Acorn.<\/p>\n\n\n\n

    To jest du\u017ca zmiana jako\u015bciowa, bo Ignition jest nastawiony na szybkie namierzanie problem\u00f3w: prezentuje wyj\u0105tek w bardzo czytelnej formie i u\u0142atwia nawigacj\u0119 po stack trace. Je\u015bli zale\u017cy Ci na mo\u017cliwie \u201eframeworkowym\u201d DX (developer experience) w WordPressie, to jest najrozs\u0105dniejsza opcja.<\/p>\n\n\n\n

    \n\n

    Instalacja Ignition (dev dependency)<\/h4>\n\n\n

    Ignition instalujesz przez Composer jako zale\u017cno\u015b\u0107 developersk\u0105, uruchamiaj\u0105c polecenie w katalogu, w kt\u00f3rym zainstalowany jest Acorn.<\/p>\n\n<\/div>\n\n\n\n

    <\/circle><\/circle><\/circle><\/g><\/svg><\/span>