PEAK XOOPS - XOOPSにおけるPHPエラーハンドリング問題

XOOPS2.0.4から導入されて「しまった」XoopsErrorHandler。
私自身、ことある毎にこれについて批判してきましたが、その理由は明確です。

(1) phpの設定によらず、PHPエラーがHTTPボディとしてechoされてしまう
(2) fatalエラーなどで止まる場合は、ハンドラの上書きが効かない
(3) mainfile.phpを通過するケースとそうでないケースで、設定を一致させる術がない

(1)は、実稼働サイトでエラーを確認する術がないことを意味します。XoopsErrorHandlerは一応XOOPS_URLを隠蔽してくれますが、PHPデバッグがONの間、すべての訪問者にエラー内容を送出してしまう、という根本的な問題が解決されていません。

(2)も大きな問題です。mainfile.phpなどの記述ミスで、fatalエラーとなる場合、error_reporting()やXoopsErrorHandlerの処理など実行されないのですから、必然的にphpの設定がそのまま生きます。

(3)は(2)と似ていますが、これはPathDisclosure問題と直結します。XOOPSの構造は古く、本来DocumentRoot外に置かれるべきPHPコードの断片ファイル群が、DocumentRoot内に多く存在します。それらに直アクセスされた時に、PathDisclosureとなるかどうかは、php設定によるのです。

つまり、どのようなエラーハンドラ設計を行おうと、php設定こそが重要である、という事実はひっくり返しようがないのです。

であれば、特定条件を満たした時だけ働くエラーハンドラなど無効にして、PHP設定だけですべてをコントロールできるようにするのが合理的な手段というものでしょう。

特に勝手にerror_reporting()レベルを変更してしまうXoopsErrorHandlerなんて、今すぐ捨てましょう！


…と、ここで従来であれば、「その部分を潰すHackは〜」となるわけですが、XCL2.1なら、それさえもpreload一個で実現できることに、今になってようやく気付きました。

XCL2.1用のエラーハンドラ正常化preload
http://www.peak.ne.jp/support/xoops/Preload_ErrorHandlerOriginal.zip
（解凍で得られた ErrorHandlerOriginal.class.php を preloadフォルダにコピー）

このpreloadを入れるだけで、php設定だけでエラー処理をすべてコントロール出来るようになります。


なお、ほとんどすべてのケースで都合が良いのは、エラーをログに記録する方法です。
「ログ記録方式だとリアルタイムなデバッグに使いづらいじゃないか」なんていう人には、良い方法を教えましょう。好きなターミナルを開いておいて、
$ tail -f error_log
とするだけです。tailの-fオプションは様々な局面で役立つので、絶対に暗記しておくべきでしょう。

もしあなたがXCL-2.1を利用しているのなら、上述したpreloadを有効にした上で、php.iniや.htaccessで、エラーをロギングするようにしましょう(log_errorsをonにして、error_logに適切なファイルを指定)。もちろん、display_errorsはoffです。

それこそが、開発者にとって最も効率よい環境であり、同時に、サイト運営者にとって最も安全な環境ですから。