WordPress「予約したイベントの実行に失敗しました」から始まる徘徊

先日の「永続オブジェクトキャッシュを使用してください」から始まる放浪の続編です。
あのあと「テーマは変えた」と投稿したのですけれど、時系列的にはその前になります。2024年の12月中旬のことです。

さて、前回は「WordPressのサイトヘルスで『永続オブジェクトキャッシュを使用してください』と出ていて対応した」という話でした。object-cache.phpによるAPCu導入、WPCodeプラグインインストール、サーバ側の高速化設定も調整などを行いました。
結果、サイトヘルスから「永続オブジェクトキャッシュを使用してください」との警告メッセージは消えたものの、新たなエラー「Page cache is not detected but the server response time is OK」が表示されるようになってしまいました。前回から残っているエラーもあります。

まずは「Page cache is not detected but the server response time is OK」というメッセージです。サイトヘルスの詳細を見てみます。

Page cache enhances the speed and performance of your site by saving and serving static pages instead of calling for a page every time a user visits.
Page cache is detected by looking for an active page cache plugin as well as making three requests to the homepage and looking for one or more of the following HTTP client caching response headers:
cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.
✔ Median server response time was 201 milliseconds. This is less than the recommended 600 milliseconds threshold.
❗ No client caching response headers were detected.
❗ A page cache plugin was not detected.

ビックリマークの項目に「ページキャッシュプラグインがない」と書かれています。前回のオブジェクトキャッシュ対応時に互換性への懸念からのオブジェクトキャッシュ対応時に互換性への懸念からWP Super Cacheを停止してたんだった。今回はちょっと別のものを試したい気持ちがあってWP Fastest Cacheにしてみた。ダメならWP Super Cacheに戻すつもりで試したら、「Page cache is not detected but the server response time is OK」のメッセージは消えてくれました。ここまで順調。

次のエラーメッセージは「予約したイベントの実行に失敗しました」。

予約したイベント wp_privacy_delete_old_export_files の実行に失敗しました。サイトは動作しますが、予約した投稿や自動更新は正しく動作しないかもしれません。

このメッセージは先日のオブジェクトキャッシュのときから出ていたものですが、対処を後回しにしていたのでした。
さてどうしたものか。内容からは、ページへのアクセス時に行われる疑似Cron的動作の一部が行われなかったということらしい。
調べてみました。

まず、「予約したイベントの実行に失敗しました」の解消方法。

WordPressをインストールしたそのままだと、wp.config.phpの属性値は400になっていると思います。
こちらを604に変更します。

パーミッションの変更ですね。オレの環境では、604にしても変化はありませんでした。

次に、【原因判明】サイトヘルスに「予約したイベントが遅れています」action_scheduler_run_queue の実行が遅延していますのアナウンス。
表示されているメッセージは若干違いますが、根っこは同じ問題なのではないかと推測。

パーミッションのグループに「読み込み権限」を与えないとダメっぽいです。※もしかしたら出たり出なかったりするかも・・？
つまり、640です。

今度は640でこっちも試してみる…が、やはり変化はありませんでした。

続いて、非表示予約プラグイン「PublishPress Future」がうまく動かない時に確認すること。こちらはタイトル通りのプラグインの挙動についての対策内容なのですが、確認事項の中にサイトヘルスのエラーがあって、同様のメッセージについて扱われています。

次の定義を wp-config.php に追加してみてください。
define('DISABLE_WP_CRON', true);

解説があります。

WP-CRONは、WordPressサイトへのアクセス時にスケジュールされたタスクをチェックして実行します。
しかし、トラフィック（サイト訪問数）が少ないサイトでは、タスク（自動的に実行される、タスク管理の内部システム）が適時に実行されないことがあります。
逆に、トラフィックが多いサイトでは、WP-Cronの実行がサーバーリソースに負担をかけることがあります。
このような理由から、define('DISABLE_WP_CRON', true); を使用することで、WordPressの内部スケジューラーであるWP-CRONを無効にし、サーバーのCronジョブでタスクを管理することができます。

