Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem
- WSOD. No error. Nothing.
Cause
Symfony\Component\HttpKernel\Kernel.php:
public function init()
{
if ($this->debug) {
ini_set('display_errors', 1);
error_reporting(-1);
DebugClassLoader::enable();
ErrorHandler::register($this->errorReportingLevel);
if ('cli' !== php_sapi_name()) {
ExceptionHandler::register();
}
} else {
ini_set('display_errors', 0);
}
}
Details
- index.php calls
$kernel = new DrupalKernel('prod', FALSE); - The second argument is
$debug, tacked onto$this->debugby the Kernel's constructor. - The rest is visible in the pasted snippet above.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | kernel-init-debug-errorexception.png | 15.25 KB | sun |
| #2 | drupal8.kernel-init-stopgap-fix.2.patch | 740 bytes | sun |
Comments
Comment #0.0
sunUpdated issue summary.
Comment #1
Crell CreditAttribution: Crell commentedI wonder if we shouldn't just modify our error handling to build off of that. I mean, the feature is there, and there's discussion elsewhere of a dev/prod toggle being useful.
Comment #2
sunWe can investigate that, but let's implant a stop-gap fix for now.
The $debug FALSE is hard-coded currently, which makes Drupal core development quite problematic.
Comment #3
Crell CreditAttribution: Crell commentedSeems like a worthwhile stopgap while we consider how to leverage the dev/prod flag: #1537198: Add a Production/Development Toggle To Core. Marking for later consideration.
Comment #4
sunAlso, FWIW, without this fix, any call to
debug()causes the Kernel to end the request:Comment #5
aspilicious CreditAttribution: aspilicious commentedThat last statement is incorrect. I just did a nice debug.
Comment #6
webchickSo... what exactly breaks, and let's get some test coverage for it.
Comment #7
sunerm. Nothing is broken. But if something is broken, you don't see what's broken.
Comment #8
Dries CreditAttribution: Dries commentedI'm ok with this stop-gap solution while we figure out a solution. I committed the patch to 8.x.
Sun, do we want to rename this issue?
Fixing this is different from #1537198: Add a Production/Development Toggle To Core, which Larry created in #3.
Setting to 'needs work' to make sure we either rename this issue, or create a follow-up issue.
Comment #9
sunI guess it's ok-ish to re-purpose this issue, given how short it is.
Note that (I believe) #1537198: Add a Production/Development Toggle To Core is different — the Kernel's
$environmentparameter seems to be a built-in, free-form environment specifier, which mainly seems to impact configuration (overrides, such as caching).The
$debugparameter is independent from that.I will definitely say that the Kernel's exception/error handling looks very solid. That ::init() code already reveals that it treats the CLI appropriately and even goes one step further and injects a debug handler into the class loader.
(The latter almost looks like a much better solution than #1632364: Write tests to ensure that all classes in Drupal can actually be found by the autoloader.)
On top of that, it even comes with a "maintenance theme"-alike output handler — e.g., if you enable
$debug = TRUEand trigger an exception, then you see a pretty-styled error page in your browser (replacing the entire page output).However, at the same time,
1) the Boolean TRUE/FALSE flag most likely won't be able to support our granular error handling configuration options (we have 4 different levels of error exposure alone, plus I think some additional settings). Symfony seems to solely rely on PHP ini settings instead (which I guess is just natural for a PHP framework without user-facing administration/configuration UI).
2) the verbose error/exception output is completely verbose (without any attempt to reduce it, like we just recently did in #1158322: Add backtrace to all errors).
3) replacing the entire page output is a bit extreme.
So, I'd totally +1 the idea of migrating to Symfony's error handler, but at the same time, I hope we can retain some "sanity" with regard to our current error handling.
That said, lastly, our error handling also plugs very deeply into the testing framework (e.g., sending HTTP response headers in case of any exceptions/warnings/errors), so as to communicate any otherwise non-trackable failures to web/functional tests; including special handling for
debug()E_USER_NOTICEs.Comment #9.0
sunUpdated issue summary.
Comment #10
Crell CreditAttribution: Crell commentedIt's been 2 years, and our bootstrap pipeline has changed radically. Is this issue still relevant?
Comment #11
dawehnerWhile using the symfony error handler code might not be what we want, we could at least think about improving our error handler code even further. It is still kind of a mess,
but at least compared to back then its more failure proven.
Comment #12
webchickComment #23
AaronMcHaleI'd really like to see Drupal use Symfony's error/exception handling, it provides a much nicer interface for debugging compared with what comes with Drupal.
#9 by @sun:
That might be our only real blocker, and could be addressed by simply initialising the debugger outside of the Symfony Kernel's init function, there's even docs on the Symfony site explaining how to do it, so it's definitely supported.
Comment #26
bradjones1Comment #27
Chi CreditAttribution: Chi commentedComment #28
andypostComment #29
andypostComment #30
AaronMcHaleIt kind of looks like this issue aims to do the same as #3051459: Replace error and exception handlers with implementation from Symfony ErrorHandler component, should either this issue or that issue be closed in favour of the other?
Comment #35
quietone CreditAttribution: quietone at PreviousNext commentedThis issue was committed to 8.x and then then re-opened with a new title. It would have been cleaner to close this one and open a new issue to discuss the next step. Anyway, here we are.
Thanks to @AaronMcHale, who found that there is a duplicate issue for the next step, #3051459: Replace error and exception handlers with implementation from Symfony ErrorHandler component where work can continue. So, for this issue I am restoring the meta data to the date it was committed and setting the status to Fixed.