タグ: 管理画面

WordPressをカスタマイズしていると、何かとエラーが出たりします。

その際によくあるデバッグ方法として、config.phpへの記述に

define('WP_DEBUG', true);

と記述し、エラーを表示させる機能があります。

ちなみにこれ、エラー表示を抑制するかしないかの機能。

 

もっと詳しく言うと、wp-admin/plugins.phpの140行目あたり、

if ( ! WP_DEBUG ) {
 error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
 }

こんな記述があったりします。

 

でも、WP_DEBUGをtrueにしても、

プラグインを有効化する際のエラーは表示してくれません。

何かいい方法無いかとぐぐってみましたが。

WordPressって、デバッグ方法について色々と機能が準備されていたんですね。

ほんと、知らないだけでした。

Debugging_in_WordPress

 

※この記事の情報は、記事を書いている時の最新バージョン、WordPress 3.5.1 をもとにしています。

 

define(‘WP_DEBUG_LOG’, true);

これはどんな機能か調べてみると、エラーの内容をログとしてwp-content/に記録してくれる機能。

詳しく見てみたい方は、wp-includes/load.php の 274行目付近を参照ください。

試しにconfig.phpに追加してみると、

debug.logというファイルが作成されました。その中身はこうでした。

 PHP Warning:  var_dump() expects at least 1 parameter, 0 given in

なんにもパラメータ無いじゃん。このxxxxやろう!! というエラーだと思いますね。

プラグインを有効化する際(ヘッダーを出力する前)のエラーを確認したい時に、とても便利な機能だと思います。

また、エラーの表示は出したくないけど、エラーが出た場合は記録だけしておきたい時には便利です。

たまにしか出ないエラーなんていうものだって、ありますもんね。

クライアントにWordPressをCMSとして提供している場合は、この機能を有効にしておいて、メンテナンスとしてこのログを確認することにも使えそうですね。

 

 

次は、

define(‘WP_DEBUG_DISPLAY’, true);

なんとなく英語を解釈すると想像できますが、念の為調べてみました。

wp-includes/load.php の 269行目付近。

php の display_errors を true にしているだけのようですね。エラーを表示するor しないを選択する機能のようです。

 

お次は、

define(‘SCRIPT_DEBUG’, true);

スクリプトデバッグ？何のスクリプト？と疑問です。で、調べてみました。

で、SCRIPT_DEBUGで条件分岐しているところがいくつかありました。

まずは、includes/class-wp-editor.php の551行目。

$suffix = ( defined('SCRIPT_DEBUG') && SCRIPT_DEBUG ) ? '_src' : '';

うん。$suffix。なんでしょうこれ。見る限りは、SCRIPT_DEBUGがtruだったら、_srcをいれる。

それがどういう役目なのか分からなかったので、$suffixが何に使われているのか調べてみると、

tinyMCEPreInit = {
 base : "<?php echo self::$baseurl; ?>",
 suffix : "<?php echo $suffix; ?>",

ビジュアルエディタのTinyMCEの何かのsuffixの値として、_src という値を入れているようです。

これがまたどういう役目なのか分からないので、もっと追っていこうと思いましたが、そもそもこの単語、どういう意味なんだろうとGoogleで翻訳してみました。

suffix = サフィックス。接尾。接尾語。

つまり、何かの接尾に_srcをつけるものっぽい。何かがさっぱり分からりません。

ただ、TinyMCEに使われている事は確かだと思いましたので、wp-includes/js/tinymce/tiny_mce.jsをひたすら検索していると、

"themes/"+q.theme+"/editor_template"+k.suffix+".js"

suffixが使われていますね。

おそらく、themes/advanced/editor_template_src.js というファイル名になるはず。

念の為確認すると、

• editor_template.js
  
• editor_template_src.js

２つ、ファイルがありますね。違いが分からないので開いてみましたが納得。

srcが無いほうのファイルは、圧縮されていました。（改行やスペース）

srcがあるほうは、デベロッパー向きでコードが見やすいものですね。

納得した後に他のコードも追ってみると、あとはほとんどがjsファイルに min を付けるか付けないか等の判別（圧縮ファイルを読み込むかどうか）で使われていました。

 

ただ、一箇所違う部分がありました。

wp-includes/script-loader.php 850行目付近

if ( ! is_admin() || ( defined('SCRIPT_DEBUG') && SCRIPT_DEBUG ) )
 $concatenate_scripts = false;

$concatenate_scripts ? これは一体なんでしょう。よく分からないので、変数名を翻訳してみました。

concatenate = 連結

連結。なんでしょう。。分かりません。Javascriptファイルの連結？しかも管理画面内のとき。

 

ふと考えると、WordPressのファイル読み込み設定は、

http://サイトURL/wp-admin/load-styles.php?c=1&dir=ltr&load=admin-bar,buttons,media-views,wp-admin&ver=3.5.1

このようになっています。もしかして、この連結のことかな？

SCRIPT_DEBUG をtrue にしたりfalseにしたりして、管理画面内のソースをにらめっこしてみると、trueにした時はbuttons のcssやnav-menusのjsなど、cssやjavascriptファイルをひとつずつ読み込む設定になる仕組みとなっていました。

こうやってみると、WordPressって多くのJSファイルを読み込んでいるんだな～と実感。それでいてよくあまりエラーが起きません。すごいな。。 😉

この機能は、普段のプラグインの開発やテーマの作成では使わないようなデバッグ機能かもしれません。

 

お次は、

define(‘SAVEQUERIES’, true);

クエリをセーブ。ログとして保存するのかな？分からないので探ってみました。

wp-includes/wp-db.php の1195行目あたり、

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES )
 $this->timer_start();

～

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES )
 $this->queries[] = array( $query, $this->timer_stop(), $this->get_caller() );

1つめのやつはtime_start()なんで、おそらく何か時間を開始していると解釈しました。

念の為確認してみましたが、microtime()で取得した値を変数に入れているだけのようです。

 

２つめの部分ですが、

 $this->queries[]

これがよくわからない。$this->queriesへ配列として追加。

よく分からないので $wpdb->queries を出力してみました。

Array
(
 [0] => Array (
 [0] => SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
 [1] => 0.0027470588684082
 [2] => require_once('...省略...'), wp_not_installed, is_blog_installed, wp_load_alloptions
 )
)

↑省略しています。require_onceの中身。長いので。

クエリが出力されました。

 

ただ、queriesに入るクエリは、どういったタイミングのクエリなんでしょう。

と思い、この関数名を見ると、

function query( $query )

$wpdb->queryで実行されたクエリ全てが対象のようです。

 

今回は何のフックもせずに、$wpdb->queryを実行したのでクエリがひとつしか出力されませんでした。

なので試しに、$wpdb->queriesをadmin_footerにフックさせて実行してみました。

結果、やっぱり$wpdb->queryを実行したクエリの情報を格納しているようでした。

クエリがちゃんと実行できているかどうか、予定通りのクエリを発行しているかどうか、確かめるには丁度いい機能ですね。

プラグイン開発者でデータベースをよく使用してテストする場合は、嬉しい機能です。

 

 

プラグインのデバッグにいいもの

Debug Bar

作成者にwordpress.orgが含まれているので安心して使えそうです。

ただ、私はこのプラグインの使い方がいまいちよく分からないので、使ってはいません。

Developer

作成者にAutomatticが含まれているので安心して使えそうです。