A WSOD is a pretty horrible thing from a UX perspective- absolutely no feedback that an error has even occurred. I think we could make this experience a little less traumatic by using register_shutdown_function to at least tell users 'sorry, an error has occurred', such as with the attached patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | drupal-no-more-wsod-1135066-12.patch | 1.05 KB | traviscarden |
| #1 | 1135066.patch | 1.04 KB | robloach |
| register_shutdown.patch | 498 bytes | danepowell |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !4440
Comments
Comment #1
robloachI like the idea a lot! The WSOD is definitely not something that's nice to get. If we provide a simplistic page with some details as to what happened, it might have both on the user perspective and the developer's. This patch moves it into part of the bootstrap instead of
index.php, and uses drupal_register_shutdown_function().Should this use the maintenance page to display the message? Should we provide more information about the error that occurred?
Comment #2
danepowell commentedWell, if there was some sort of fatal error, I don't know that we should rely on much of anything working, including the maintenance page. In an ideal world, maybe there could be some sort of graceful shutdown process, where if there's a bad shutdown, you try to display a nice maintenance page, and if THAT fails too, just give a white screen with "sorry, an error has occurred".
As for displaying errors: I don't think we should display them by default, as that could be a security risk. But maybe it could be user configurable, or maybe it could be based on PHP settings?
Comment #3
Josh The Geek commentedWhy not include the 500 header while you're at it? Internal server error is a good description of the problem. If that's the case, do you have to include the output anyway?
Comment #4
wapnik commentedWhy not display some sort of Drupal debug output, if the user is admin or has permission. Could be done in a pluggable way, to make it possible for tools like this to work with Drupal (probably through a wrapper module).
Comment #5
wapnik commentedLets pretend someone wants to build a Drupal specific debugger. A tool which indicates an error/message even if php itself does not. Can be in these cases:
Help me find other points here, please.
Or is it a modification of the coder module that what i want in core?
Comment #6
danepowell commentedThis all sounds great, but like I said- if there's a fatal error, I don't think we should count on being able to bootstrap Drupal (to check user permissions), or do much of anything really, other than say "Sorry".
Comment #7
wapnik commentedMaybe i should file another issue for this debugger. This needs some experiments first. Can we read settings.php before the error occur? Let's say an error in a module file.
Comment #8
wapnik commentedI just got that Nette\Debug working with Drupal, using the code from comment #1. Tested by adding random characters to theme's template.php, system.module, a settings.php file, debugger works as expected. Which is enough for a contrib developer. I'll try to make it pluggable now, put it out of core, if possible, try to figure out the strategy when to use it...
Comment #9
rfayAnother approach in #1159422: Death to WSOD: Output information about what caused a fatal error. There I'm just trying to give a little information about what has happened.
Comment #10
rfayIf you're testing: I created an error-creating fatal module for testing.
Comment #11
rfayWill need a reroll after the core patch went in.
Comment #12
traviscarden commentedHere's a patch to get the ball rolling again.
Comment #13
cweagansStill a couple issues to work out here:
1) How do we deal with translation of that string? Or at least allowing it to be overridden without a core hack?
2) Is there a clean way to show the maintenance page in that situation? If so, then I think we should.
Comment #26
smustgrave commentedFrom what I can tell this may still be valid. #1159422: Death to WSOD: Output information about what caused a fatal error was closed a duplicate a month ago.
Comment #29
rpayanmPlease review.
Comment #30
smustgrave commentedNeeds test coverage.