WordPress has a debug mode,
WP_DEBUG, that is enabled by setting the
WP_DEBUG constant in your configuration file.
WP_DEBUG should always be enabled in your local development environments in order to quickly catch notices and errors.
WP_DEBUG default output
WP_DEBUG output isn’t great: it simply shows the error messages and notices directly on the screen. This is absolutely better than nothing, and if you are developing WordPress plugins and themes, you should always enable
WP_DEBUG mode. The WordPress ecosystem is littered with countless plugins and themes that emit notices and errors.
Acorn WP_DEBUG outputs
Acorn’s WP_DEBUG default
Acorn will enhance your
WP_DEBUG output when
WP_DEBUG && WP_DEBUG_DISPLAY are enabled. By default, Acorn utilizes the Symfony exception handler. This provides an easier to read exceptions thrown on your sites.
Acorn’s WP_DEBUG output with Ignition
If you’re a Laravel developer, you might be familiar with Ignition — the default error page for Laravel since Laravel v9. With the release of Acorn v3, Acorn now includes support for routing in Laravel, which also means that Ignition is now supported on WordPress sites using Acorn. We recommend installing Ignition on your sites for the best error handling experience in WordPress.
To start using Ignition with WordPress, run
composer require spatie/laravel-ignition --dev from the same directory that Acorn’s installed.
Acorn’s WP_DEBUG output with whoops
Prior to Acorn v3, we recommended installing whoops alongside Acorn. For folks still on Acorn v2, we do recommend upgrading to Acorn v3, but it’s still possible to have a better experience compared to the Symfony error page by installing whoops:
If you’re not developing a site with Acorn (which you should be — don’t you want to use things like Laravel helpers in your codebase for a more modern PHP vibe?)— there’s also some WordPress plugins that provide a better
WP_DEBUG experience besides the default: