WordPressでは疑似クーロン(wp-cron)を使って、一定時間経過後に関数(コールバック関数)を呼び出すタイマー機能を実装できます。
そこで使うのが下記のWordPressの関数です。
スケジュール登録関数
- wp_schedule_event(リピート指定ができる)
- wp_schedule_single_event(一回のみ実行する)
上記の関数でスケジュール登録して、add_actionでフックしてコールバック関数を呼び出します。
問題になるのがコールバック関数の中身のデバッグです。
スケジュールは、バックグラウンドで処理されるのでvar_dumpなどで変数の中身を確認できません。
Contents
wp_schedule_eventで登録したコールバック関数をデバッグする方法
まず、コールバック関数の中身なのか、それ以前の問題かを切り分けます。
コールバック関数の中身以前の問題は、WP Controlプラグインを使って確認できます。
WordPressプラグイン「WP Control」で問題を切り分ける
WordPressプラグイン「WP Control」では、下記のことを確認できます。
WP Controlで確認できること
- wp_schedule_eventでスケジュール登録・実行できたか
- コールバック関数を設定できたか
- コールバック関数に渡す引数を設定できたか
wp_schedule_eventでスケジュール登録できると「Cronイベント」>「カスタムイベント」に表示されます。
フック | wp_schedule_eventで登録したフック |
引数 | wp_schedule_eventで登録したフック |
次回実行 | wp_schedule_eventで登録した日時 ※リピート設定していると実行後に日時が更新される |
アクション | add_actionで登録したコールバック関数 |
add_actionでスケジュールが正常に登録できれば、「アクション」にコールバック関数が表示されます。
アクションが「なし」になっている場合は、wp_schedule_eventのスケジュール登録は正常ですが、add_actionの登録がうまくいってません。
コールバック関数の中身をデバッグする以前の問題なので、正しく動くように修正が必要です。
メモ
wp_schedule_eventでスケジュール登録できるけど、コールバック関数だけ表示されない場合は、add_actionの呼び出し位置が悪い可能性があります。
設定位置を変更して、登録できる場所を探してみましょう。
コールバック関数の中身を調べる方法
コールバック関数単体で起動はできる状態(PHPエラーのFatal errorなどはなくす)にできたら、中身は下記の方法を使ってデバッグすると便利です。
wp_optionsテーブルに変数の中身を保存して確認する。
面倒に聞こえますが、wp_optionsテーブルは、WordPressが提供している関数を使って簡単に登録、取得、削除ができます。
新規作成・更新 | update_option |
取得 | get_option |
削除 | delete_option |
コールバック関数内で変数を確認したい場合は、下記のようになります。
//$hogeの中身を確認したい $my_debug = $hoge; update_option( 'my_debug_schedule', $my_debug );
wp_optionsテーブルで下記のコマンドを入力すれば、内容を確認できます。
※wp_optionsは自分のテーブル名に変更が必要です。
複数の変数の値を連結してデバッグ変数に代入すれば、一回のチェックで複数の変数をチェックできます。
//変数に区切りをつけて保存する $my_debug .= 'hoge::'.$hoge.'/'; $my_debug .= 'hige::'.$hige.'/'; //最後にwp_optionsテーブルに保存する update_option( 'my_debug_schedule', $my_debug );
get_optionで値を取得できる
今後も使う可能性があるなら、表示用のPHPファイルを作っておくと便利です。
<?php //get_optionで値を取得してechoする $my_debug_result = get_option( 'my_debug_schedule' ); echo $my_debug_result;
デバッグ後のデータ削除
デバッグが終わった後は、wp_optionsテーブルから削除すれば完了です。
※wp_optionsは自分のテーブル名に変更が必要です。
delete_optionで削除することもできます。
delete_option( 'my_debug_schedule' );
【まとめ】wp_schedule_eventで登録したコールバック関数の中身をデバッグする方法
「デバッグでDBを使うな!」という意見はごもっともですが、サーバーの権限がもらえない場合や、サーバーログなどを探してチェックするのが難しい場合は、この方法を検討してみるといいと思います。