WordPress 7.1 が出てしばらく経ちました。今回のアップデートは、様子見している方が多い印象です。
というのも、リリース直後に WP Rocket(有料の定番キャッシュプラグイン)が致命的エラーを起こし、サイトが真っ白になったという報告が海外で相次いだからです。ああいうニュースを見ると、どうしても手が止まりますよね。
実際のところはどうなのでしょう。気になったので、日本でよく使われている定番プラグイン100個を WordPress 7.1 の環境に順番に入れて、動くかどうかを一つずつ確かめてみました。インストール、有効化、公開画面の表示、管理画面、アンインストールまで一通りです。
この記事はその結果の報告と、「何を確認してから上げればいいのか」のまとめです。
結論:上げて大丈夫。ただしプラグイン更新は先に
先に結論を書くと、7.1 に上げて大丈夫そうです。
検証した100個のうち、WordPress 7.1 が原因で壊れたプラグインはゼロでした。Contact Form 7、Yoast SEO、Elementor、WooCommerce といった大物から、WP Multibyte Patch や SiteGuard のような日本の定番まで、拍子抜けするくらい普通に動きます。
なお、この「ゼロ」は、インストールから公開画面の表示・管理画面・cron・アンインストールまでを確認した範囲での話です。ブロックエディターでの編集操作までは検証できていません。エディターを拡張するタイプのプラグインをお使いの方は、更新後に記事の編集画面も一度開いてみると安心です。
ただし例外が2つあります。どちらも古いバージョンのまま 7.1 に上げると壊れることが分かっているので、本体より先にプラグイン側を更新しておくと安心です。
| プラグイン | 安全なバージョン | 古いままだと |
|---|---|---|
| WP Rocket | 3.23.2.2 以降 | 公開画面が真っ白(致命的エラー) |
| WP Activity Log | 5.6.6 以降 | ログ画面を開くと「重大なエラー」 |
WP Activity Log の方は実際に踏みました。7.1 に上げた後にログ画面を開いたら「このサイトで重大なエラーが発生しました」。他の画面は無事なのに、そこだけ落ちる、という状態でした。
こういう「特定の画面だけ壊れる」パターンがあるので、後述のチェックでは管理画面も一通り開くことをおすすめします。
「7.1で未検証」の警告は、思っているほど怖くない
プラグイン一覧に「お使いのバージョンの WordPress では未検証です」と表示されると不安になりますが、これは作者が動作確認済みバージョンの申告を更新していないだけ、というケースがほとんどです。
今回検証した100個のうち51個がこの「未検証」状態でしたが、全部動きました。中には2年以上更新が止まっているプラグインもありましたが、それでも動くものは動きます。
もちろん「警告が出ていても大丈夫」の保証にはなりません。警告の有無で判断するより、実際に確認してみる方が早くて確実、というのが今回の実感です。
更新の順番と、終わった後に見るところ
手順自体はいつも通りです。
プラグインを先に最新化しておけば、先ほどの WP Rocket や WP Activity Log の問題は自動的に回避されます。
ひとつ付け加えると、PHP のバージョンアップを同時にやるのは避けた方が無難です。PHP 8.4 では非推奨の警告を出すプラグインがちらほらあり(動作はします)、本体更新と同時にやると何か起きたときの切り分けが面倒になります。別の日に分けると安心です。
本体を上げたら、次の3点を確認します。時間にして5分程度です。
- 公開画面 — シークレットウィンドウでトップページ、記事ページ、検索結果あたりを開く。真っ白になっていないか、「重大なエラー」が出ていないか。
- 管理画面 — ダッシュボードと、普段使うプラグインの設定画面をそれぞれ開く。画面上部にエラーや警告の帯が出ていないかも見る。一覧だけ見て安心しないのがコツです。
- 裏方の処理 — バックアップや SEO のサイトマップ生成、予約投稿など、cron で裏側が動くタイプは、その場では分かりません。数時間後か翌日に、実行ログや成果物(バックアップファイルの日付など)を確認してみてください。
いつ上げるか — 「何日待つか」ではなく「検証期間を設ける」
よく「メジャーアップデートはリリースから何日か待て」と言われます。ただ、今回100個を検証してみて感じたのは、この日数論はあまり本質的ではなさそうだ、ということです。何日待っても、自分のサイトで動くかどうかは分からないからです。
判断の軸は日数ではなく、2つあると考えています。「このサイトでアップデートを成功させた実績があるか」と「事前に検証できるか」です。
まず:今回のアップデートをどう実施するか
更新実績のないサイト(長らく上げていないサイト)は、手動で一度やり切るのがおすすめです。バックアップ、プラグイン更新、本体更新、そして5分チェック。大事なのは「自分の手で、見ている状態で」上げることです。何か起きてもその場で気づけますし、直前の操作が原因だとすぐ分かります。
検証環境(ステージング)があるサイトは、待つのではなく検証期間を設けるのがいいと思います。ステージングでの検証は数日かかるのが普通で、それは遅れではなく健全なプロセスです。「修正版を待つ」という判断が出てくるのは、検証で失敗した時だけです。
そのあとで:自動アップデートを有効化するか
自動アップデートの有効化は、今回のアップデートとは別の話です。「次回以降を自動に任せるか」という運用の選択で、手動で一度成功させた後に、初めて検討するのが自然な順序だと思います。一度成功したサイトなら、構成が「更新に耐える」ことを実証済みなので、未知のリスクで壊れる可能性は低いと言えます。
逆に、長らく更新していないサイトが、いきなり自動アップデートを有効にして済ませるのは、あまりおすすめできません。壊れる瞬間に誰も見ていないうえ、複数の更新が一気に走るので、どれが原因かの切り分けもしにくくなります。
そもそも自動アップデートは、アップデートを自動的に「解決」してくれる機能ではありません。自動的に「スケジュール」してくれる機能です。検証も復旧もしてくれません。実績のあるサイトの省力化には向いていて、放置サイトの救済には向かない、というのはそういう意味です。
手持ちのプラグインを調べたい人へ
今回の検証結果は、プラグイン名で検索できるページにまとめました。判定は「問題なし」「注意あり」「要対応」などのラベルで一覧できます。
PHP8.4の対応状況も分かります。
手持ちのプラグイン一覧を貼り付けると、一括で判定する機能も付けています。「要対応」があれば先頭に出るので、上げる前の確認にどうぞ。
最後にひとつ。検証の過程で、公式ディレクトリから閉鎖されて入手できなくなった「かつての定番」がいくつもありました。WP Social Bookmarking Light や Crayon Syntax Highlighter などです。
この手のプラグインが現役で入っているサイトは、7.1 がどうこう以前に、乗り換えを考えるいいタイミングかもしれません。アップデートは、そういう棚卸しのいい機会でもあります。7.1 自体は、怖がるようなリリースではありませんでした。