SEE: http://drupal.org/node/49501

Steven fixed the earlier Ajax update failing on Fatal and Parse errors by using an ini_set('display_errors', 0).
This hides errors from developers as Dries note. The Ajax javascript stuff should be extended to report these errors.

CommentFileSizeAuthor
#4 update.fatal.error.patch9.13 KBSteven
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dopry’s picture

Dries said in the aformentioned issue:

#44 submitted by Dries on March 7, 2006 - 12:12

The update.php is not properly reporting errors anymore. I spent 45 minutes debugging a simple problem.

Update.php said: 'The update process did not complete. All errors have been logged. You may need to check the watchdog table manually.' but no errors were logged.

reproduction instructions? We need to know that we can fix this before you disappear on you wedding/honeymoon/escape from drupal.

Steven’s picture

Title: AJAX/JSON... ini_set(display_errors,0) hiding errors that need to be reported. » Watchdog not logging update errors

The error reporting has nothing to do with ajax... outputting errors during the updating is bad whether JS is used or not. With the non-JS version, any extra output such as error messages only appears for a second anyway.

The real issue is that some or all errors are not being logged to the watchdog correctly.

moshe weitzman’s picture

could someone elaborate where the watchdog call is missing? error_handler() is not behaving properly. i will do whatever needs to be done if i get some guidance here.

Steven’s picture

FileSize
9.13 KB

This patch removes the last shreds of configuration dependency of update.php, and improves the handling of fatal errors. The main issue was that PHP does not pass most fatal errors through the custom error handler, so they were never logged in the watchdog. So I changed things around (again).

  • The PHP error printing is turned off only until Drupal's error handler is installed. This means that the unavoidable database errors which are dealt with in update_fix_xxxxx() are still silent. But later fatal errors are reported on screen.
  • Instead of redirecting to the summary page when a fatal error occurs during updating, we give the user a chance to copy/paste the error message. The output buffering trick is used to provide a friendly error page for fatal errors, even for the non-JS version (image).
  • On the summary page, the user is told exactly which update failed as well as any other non-fatal warnings that occurred before the fatal error (image).

Note that fatal errors are only those that cause PHP to stop directly (parse error, non-existant function, memory/time limit, ...). These are mostly development mistakes. The vast majority of users will only encounter warnings (e.g. failed db queries) which were dealt with elegantly already.

Steven’s picture

Status: Active » Needs review

-

neclimdul’s picture

WFM. This seems to fix all the issues.

As a side note, the problem many of us had with watchdog not storing our errors wasn't entirely due to php not passing errors through the error handler. You will find that devel.module reverts drupals error_handler back to the default(look at devel_init). This is a quick debug feature when working on pages but is going to be undesirable on any ajax callback. This is what was probably the cause of the problem annoying Dries in the first place unless he was having a parsing error.

chx’s picture

Status: Needs review » Reviewed & tested by the community

I can only admire what Steven is cooking.

killes@www.drop.org’s picture

Seems to work fine, waiting for word from Neil.

rbrooks00’s picture

FWIW I think Neil is out till Wednesday unless someone has a more direct line to him.

Stefan Nagtegaal’s picture

Component: other » update system

Works perfectly for me! :-)

Gerhard Killesreiter’s picture

Status: Reviewed & tested by the community » Fixed

applied

Anonymous’s picture

Status: Fixed » Closed (fixed)