WordPress開発のデバッグで、
幸せになれるかもしれない10行plugin

世界的なコミュニティーの御陰様で、大抵の事はありもののpluginで実現出来てしまうありがたいWordPressですが、複雑な案件で色んなpluginを組み合わせた時に思った通りに自分のコードが動かなかったり、WordPress本体のバージョンアップで挙動がおかしくなってしまうpluginが出てきたり、時に、自分の書いたコードだけでなく、人様のpluginの解析やらデバッグやらの必要性が発生します。

が、有名pluginほど、その豊富な機能が故に、解析しなければいけないコード量に呆然としたり...WordPressのフックを駆使した華麗すぎるコード程、流れを読み取りにくかったり...

そんな状況を少しだけ早く解消出来るかもしれない10行のプチpluginをご紹介します。
ちなみに、あまりにもささいなpluginなので、社内共有さえしていなかったのですが、数人に渡してみたら、声を揃えて『役に立ちましたよー！』と言って頂けたので、それが嘘でない事を祈りつつ、この記事を続けますw

有名どころのデバッグ系pluginと、それでも足りないケース

まずは、素晴らしいまとめBlogをご紹介。

WordPress：覚えておいて損はない、開発者向けプラグイン 25＋

実際に自分が使っているのは、リストの冒頭で紹介されている

• Debug Bar＋拡張プラグイン
• Query Monitor

だけなのですが、当然ながら、これらのpluginで全てが解決する訳ではありません。

※『Query Monitor』は、ほぼ欲しいもの全部入りで、思わず画面の前で手を合わせてしまう程に素晴らしいです。これは、また別の記事でご紹介したいと思います。

前出のplugin達でやっつけられない敵、
挙動がおかしいのに正常終了してエラーが検出出来ないとか、
ドキュメントの通りに関数やショートコード使ってるのに結果が...とか、
むしろ、そんな見えない敵の方に時間を費やす事の方が多いのでは？

PHPなんだからvar_dumpでいいじゃん？

PHPで出来ているWordPressですから、デバッグ時には、PHPの定番の手法がとられると思います。

【PHP入門講座】 デバッグ用関数

でも、この手法を使うと、表示が崩れたりするだけでなく、var_dumpの挿入箇所によって、そこ以降の処理が止まってしまったり、どこにも出力されなかったりします。
もちろん、テスト環境が無くて本番環境でテストしたい場合などには、当然使えません。
さてどうしましょう。

WordPressだから、WordPressらしい方法で解決してみる

以下の、10行pluginを自作してみます。
いつもの『Pluginception』で、"mylog"という名前でpluginを新規作成して、以下のコードをペーストしましょう。

お役目は、渡された変数をprint_r()で読みやすくしてpluginフォルダ内にファイル書き出しするだけ。
内容は、PHP超入門レベルで、WordPressの関数も1つしか使っていませんw

function mylog( $message , $filename = 'debug.txt' ){
//文字列じゃなかったら文字列に展開
if( !is_string($message) ){
$message = print_r( $message , true );
}
//出力内容
$message = date_i18n('Y-m-d H:i:s') . "\t" . $message . "\n";
//ログファイル名
$log_file = dirname(__FILE__) . '/' . $filename;
//ファイルに追記
$fp = fopen( $log_file , 'a' );
fwrite( $fp , $message );
fclose( $fp );
}

そして、解析したい箇所に mylog( 確認したい値 )を挿入してください。
例えば、先日の記事で説明をはしょらせて頂いた『ACFのバリデーションフックに何が渡されているか』を確認する際にはこんな風にしました。

function check_end_date( $valid, $value, $field, $input ){
//TEST
mylog( $valid );
mylog( $value );
mylog( $field );
mylog( $input );
/*　以下省略　*/}
add_filter( 'acf/validate_value/name=end_date' , 'check_end_date' , 10 , 4 );

このプラグインの編集画面に行くと、右のファイルリストにdebug.txtというリンクが出現している筈です。
ここをクリックすると、挿入したmylog()達の出力結果が確認できます。
この画面の編集機能で、内容を空にできますし、不要になれば、プラグイン自体を無効化すればいいだけ。

あちこちにたくさん入れる場合には、

mylog( '--- テスト1 ---' );
/*　省略　*/mylog( '--- /テスト1 ---' );

また、出力先のファイルを以下のように指定する事も可能ですので、調査内容によって出力を切り分ける事も出来ます。

mylog( $hoge , 'test1.txt' );
mylog( $piyo , 'test2.txt' );

いつだって、百聞は一見に如かず

呼び出し元が分かるPHPのデバッグ用関数 debug_backtrace() を使って mylog( debug_backtrace() ) とすることで、処理の流れを把握したり、
いままでなんとなく使っていた、WPのグローバル変数、$postやら$wp_queryのなかみを確認するのに使ってみたり、
フロントの表示や処理に影響を及ぼす事無く、思う存分、調べごとが出来ます。
これで、どこかのだれかのもやもやが、すこしでも解消されれば幸いです。

使用(仕様)上のご注意

当プラグイン無効化の際は、必ずコードに挿入したmylog()達を削除するかエスケープするかしてください。
また、調子に乗って色んなものを出力しまくったり、目的を果たした後にmylog()をコード内に放置すると、管理画面で開けなくなる程の巨大ファイルを生成しかねませんので、そこら辺は、おきまりの『自己責任』でお願いいたします。