WP Statisticsの移行処理が0%で止まる原因と直し方
WP Statisticsの移行処理が3つとも0%で止まる場合、多くのケースでサーバー自身へのループバックリクエストがCloudflareやファイアウォールに遮断されている。管理画面から再試行しても進まない場合は、WP-CLIで処理を直接実行すると解決できる。
移行処理が0%で止まる原因は何か
WP Statisticsの移行処理はブラウザの画面表示とは独立したバックグラウンドジョブとして動く。管理画面で移行を開始すると、WordPressは自身のサーバーに対してadmin-ajax.phpへPOSTリクエストを送り、そのリクエストがバッチ処理を実行する仕組みだ。
このリクエストが何らかの理由でブロックされると、移行処理のカウンターは0%のまま動かなくなる。特にCloudflareのプロキシを有効にしている環境や、サーバー側のファイアウォール、セキュリティプラグインが自サーバーからのリクエストを遮断していることが多い。
上の図は移行処理が止まったときの対処フローを示している。まずループバック障害の有無を確認し、ネットワーク経路の問題なら設定変更で直す。それでも進まない場合はWP-CLIでHTTPリクエストを経由せずに処理を実行する。
「ループバックリクエスト」とは、サーバーが自分自身のURLに対してHTTPリクエストを送る仕組みのことだ。WordPressのバックグラウンド処理やCronジョブの多くはこの仕組みに依存しており、これが遮断されるとジョブは開始されないまま成功扱いになる。
ループバック障害を確認する方法
最初に確認すべきはWordPressのサイトヘルス画面だ。管理画面の「ツール」→「サイトヘルス」を開き、「ループバックリクエストを完了できません」という警告が出ていないか確認する。
サイトヘルスで警告を確認する手順
管理画面左メニューの「ツール」をクリックし、「サイトヘルストップ」を選択する。「ステータス」タブに表示される項目のうち、ループバックリクエストやREST APIに関する警告を探す。警告が複数ある場合は、それぞれの詳細をクリックして原因のヒントを確認する。
サイトヘルスにループバック警告が表示されていない場合でも、実際にはブロックされていることがある。特にCloudflareのプロキシを経由している環境では、サイトヘルスの診断はサーバー内部からのループバックのみを確認するため、外部経路の問題を見逃すことがある。
コマンドラインでループバックを手動確認する
サーバーにSSH接続できる場合は、curlコマンドでadmin-ajax.phpへのアクセスを確認できる。ただし単純なGETやPOSTでは移行ジョブのアクションが含まれないため、0が返ってきたからといってループバックが正常とは言い切れない。
より確実なのは、WP Statisticsの移行画面を開いたまま数分間待ち、カウンターが動くかを確認することだ。カウンターが一切動かない場合は、バックグラウンドリクエストがどこかで止まっていると判断できる。
WP-CLIで移行処理を直接実行する
ループバックのブロックを回避する最も確実な方法は、WP-CLIを使って移行処理をサーバー上で直接実行することだ。WP-CLIはWordPressのコマンドライン操作ツールで、HTTPリクエストを経由せずにPHPコードを直接実行できる。
WP-CLIがインストール済みか確認する
SSHでサーバーに接続し、WordPressのインストールディレクトリに移動して次のコマンドを実行する。WP-CLIのバージョン情報が表示されれば利用可能だ。
wp --infoコマンドが見つからない場合は、WP-CLIをインストールする必要がある。公式ドキュメントに従ってpharファイルをダウンロードし、実行権限を付ける方法が手軽だ。
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp移行ジョブを実行するPHPスクリプト
以下のPHPスクリプトをWordPressのルートディレクトリに保存する。ファイル名は「wps-run-jobs.php」など分かりやすい名前でよい。
<?php
// WP Statisticsの移行ジョブをWP-CLIで直接実行する
use WP_Statistics\Service\Database\Migrations\BackgroundProcess\BackgroundProcessFactory;
$keys = [
'visitor_columns_migrator',
'update_unknown_visitor_geoip',
'summary_totals_data_migration',
];
foreach ($keys as $key) {
$process = BackgroundProcessFactory::getBackgroundProcess($key);
if (!$process || !$process->is_queued()) {
WP_CLI::log("{$key}: キューがありません");
continue;
}
// バッチ処理を同期的に実行する
do {
$process->handle();
WP_CLI::log("{$key}: バッチ処理を実行中");
} while ($process->is_queued());
WP_CLI::success("{$key}: 完了しました");
}
スクリプトを保存したら、WordPressのルートディレクトリで以下のコマンドを実行する。
wp eval-file wps-run-jobs.php処理が開始されると、バッチ処理の進捗がCLI画面に表示される。データ量が多い場合は数分〜数十分かかることがある。最後に「完了しました」というメッセージが表示されれば移行は終了している。
WP-CLIが使えない場合の代替手段
WP-CLIをインストールできない場合は、管理画面から移行処理を再開する前に、問題を引き起こしている可能性の高い設定を一時的に無効化する方法がある。
まずCloudflareの管理画面で該当ドメインのプロキシを一時的にオフにする。もしくは「Speed」→「Bot Fight Mode」やファイアウォールルールでadmin-ajax.phpへのアクセスを許可する設定を追加する。セキュリティプラグインがサーバー自身のIPをブロックしていないかも確認する。
移行処理を再開できない場合の追加対処
上記の方法でも移行が進まない場合、WP Statisticsの状態が不正になっている可能性がある。プラグインが保存しているジョブの進捗情報をリセットして、最初からやり直す方法を取る。
ジョブの進捗情報をリセットする
データベースのoptionsテーブルには、移行ジョブのバッチ情報やプロセスロックが保存されている。これらを削除すると、移行処理を初期状態から再開できる。phpMyAdminやWP-CLIのdbクエリで以下のSQLを実行する。
DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_visitor_columns_migrator_batch_%';
DELETE FROM wp_options WHERE option_name LIKE '%wp_statistics_visitor_columns_migrator_process_lock%';
DELETE FROM wp_options WHERE option_name = 'wp_statistics_visitor_columns_migrator_status';
DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_summary_totals_data_migration_batch_%';
DELETE FROM wp_options WHERE option_name IN (
'wp_statistics_summary_totals_data_migration_total',
'wp_statistics_summary_totals_data_migration_processed'
);
DELETE FROM wp_options WHERE option_name = 'wp_statistics_jobs';SQLを実行した後、管理画面の移行画面に戻って「移行を開始」ボタンをクリックする。ただしこの方法はあくまで状態のリセットであり、根本的なループバック障害が残っていると再び0%で止まる。
Cronジョブの状態を確認する
WP Statisticsの移行処理はWordPress Cronからもトリガーされる。Cronが正常に動作しているか確認するには、管理画面の「ツール」→「サイトヘルス」でcron関連の警告を確認するか、サーバー上でwp-cron.phpを手動実行する。
curl -s "https://example.com/wp-cron.php?doing_wp_cron"URLの「example.com」は自分のサイトのドメインに置き換える。このコマンドでcronジョブが実行されるが、移行処理はcron経由でも結局はループバックリクエストに依存するため、ブロックされていれば動かない。
よくある質問
移行処理を実行しないまま放置してもサイトに影響はあるか
移行処理はバックグラウンドで安全に実行される設計のため、移行が完了していなくてもサイト自体は通常どおり動作する。ただし訪問者データの集計やGeoIP情報が最新化されないため、統計表示に誤差が出ることがある。
WP Statisticsのバージョンを更新しても移行が0%で止まるのはなぜか
プラグインのバージョンではなく、サーバー環境のネットワーク設定やファイアウォールが原因であることが多い。バージョンを更新してもループバックのブロックは解消されないため、同じ現象が続く。
Cloudflareのプロキシを無効化する以外の方法はあるか
Cloudflareのファイアウォールルールで、サーバー自身のIPからのadmin-ajax.phpへのアクセスを許可する設定を追加できる。もしくは「Bot Fight Mode」をオフにする、WP StatisticsのジョブをWP-CLIで実行するといった代替手段がある。
WP-CLIのスクリプト実行でエラーが出る場合はどうすればよいか
クラスの名前空間やメソッド名はWP Statisticsのバージョンによって異なる可能性がある。エラーメッセージを確認し、該当するクラスが存在するかPHPファイルを調べる。どうしても解決しない場合は、プラグインのサポートフォーラムに問い合わせる。
移行処理が途中まで進んで止まるのは別の原因か
0%から進まない場合はリクエスト自体のブロックが原因だが、途中まで進んで止まる場合はPHPの実行時間やメモリ制限が原因のことが多い。サーバーのタイムアウト設定やPHPのメモリ上限を引き上げると解決する場合がある。
この記事のポイント
- WP Statisticsの移行処理が0%で止まる主な原因はループバックリクエストの遮断
- サイトヘルスで警告を確認し、Cloudflareやファイアウォールの設定を見直す
- WP-CLIを使えばHTTPリクエストを経由せずに移行処理を直接実行できる
- 進捗情報をリセットしてから再試行する場合は根本原因の解消が先
- 移行処理が止まってもサイトの表示自体には大きな影響はない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている