WordPressのテーマやプラグインをカスタマイズする人必見 – デバック定数WP_DEBUGを正しく理解する

pixeladdict-1126970-o

・自作テーマを入れてみたけど期待通りに表示されない。
・新しいプラグインを入れたのに上手く動かない。
・サーバの引越しをしたら画面がまっ白。
・なにもしてないのに(そんなワケはないんですが)おかしくなった。

そんなあなた!もしかしてあなたのWordpressでなにかが起きているかもしれませんよ?ということでWordpressの開発をする人なら絶対に知っておかなければいけないエラーレポートについてまとめ的エントリーをしたいと思います。

WP_DEBUG定数はよく出てくる定数なので名前とどんなことをするものかくらいは漠然と知っている人は多いと思いますが、WP_DEBUGを設定すると具体的になにが起きて、なにができるのかをちゃんと伝えているサイトはほとんど見たことがないのでお口にあえばということで。

なにはなくともCODEX

60e8be719b2b3406815f5a3a759bf481

まずはマニュアルを見る。これ基本。
http://codex.wordpress.org/Debugging_in_WordPress

ただこれだけ見てもどんな定数がありますよ。どんなことに使いますよという情報くらいしか載ってない。正直CODEXでは足りてない。

たとえば「WP_DEBUGをONにするとデバックモードになりますよ」「PHPのエラーを表示しますよ」的なことだけしか書いてない。
これだと「ふーん」で終わっちゃうし、「セキュリティー的に開発環境以外では絶対につかっちゃだめ!キリッ!」とかいう人が出かねない。というかこういうこと言ってる人ばっかりですが。

まあ、いろいろ言ってもきりがないので、ひとまずここにのっている定数をご紹介しましょう。

いろいろあるよ!デバック定数

WP_DEBUG

最初に理解しなければいけないのはこのWP_DEBUGです。
たぶんここを理解していないのが変な勘違いがうまれる元でもあります。

WP_DEBUGはWordpressをデバックモード、というかエラーレポートを表示するように設定する定数です。

これをwp-config.php辺りで

としてやると、error_reporting( E_ALL )としてWordpressが動きます。

E_ALLなのでNoticeやWarningをはじめ、コンパイルエラーや廃止予定関数の警告も含めて全部のメッセージが出力されます。(出力されるエラーの種類はPHPのバージョンによります)

じゃあどこに出力されるの?というとデフォルトでは画面に出力されます。
ただし、後述するWP_DEBUG_DISPLAYでそのへんも制御可能です。

そしてこれがキモなのですが、WP_DEBUGはWP_DEBUG_DISPLAYやWP_DEBUG_LOGを有効にするためのスイッチも兼ねています。
つまりWP_DEBUGを有効にしなければWP_DEBUG_DISPLAYやWP_DEBUG_LOGを有効にしても意味がないんです。

この一言が言いたくてこのエントリーを書いたのでスッキリ。

WP_DEBUG_DISPLAY

WP_DEBUGで有効になったエラーレポートを画面に出力するかどうかを指定できます。
未定義の場合のデフォルトはONに設定されます。

これがデフォルトでONになっているのでWP_DEBUGが有効になると画面にエラーレポートが表示されることになるのですが、逆に言うとWP_DEBUGをONにしてもWP_DEBUG_DISPLAYをOFFにすれば画面にエラーが出力されることはありません。

重ねて言いますがWP_DEBUGがONの時にだけ意味のある定数です。

そうなるとエラーがでないんじゃWP_DEBUGを設定しても意味が無いよねと当然思うわけですが、ここをフォローするために次のWP_DEBUG_LOGが存在します。

WP_DEBUG_LOG

WP_DEBUGで出力されるエラーレポートをファイルに書き出す定数です。未定義の場合のデフォルトはOFFに設定されます。

出力はWordpressインストールディレクトリの/wp-contents直下にdebug.logというファイルで書きだされます。

これはWP_DEBUG_DISPLAYと併用が可能です。
つまり、画面にエラーレポートを表示して、かつログに残すこともできますし、画面にエラーレポートを出さずに、ログだけ出すことも可能です。

大事なことなので三回目ですがWP_DEBUGがONの時にだけ意味のある定数です。

SCRIPT_DEBUG

ここから先はちょっと毛色が違います。WP_DEBUGは関係ありません。
つまりWP_DEBUGがONだろうがOFFだろうが独立して意味がある定数です。

WordPressにロードされるCSSやJavascriptを圧縮されたものではなく、開発者版としてロードすることができ、かつスクリプトを単独で個別にロードします。未定義の場合のデフォルトはOFFに設定されます。

圧縮されたものといっているのは xxxxx.min.js とか xxxxx.min.css という形式のコメントや改行を削除してある通信容量に配慮したファイルのことで、オープンソースのスクリプトは大体このファイルが含まれています。
開発者版といっているのは.minといったサフィックスがつかない、コメントや改行を削除していない、人が読める形式のファイルです。

で、SCRIPT_DEBUGがONになっていると人が読める形式で読み込むので、ブラウザでデバックモードにしてソースを追うのが容易になるというメリットがあります。

が、ここも誤解がうまれるポイントなのでハッキリさせておかなければいけませんが、これが有効なのはWordpressがデフォルトでロードするスクリプトとスタイルのみです。

つまり、自分でwp_enqueue_script()やwp_enqueue_style()したものにまで適用されることはありません。つかえねー。

また、SCRIPT_DEBUGをONにすると読み込むファイルがWordpress3.5から変わってます。

3.5以前はファイルのサフィックスが xxxxx.dev.js となっているものをロードするようになっていたんですが、3.5からはOFFの場合は xxxxx.min.js をロードして、ONの場合は xxxxx.js のような無印をロードするようになりました。まめちしき。

SAVEQUERIES

ここれもWP_DEBUGは関係ありません。WP_DEBUGがONだろうがOFFだろうが独立して意味がある定数です。

$wpdbを使用してデータベースにSQLを発行する際のSQLが記録されます。
未定義の場合のデフォルトはOFFに設定されます。

これは「記録される」というのがポイントで、この定数をONにしても特になにも起こりません。
$wpdb->queries を print_r() でもしてやると中身が表示されます。

中身はSQL文とかかった時間と呼び出し元へのbacktraceです。取得結果は含まれません。あしからず。

エントリーのまとめ

WordPressのちょっと凝ったプラグインやテーマを使おうとすると、公式ディレクトリにあるものでさえNoticeやWarningが大量に出るものがあるのが現状です。

エラーが出てるものを無視してつかうのもアリといえばアリですが、エラーは意味があって出ているわけで、見なかったことにするのは気持ちいいものではありません。

きっちりとテストするのは当然ですが、テストの仕方、デバックの仕方を間違えてしまっていてはテストの意味がなくなってしまうのでキチンと理解して正しい開発を心がけたいものですね。