Closed Biont closed 2 years ago
In v3 I already added support for the constant the other day (https://github.com/wecodemore/wpstarter/commit/f59bd30c89a4c436853b984f3bcbcc8101517826) and I thought as well to set it when WP_ENV=development
.
The only issue I see is that there's no way to do conditional check on .env file itself, so the constant would be set on the auto-generated wp-config.php
, meaning that if someone, for some reason, want to have WP_ENV=development
and don't want to disable the fatal handler that could be very hard, depending on how WP does the check.
If WP checks just for the constant definition I'll have no way, unless provide myself an additional setting like WPSTARTER_FORCE_FATAL_HANDLER
. If WP checks for truthy value, then a dev could set it to true, keeping WP_ENV=development
and WP Starter will not attempt to set WP_DISABLE_FATAL_ERROR_HANDLER
because already set.
I planned to look at WP code soon, just did not had the time yet.
If you, or anyone else, has already looked at WP code and knows that WP checks for WP_DISABLE_FATAL_ERROR_HANDLER
being true and not only defined, and want to provide a PR, I'll be happy to merge.
Current implementation works. Closing.
Is your feature request related to a problem? Please describe. WordPress 5.2 introduced a new error recovery mode which displays a site with recovery instructions if the site encounters a fatal error:
https://make.wordpress.org/core/2019/04/16/fatal-error-recovery-mode-in-5-2/
While this is extremely nice for site owners and production systems, it makes it a little harder to see what just blew up your site during development
Describe the solution you'd like Luckily, they were nice enough to provide a constant to turn off this new error handler:
WP_DISABLE_FATAL_ERROR_HANDLER
So if have set
WORDPRESS_ENV=development
in your .env file, it would make sense to also define this new constant so we get our nice stack traces.