{"id":142,"date":"2023-02-14T00:00:00","date_gmt":"2023-02-13T23:00:00","guid":{"rendered":"https:\/\/helloblog.io\/de\/besseres-wordpress-debugging-mit-acorn\/"},"modified":"2026-01-20T06:32:39","modified_gmt":"2026-01-20T05:32:39","slug":"besseres-wordpress-debugging-mit-acorn","status":"publish","type":"post","link":"https:\/\/helloblog.io\/de\/besseres-wordpress-debugging-mit-acorn\/","title":{"rendered":"Besseres WordPress-Debugging mit Acorn: WP_DEBUG endlich sinnvoll lesen"},"content":{"rendered":"\n

In WordPress ist WP_DEBUG<\/code> der klassische Schalter, um Notices, Warnings und Exceptions in der Entwicklung sichtbar zu machen. Aktiviert man ihn konsequent lokal, f\u00e4ngt man viele Probleme fr\u00fch ab \u2013 gerade weil im WordPress-\u00d6kosystem (Themes, Plugins, MU-Plugins) erstaunlich oft \u201ekleine\u201c Notices entstehen, die sp\u00e4ter im falschen Moment zu echten Bugs werden.<\/p>\n\n\n\n

Das Problem: Die Standardausgabe von WordPress ist funktional, aber unbequem. Sie wirft Meldungen einfach ins HTML, ohne Kontext, ohne Stacktrace-Darstellung, ohne gute Lesbarkeit. Genau hier setzt Acorn<\/strong> an: Es erweitert die Ausgabe von WP_DEBUG<\/code> so, dass du Fehler \u00e4hnlich angenehm analysieren kannst wie in modernen PHP-Frameworks.<\/p>\n\n\n\n

WP_DEBUG in WordPress: Was passiert standardm\u00e4\u00dfig?<\/h2>\n\n\n\n

Wenn WP_DEBUG<\/code> aktiv ist, schreibt WordPress Fehlermeldungen und PHP-Notices je nach Konfiguration direkt ins Markup (und\/oder in Logs). F\u00fcr schnelle Sichtbarkeit ist das okay \u2013 aber beim echten Debugging fehlt oft das, was du brauchst: klare Exception-Seiten, konsistente Stacktraces, saubere Darstellung von Request- und Kontextinfos.<\/p>\n\n\n\n

\"Standardausgabe
So sieht WP_DEBUG ohne zus\u00e4tzliche Tools h\u00e4ufig aus: Meldungen landen direkt auf der Seite. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

Bedrock-Setup: WP_DEBUG ist in Development oft schon gesetzt<\/h2>\n\n\n\n

Wenn du mit Bedrock<\/strong> arbeitest (modernes WordPress-Boilerplate mit Composer), ist WP_DEBUG<\/code> in Development-Umgebungen typischerweise bereits aktiviert. Das nimmt dir eine Fehlerquelle ab: Du startest nicht aus Versehen \u201eblind\u201c in eine lokale Session, sondern siehst Notices und Errors sofort.<\/p>\n\n\n\n

Acorn als Upgrade f\u00fcr WP_DEBUG-Ausgaben<\/h2>\n\n\n\n

Acorn<\/strong> ist das Roots-Paket, das Laravel-Komponenten in WordPress-Projekte bringt (u. a. Service Container, Commands, Helpers). F\u00fcrs Debugging besonders interessant: Wenn WP_DEBUG<\/code> und<\/strong> WP_DEBUG_DISPLAY<\/code> aktiv sind, ersetzt Acorn die eher rohe WordPress-Ausgabe durch deutlich besser lesbare Error-Handling-Seiten.<\/p>\n\n\n\n

Acorns Default: Symfony Exception Handler<\/h3>\n\n\n\n

Ohne weitere Zusatzpakete nutzt Acorn standardm\u00e4\u00dfig den Symfony Exception Handler<\/strong>. Das liefert dir eine strukturierte Exception-Ansicht, bei der du schneller erkennst, wo der Fehler ausgel\u00f6st wurde und welche Pfade beteiligt sind.<\/p>\n\n\n\n

\"Acorn
Acorns Standard-Error-Page (Symfony) ist deutlich lesbarer als die WordPress-Ausgabe. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

Ignition in WordPress: Laravel-Feeling dank Acorn v3<\/h3>\n\n\n\n

Wenn du aus der Laravel-Welt kommst, kennst du vermutlich Ignition<\/strong>: die Error-Page, die seit Laravel v9 der Standard ist. Mit Acorn v3<\/strong> ist Ignition auch in WordPress-Projekten nutzbar, weil Acorn seit v3 Laravel-Routing unterst\u00fctzt \u2013 und damit auch das Ignition-Integration-Setup m\u00f6glich wird.<\/p>\n\n\n\n

\"WP_DEBUG-Ausgabe
Mit Ignition bekommst du die vertraute Laravel-Debug-Experience direkt in WordPress. \u2014 Forr\u00e1s: Roots.io<\/em><\/figcaption><\/figure>\n\n\n\n

F\u00fcr Ignition installierst du das Paket in der Regel als Dev-Dependency \u00fcber Composer (im gleichen Verzeichnis, in dem Acorn installiert ist):<\/p>\n\n\n\n

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