While updating modules to Drupal 7 I found it seemed impossible to get html_errors to work to ease finding broken functions and backtraces. It turns out that #304924: Extend drupal_error_handler to manage exceptions hard coded this and it was stated that "Drupal catches exceptions and displays them with the maintenance theme unless they happen *very* early."

That doesn't really help fatal errors is seems happening even in menu_execute_active_handler so it gives developers no recourse but to hack bootstrap.inc to see an easily readable backtrace in browser. This seems like a pretty bad design.

I don't know that its the right option but the attach patch removed the hard-coded setting from drupal_initialize_variables. Has anyone else run into this annoyance? Is there some better way we could support this?

CommentFileSizeAuthor
allow_html_errors_in_php_ini.patch638 bytesneclimdul

Comments

neclimdul’s picture

neclimdul
He/Him
commented
Status: Active » Needs review

Also, upon some inspection, neither watchdog messages nor the maintenance themed exception page seem to be broken by removing this. Can someone maybe provide a case where this is a problem?

neclimdul’s picture

neclimdul
He/Him
commented

I've been testing this patch for my development on CTools and Panels recently and have yet to run into a case where output was mangled by having html_errors enabled so I'm hoping this patch is just cleaning up some cruft.

neclimdul’s picture

neclimdul
He/Him
commented

This really is an easy review. Hope we can get this looked at before release.

damien tournoud’s picture

damien tournoud commented
Status: Needs review » Reviewed & tested by the community

That was introduced by the initial exception support patch: #304924: Extend drupal_error_handler to manage exceptions. See in particular http://drupal.org/node/304924#comment-1043193 for the rationale at this time.

In the meantime we finally figured out that PHP considers that error messages are actually HTML, while exception messages are plain-text (joy!), and we fixed our error/exception handler to map this broken behavior (see _drupal_error_handler_real() and _drupal_decode_exception()).

At this point, I see no reason not to allow html errors. We have a filter_xss_admin() in there to protect against common XSS, so I'm happy.

dries’s picture

dries commented
Status: Reviewed & tested by the community » Fixed

Agreed that this isn't really necessary anymore. Committed to CVS HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.