I've continued to criticize XoopsErrorHandler since XOOPS-2.0.4 released.
There are three reasons:
(1) XoopsErrorHandler ignores the setting of php and messages are displayed
(2) If there are parse errors in codes, the error handler cannot work fine
(3) There are no way to override the handler if attackers access un-intended URI directly
In the other words, the setting of php must be the most important, hence such a handler looks non-sense for other than limited conditions.
Then, we should disable such a error handler, and control it via the setting of php (.htaccess or php.ini).
Especially, XoopsErrorHandler changes the level of error_reporting arbitrarily, thogh you set the level by .htaccess/php.ini explicitly.
Such a bad class should be dropped, right now.
Fortunately, XCL can do that without core hacks, however it is necessary to hack the core (include/common.php etc.) for the other X2 forks.
This is the preload.
http://www.peak.ne.jp/support/xoops/Preload_ErrorHandlerOriginal.zip
After you set this preload, you can recover the controls against php errors.
For both of developpers and site owners, it must be the best way to handle errors by log.
You may say...
"display_errors will be usefuler than log_errors for debugging"
I can deny it easily.
Just try
$ tail -f error_log
php_flag display_errors off
php_flag log_errors on
php_value error_log (a_file_you_like)
php_value error_reporting 2047