wordpressのエラーログ

wordpressでエラーを検出するためには、「php.ini」を編集する方法とwordpressのルートディレクトリにある「wp-config.php」の「define('WP_DEBUG', false);」を「define('WP_DEBUG', true);」とする方法があげられます。ただし、wordpressでデバッグモードがオフになっていても「php.ini」の設定が優先されます。反対に「php.ini」がオフになっていてもデバッグモードがオンになっていればwordpressの設定が優先されるようです。

従って、wordpressで開発する場合はどちらかがオンになっていれば良いということになりますが、wordpress特有の情報も得たいのであれば、デバッグモードをtrueに置き換えます。ただし、デバッグモードはwordpressが制御する範囲内に限られます。同一ドメイン内でも制御する範囲外では、「php.ini」の設定しか反映されない点に注意してください。

「php.ini」

これはphpの設定ファイルです。以下のように設定していると、wordpressでデバッグモードを指定していなくてもエラーが吐き出されます。ですが、これはwordpressのデバッガによるものではなく、あくまでphpによるエラー出力です。また、エラーが想定されているコードの先頭に「@」を追記することで、非表示にすることもできます。

エラーログを作成する時は、サーバ内のフルパスで以下のように指定します。レンタルサーバなら管理パネルからフルパスを確認できます。ファイル名は適当で構いません。わざわざ作らなくても検出時に自動で作られます。また、レンタルサーバの簡単設定ではerror_logディレクティブの項目が無いケースがあり、そういったときは直接編集の画面で入力します。レンタルサーバが直接編集画面を用意していない時は、FTPなどを使ってwordpressのルートディレクトより上に遡りながら、php.iniファイルを探してください。存在すればダウンロードして以下のように書き換え、再びアップロードして下さい。

error_reportingでよく指定される定義済み定数

これらを「&」でつなげて複数指定しているケースもありますが、定数の前に「~」があると否定になります。例えば、「E_ALL & ~E_NOTICE」とあれば、「E_NOTICE以外のすべてのエラーを表示する」という意味になります。

1. E_ALL：サポートされる全てのエラーと警告。
2. E_NOTICE：実行時の警告。致命的なエラーではない。
3. E_WARNING：実行時の警告。エラーを発しうる状況に遭遇した。
4. E_PARSE：コンパイル時のパースエラー。
5. E_DEPRECATED：将来のバージョンで動作しなくなるコードについての警告。
6. E_ERROR：重大な実行時エラー。

phpファイルに直書き

以下のようにファイル先頭に記述することで、そのファイル内でのエラーを出力します。ただし、wordpressではrequireやinclude、あるいはget_template_partなどのワードプレス独自関数によってエラー表示コードが読み込まれているケースもあり、その場合は全ページでエラーが表示されているように見えることもあります。ただ、そういったケースでも基本的にはincludeなどによって下記コードが読み込まれているだけであって、ワードプレスが自動的にこの設定を全てのページで踏襲している訳ではありませんので注意して下さい。

また、display_errorsの「1」はONでもTRUEでも構いません。反対に、エラーを非表示にしたい場合は、0、OFF、FALSEのいずれかを選択します。大文字と小文字は区別しません。

ログファイルとして保存するときは「ini_set('error_log', 'full_path'」を使います。適当なファイル名を指定すると、自動的に作られます。他にerror_logという組み込み関数も用意されていますが、使い道があまりないかも知れません。

wordpressのデバッグモード

ワードプレスの「wp-config.php」でデバッグモードがfalseになっている部分をtrueに書き換えてアップロードします。デバッグモードの良いところは、非推奨関数もエラーとして出力してくれる点です。もちろん、普通にphpを使うだけなら不要です。しかし、ワードプレスでブログなどを運営していて、テンプレートやプラグインなどを作ったり、自分でワードプレスの独自関数を記述しているケースでは便利です。理由は、将来プログラムが動かなくなって使用している関数などを見直す手間が省けるからです。

wordpressでよく出くわすエラー

以下はワードプレスと限りませんが、まあよく出ます。

Notice: Undefined index

未定義のインデックスという意味ですが、POSTやGETなどのグローバル変数をいきなりechoした際に出てきます。

回避のための対策

Parse error: syntax error

予期しない構文エラーという意味ですが、セミコロンなどの記述忘れが多いです。このケースでの行番号や提案はあてになりません。大抵、本来の誤記入位置より下の方でsyntax errorとされますので、提示された行番号より上のほうを確認したほうが早いです

Notice: Undefined variable

未定義の変数を使用したときに出てきます。

変数を使う前に初期化する。

変数が空かどうか確認してから処理する。

Warning: Invalid argument supplied for foreach

foreachに無効な引数が指定されたとのことですが、大抵配列ではない値を配列処理しようとした際に出てくるerrorです。

以下のようにコードの最初の方で、変数に対して配列の初期化をする。値を入れても良い。

以下のように(array)を追記してキャストしてもこのerrorを消すことはできますが、根本的な解決にはなっていません。なぜ配列になっていないのかを遡って調べたほうが良いでしょう。また、Notice: Undefined variableとセットで出ることが多いです。

開発終了後の対応

これらのerror出力がオンのままになっていると、パスディスクロージャというセキュリティの不備が発生するため、開発が終了したら全てをオフにしてください。このパスディスクロージャは何もワープレに限ったことではありません。エラーレポートによってスクリプトのフルパスが表示されてしまうため、攻撃者がわざとエラーを発生させて何らかの情報を得ようとする場合があります。フルパスが漏れたからといって必ずしも問題となる訳ではありませんが、なるべくそういった情報を与えないようにしたほうが無難です。

まとめ

ワープレのデバッグモードであれ、phpの出力であれ、基本的には全てのエラーを確認できるようにしておいたほうがあとあと面倒がなくて良いかもしれません。エラーの種類は選んで出力できますが、後で非表示にできない重大なエラーになってしまう可能性も０ではないため、はじめからすべてのエラーを修正して開発したほうが何かとスッキリしていいような気がします。

尚、編集する際は基本的にバックアップをとってから行うように癖をつけたほうが良いでしょう。ワープレのバージョン4.9からはテーマやプラグインファイルで無理な編集ができなくなっていますが、それでもミスを修正するまで更新できないといった悪循環に見舞われます。数行程度ならすぐに見つけられますが、数千行になればいじっているうちにどこで誤記入したのか予測をつけにくいケースが出てきます。そういったときは、直近で確実に動くバックアップファイルをアップロードしたほうが早い場合もあります。