フックはどの順で走る？“見える化”ログ術（WordPress）
これは何ですか？
「WordPress は実際どの順番で処理が走っているのか」を、自分のサイト上で可視化するミニツールをご紹介します。
やることはシンプルで、add_action('all', ...) を利用して通過したフック名を debug.log に記録します。順番が見えると「どのタイミングで処理を挟めば安全か」が判断しやすくなります。
目次
前提（安全に試すために）
まずは wp-config.php のデバッグ設定を確かめます。未設定なら次の 3 行を追加します（既に定義がある場合は重複しないようにしてください）。
// wp-config.php（/* That's all, stop editing! */ より上）
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true); // wp-content/debug.log に出力します
define('WP_DEBUG_DISPLAY', false); // 画面には出しません（本番で安全です）
終わったら元に戻す（
falseにする）か、必要なときだけ一時的にtrueにする運用をおすすめします。本番でのログ出力は最小限にしましょう。
最小セット：発火順を番号付きでログ出力します
以下を テーマの functions.php または mu-plugins に一時的に置いて使います。
<?php
// === Hook Logger（必要な時だけ有効化してください） ===
add_action('plugins_loaded', function () {
// まずはフロント側だけ観察します（管理画面は後述）
if (is_admin()) {
return;
}
// 観察対象のフックを絞ると見やすく・軽くなります（必要に応じて追加してください）
$watch = [
'init', 'wp', 'template_redirect', 'wp_head',
'loop_start', 'the_post', 'the_content', 'loop_end', 'wp_footer'
];
add_action('all', function ($tag) use ($watch) {
static $n = 0;
if (!in_array($tag, $watch, true)) {
return; // 監視対象のみ記録します
}
error_log(sprintf('%03d %s', ++$n, $tag));
});
});
wp-content/debug.log には次のように並びます。
001 init
002 wp
003 template_redirect
004 wp_head
...
010 the_post
011 the_content
...
020 wp_footer
この並びから、出力して良いタイミング／避けるべきタイミングが直感的に分かります。
とくに init のような早いフックで echo をすると、ヘッダー送信前の出力になり不具合の原因になりますので、ログは error_log() に出すのがおすすめです。
回数や現在のフック名を知る補助API
フックが何回呼ばれたかは did_action()、今どのフックの中かは current_filter() で分かります。
<?php
add_action('the_post', function () {
error_log('the_post count=' . did_action('the_post'));
});
add_action('the_content', function ($content) {
error_log('now: ' . current_filter());
return $content;
}, 10);
管理画面の流れを覗きたい場合
管理画面側の主要フックだけ観察する例です。必要なときだけ一時的に有効化してください。
<?php
add_action('admin_init', function () {
// 観察対象のフックは必要に応じて増減してください
$watch = ['admin_init', 'admin_menu', 'current_screen', 'load-post.php', 'admin_notices'];
add_action('all', function ($tag) use ($watch) {
static $n = 0;
if (!in_array($tag, $watch, true)) {
return;
}
// A を付けてフロントのログと区別しやすくします
error_log(sprintf('A%03d %s', ++$n, $tag));
});
});
出力例（wp-content/debug.log）
画面やプラグイン構成によって順序は前後します。下記はあくまで一例です。
ダッシュボード（/wp-admin/index.php）の例
A001 admin_init
A002 current_screen
A003 admin_menu
A004 admin_notices
投稿編集画面（/wp-admin/post.php?post=123&action=edit）の例
A001 admin_init
A002 current_screen
A003 load-post.php
A004 admin_menu
A005 admin_notices
観察ポイント
-
admin_init：管理画面の初期化タイミングです。設定の読み込みや軽い準備処理に向きます。 -
current_screen：いま開いている管理画面のスクリーン情報が確定します。画面ごとの分岐に使いやすいです。 -
load-*.php：特定ページを開いたときだけ発火します（例：投稿編集ならload-post.php）。その画面専用の前処理に便利です。 -
admin_menu：メニューの登録・調整のタイミングです。 -
admin_notices：通知（バナー）を表示するタイミングです。画面への出力はこの辺り以降が安全です。
片付けと注意点
- 使い終わったら、必ず削除またはコメントアウトしてください。
add_action('all')は重い処理です。 - 本番では短時間だけ有効化するか、ステージング環境での確認をおすすめします。
- 早いフックでの
echo出力は避け、ログはerror_log()に送ると安全です。
最後に
この「見える化」ロガーは、“順番を体で覚える”ための補助輪です。使い終わったら、必ず無効化・削除してください。本番環境では短時間だけの利用をおすすめします。
- 判断の軸ができます：どのフックで「出力／保存／前処理」を行うか、根拠をもって決められるようになります。
-
早いフックでの
echoは避けます：initなどでは画面に出さず、error_log()に記録します。 -
出力してよいタイミングの目安：フロントは
wp_head／wp_footer以降、管理画面の通知はadmin_notices。 -
前処理の目安：フロントは
template_redirect、管理画面はadmin_init／current_screen、画面個別はload-*.php。
次の一歩としては、「入力は sanitize／出力は escape／状態変更は nonce」 の最小セット（CSRF 対策とエスケープの基本）と、「WP 新人がまずつまずくエラー10選」をあわせて読んでいただくと、トラブルシュートがぐっと楽になります。
最後まで読んでいただき、ありがとうございます。この記事が役に立ちましたら、ストックやフォロー、または「ここも見たい」「この順番も見える化したい」といったご要望をコメントで教えてください。今後の改善に活かします。
あわせて読みたい