WordPress 7.1 に上げた直後からサイトが真っ白になる、という報告が 8/20 から増えています。Elementor のフォーラムで犯人が WP Rocket なのか Elementor なのかで意見が割れていたので、手元で再現して確かめました。先に、やることだけ。
- WP Rocket を 3.23.2.2 に上げる。それからコアを 7.1 に上げる
- 3.23.2.1 では直らない。
.2まで上げる - すでに真っ白なら、
wp --skip-plugins plugin deactivate wp-rocketか FTP でwp-rocketフォルダを改名して先に復旧させる
やることは、上げる順番だけ
WP Rocket を先に上げてからコアを上げると、途中で一度も落ちません。Docker に WordPress 7.0.4 と WP Rocket 3.23.2 と Elementor を入れた状態から、順番だけを変えて両方向を測りました。
| 順番 | 途中の状態 |
|---|---|
| WP Rocket 3.23.2.2 → コア 7.1 | フロントもログイン画面もずっと 200 |
| コア 7.1 → WP Rocket 3.23.2.2 | コアを上げた時点で全ページ 500 |
問題は逆順のほうで、落ちた後に「じゃあ WP Rocket を上げよう」がもうできません。この不具合はページを表示する処理のいちばん最初で起きるので、プラグイン画面も wp-cli も同じところで止まります。
| 落ちた状態からやろうとしたこと | 結果 |
|---|---|
wp-admin/plugins.php を開く | HTTP 500 |
wp plugin update wp-rocket | 同じ例外で死ぬ |
wp --skip-plugins plugin list | これだけ通る |
つまり、プラグインを更新する手段が残りません。使えたのは --skip-plugins を付けて WP Rocket を止めるか、FTP でフォルダを改名するかの 2 つだけでした。WordPress には不具合を検知して復旧を案内する仕組みがありますが、今回は助けになりません。管理者宛にメールは届くものの、プラグインが自動で止まるわけではないので、そのメールのリンクを開くまでサイトは落ちたままです。
もう 1 つ、フォーラムでもまとめ記事でも「3.23.2.1 に上げれば直る」と流れていますが、これは効きません。GitHub のタグ同士で差分を取ると、3.23.2 との違いはバージョン文字列と翻訳ファイルのヘッダだけで、肝心のファイルは中身が一致していました。タグが切られたのも 7.1 が出る 9 日前です。上げるなら 3.23.2.2 まで上げてください。
落ちるのは 3 つ揃ったサイトだけ
WP Rocket を使っていれば全滅、という話ではありません。素の WordPress 7.1 に WP Rocket を入れただけなら、フロントもログイン画面も 200 のままでした。落ちるには 3 つ揃う必要があります。
- WordPress が 7.1
- WP Rocket が 3.23.2.1 以前
- 特定のフックにクロージャを登録している別のプラグインが有効
3 つ目で分かれます。手元で確認できたのは Elementor の無料版で、Pro は要りませんでした。Elementor 4.0.0 から入っているコードなので、4.2.2 でも 4.2.3 でも落ちます。フォーラムでは「4.2.3 で入った」「Elementor Pro が原因」という説が流れていましたが、どちらも当たっていません。Elementor 側は 5 か月前から何も変えていなくて、7.1 が出た日に初めて 500 になっただけです。
版ごとに並べるとこうなります。
| WordPress | WP Rocket 3.23.2 | 3.23.2.1 | 3.23.2.2 |
|---|---|---|---|
| 7.0.4 | 200 | 200 | 200 |
| 7.1 | 500 | 500 | 200 |
該当するのが Elementor だけとは限りません。wp.org の人気プラグイン 60 本を落として同じ書き方を探した範囲では Elementor だけでしたが、これは文字列を検索しただけで、Elementor の 2 か所すら最初の検索では引っかかりませんでした。「Elementor が入っていないから安全」とは読まないでください。
原因はコアがキーの作り方を変えたこと
ここだけ簡単に。WordPress はフックに登録された処理を配列で持っていて、その並びに付ける名前の作り方が 7.1 で変わりました。7.0 までは英数字混じりの文字列だったものが、7.1 からは数字だけになります。PHP は数字だけの文字列を配列の名前に使うと勝手に数値へ変換するので、名前が文字列である前提で書かれていたコードが型の不一致で止まります。WP Rocket の Cloudflare 連携がまさにそれで、Cloudflare を使っていなくても毎リクエスト走る場所にありました。
コアの差分を Claude に読ませたら、そういう読み解きが返ってきました。修正はその値を文字列に戻す 1 行だけで、3.23.2.2 に入っています。関数名やフック名まで含めた詳細を追いたい人は、WP Rocket 側の issue #8596 にコードごと出ています。
待ってもいいが、待つ必要もない
今すぐ手を入れられないなら、7.1 に上げずに待つこともできます。WordPress は最新版だけでなく 1 つ前の 7.0 にもセキュリティ修正を配っていて、7.0 の最新は 7.0.4 です。7.0.4 のままなら今回の不具合は起きません。
とはいえ待つ理由もありません。WP Rocket を 3.23.2.2 に上げる作業は、コアを 7.1 に上げるかどうかと関係なく、単独で先にできます。先に上げてしまえば、そのままコアも上げられます。3.23.2.2 を入れてからコアを 7.1 にする手順は、手元の環境でも実際のサイトでも、最後まで問題なく終わりました。
事前検査は止め、直した版では通した
最後に僕らのサービスでも同じ状況を通しました。検証用の WordPress に WP Rocket 3.23.2 と Elementor を入れて事前検査をかけると、複製した環境でコアを 7.1 に上げた時点で検査対象の 4 URL がすべて 500 になり、更新は本番へ出ませんでした。
WP Rocket だけを 3.23.2.2 に差し替えて同じ検査をかけ直すと、今度は通って本番のコアが 7.1 に上がりました。変えたのは版だけです。
自分のサイトが今どの版で止まっているかは、WordPress 年式診断に URL を入れれば出ます。