WP-Cronを置き換える前に、WordPressの予約投稿の遅れを調べる方法

予約した記事の公開が遅れたからといって、新しい予約投稿プラグインが必要とは限りません。まずWordPressにタスクを動かす機会があったか、実行が失敗したか、サイトのタイムゾーンでは本当に公開時刻に達していたかを確認します。これらは異なる問題で、修復方法も異なります。

WordPressのcronハンドブックは、WP-Cronがシステムのスケジューラーのように常駐せず、ページの読み込み時に予定タスクを確認すると説明しています。アクセスの少ないサイトは重要な手掛かりです。ただし、設定や実行の失敗も調べる必要があり、訪問が少ないことだけで今回の遅れの原因とは断定できません。

本来起きるはずだったことを確定する

記事の予約日時、サイトのタイムゾーン設定、遅れに気付いた時刻を記録します。寄稿者のノートパソコンの時計だけでは、サイトが意図した公開時刻の証拠になりません。編集者が複数の国にいる場合は、どの時計で公開を管理するか合意し、編集チェックリストに明記してください。

次に記事が下書き、承認待ち、非公開ではなく、予約状態のままだったか確認します。最後の編集と関係するワークフロープラグインを調べます。承認待ちの記事はcronの失敗ではありません。手動公開の前に予定されていた状態を残し、応急処置で診断に必要な情報を消さないようにします。

仮に静かな週末の朝に公開予定の記事を考えます。その後最初の訪問に合わせて公開されたなら、起動機会の不足が考えられます。ほかの予定タスクは時間通りで、この記事だけ失敗したなら、記事や処理関数に範囲を絞ります。何かを導入する前に、対立する説明を書き出してください。

タスクを動かす前に一覧を確認する

公式のテストガイドには、イベントの一覧表示と実行に使うWP-CLIコマンドがあります。技術担当者は正しいサイト環境で、読み取り専用のwp cron event listから始められます。キューを削除したり実行したりせず、関連するフック、予定時刻、繰り返し間隔を特定します。

一般的な診断の近道として、期限が来たイベントをすべて実行しないでください。プラグインによってはメール送信、アクセス更新、記録の同期など、影響のある処理が含まれます。特定イベントを手動で動かす前に、その役割、別経路で実行済みかどうか、結果をどう確かめるかを確認します。

予定時刻の前後のアプリケーションやホスティングのログとキューを比較します。対象処理のエラー、リソース制限、完了しなかったリクエストを探します。一覧にあることは予定の存在を示すだけで、コールバックが正常に完了できる証拠ではありません。すべてをcronの問題と呼ばず、具体的なエラーを記録してください。

起動方法と代わりのスケジューラーを確認する

通常のページ読み込みによる起動か、外部スケジューラーかをホストや担当者に尋ねます。WordPressはシステムスケジューラーへの接続を説明しており、外部の仕組みを整えてから通常の起動を無効にする手順が含まれます。無効化だけをコピーすると、代わりがない状態になります。

外部ジョブがある場合は、サイトのパスやURL、実行ユーザー、間隔、最近の結果を確認します。ステージング向けの設定があっても本番を扱う証拠にはなりません。コマンドが開始したという報告も、WordPressが対象イベントまで進んだ証明ではありません。正しい環境での完了記録を求めてください。

認証、セキュリティ制御、ネットワーク制限が具体的な起動方法を妨げていないか調べます。最初の実験でファイアウォール全体を止めないでください。担当者は対象のリクエストを切り分け、根拠がある場合に狭い例外を試せます。戻せる手順を保ち、その例外で実際の失敗が変わるか記録します。

一つの層を修復し、実際の予約で試す

証拠が起動不足を示すなら、負荷に合い、ホストが対応する定期実行方法を決めます。コールバックが失敗するなら、頻度を増やすのではなく担当するプラグインや連携を直します。壊れたタスクを何度も動かせば、記事を公開できずに負荷だけ増えることがあります。原因ごとに対処は異なります。

適切な環境で、通常の低リスクな予約記事を使って試し、編集上の結果と実行記録の両方を確認します。本番で試すなら、公開に適した内容で通常の承認を得てください。見える成功を作るためだけに、偽の記事を公開してはいけません。

訪問の少ない時間帯を含め、複数回の予定実行を観察します。変更後に同じイベントが二重実行されていないかも確認します。旧設定、新設定、次回の確認担当を保守記録に残してください。修復は、作業した人がいなくなっても機能し続ける必要があります。

プラグインや設定を変える場合はステージングとロールバックの手順を使います。定期的な保守作業には、予約公開の小さな確認を加えてください。目指すのは編集上の予約から正常な実行までの経路を把握し、次の遅れを素早く調べられる証拠を持つことです。