This patch makes the error_handler() function pass errors to drupal_set_message(), instead of printing errors itself using raw print statements. I wrote this patch in order to fix the issue of user #1 not being able to register properly, if no mail server is installed on the machine being used. When this happens, a PHP warning is generated, due to the mail() function being called. Since the forms API came in, a user is redirected to the 'edit my account' page after registering. This results in a 'headers already sent' problem (since error_handler() prints errors directly).
With this patch, no errors are printed to the screen until after any redirects (using drupal_goto()) have occurred. I don't know what impact this patch may have on other things in Drupal - perhaps there is a reason why print is used instead of drupal_set_message() in this function? If so, please explain this to me. But as far as I could tell, there is no reason why errors should be printed directly, instead of using the standard drupal message display system.
Comment | File | Size | Author |
---|---|---|---|
error_handler_output.patch | 789 bytes | Jaza | |
Comments
Comment #1
Jaza CreditAttribution: Jaza commentedComment #2
chx CreditAttribution: chx commentedApplies, works, needed, My head is not fresh enough to find a legal use case for that print.
Comment #3
webchickAh, wicked! :D Ever since the batch of patches that went in a day or two ago I've been plagued by the "white screen of death after user 1 registration on computer w/ no mail server" problem, myself. This patch fixes that just great.
The only argument I could see against putting these types of errors in a drupal_set_message is that PHP errors might get mixed in with "You forgot to fill in your password" errors on forms, which may be confusing for users.
Otherwise, huge +1 from me.
Comment #4
Jaza CreditAttribution: Jaza commentedComment #5
Dries CreditAttribution: Dries commentedCommitted to HEAD. Thanks.
Comment #6
(not verified) CreditAttribution: commented