ふむふむ。理にかなっているように思いますので、WordPressのファイルを直接いじるのは気が進まないながらもやってみました。
つづいて、WP Crontrolプラグインのインストール。間違えて別のWPControl（スペースがない）をインストールしてしまったりしたものの、最終的には有効化できました。で、問題の「wp_privacy_delete_old_export_files」を「今すぐ実行」してみました。その後で「このフックを一時停止」し、「このフックを再開」。いずれも問題なく行えたと思います。
… しかし残念ながら、こちらでも変化はなく「予約したイベントの実行に失敗しました」は表示され続けていました。

そのほか、DNS関係設定の再チェックでも特に問題は見つからず、PHPのアップデート（7.4.33から8.2.22）ではFatal errorが発生したので断念。PHPのバージョンは気になりますし上げたほうがいいのですけど、今回のサイトヘルスのエラーメッセージ問題では他に原因があると判断しました。PHPのバージョンが原因ならもっと普通にエラーが出てるはずですから。
ここまでかなり長時間にわたって色々と試しても解決できず、時間切れでこの日は断念。書き換えた設定だとかもすべて戻して一旦終了。

後日、改めてチャレンジしました。
頭を冷やして考えてみて、「WordPress内のWP-Cronを無効化してレンタルサーバのCronを使うように変更」がちゃんと最後までできていなかったので、これをやっていきます。
参考サイトは、以下。

まず wp-config.php の編集。これは前回も行っていて問題はありません。以下のコードを挿入するだけ。

define('DISABLE_WP_CRON', 'true');

続いて、レンタルサーバでのCron設定。これが前回にはできていなかったことです。
参考にさせていただいた【WordPress】パフォーマンスアップ！wp-cron.phpを停止しようではシェルスクリプトを噛ますことも書かれていてやや記述が混乱しているけれども、途中に書かれているようにCronコマンドでPHPファイルを直接指定してもいけます（PHPのパス・バージョン番号注意）。

/usr/bin/php7.3 /home/サーバーID/独自ドメイン名/public_html/wp-cron.php > /dev/null 2>&1

で、設定するにあたっての問題は、頻度ですよ。どのくらいの間隔で実行するのがいいのか。
【WordPress】パフォーマンスアップ！wp-cron.phpを停止しようの設定例では1日1回としています。
WP-Cronを無効化してWordPressサイトのパフォーマンスを改善する方法を解説の設定例は1時間に2回と1回。
WordPress WP-Cron を止めて OS層の Cron で実行する方法の設定例では5分間隔（5分経ったらに1回実行）。かなり幅があります。最後のWordPress WP-Cron を止めて OS層の Cron で実行する方法では

実行時間は5分だと細かいようにも見えますが、もともと（アクセスさえあれば）1分間に何回でも実行されていたわけなので、実行間隔が長すぎるとも言えます。この値は提供サイトの状況によって適宜見直しをしてください。

と至極真っ当な事が書かれています。そのとおりなんだよなー。
後で見直すことも前提にしてとりあえずは1時間に2回実行するよう設定してみました。すると、インストールしていたWP Controlプラグインの「Cronイベント」タブの表示内容が更新されて、イベントの実行予定時刻や頻度が表示されるようになりました。一番短い間隔のものでも1時間に1回となっていて、オレの環境ではそれ以上実行しても意味がないということなんだなと考えて一度は頻度を落としたものの、よく考えたら必ずしもそうではないですね。タイミングによってはタスクの実行までに最長1時間かかることもあるわけで、やはりここは1時間に2回は最低ラインだと思われます。ということで、1時間に2回で様子を見てみます。

ということで、レンタルサーバのCronを使ってWP-Cronを動かすようにしてからサイトヘルスを見てみると、「予約したイベントの実行に失敗しました」は消えていました！
（設定しただけで消えたのかCron実行後に消えたのかはわからなくなってしまいましたが。）
もともと何故「予約したイベントの実行に失敗しました」が出ていたのかもよくわかりませんでしたが、レンタルサーバのCronで確実に実行することでこのメッセージは撲滅できました。たぶん。
めでたしめでたし。

WP Controlプラグインはしばらくはそのままインストールしておきます。

また長々と書いてしまった…。

まとめ

WordPressサイトヘルスのエラー対応方法

「Page cache is not detected but the server response time is OK」＞WP Super CacheやWP Fastest Cacheなどのページキャッシュプラグインを導入する
「予約したイベントの実行に失敗しました」＞ WP-Cronを無効化してサーバのCronを使ってみる