WordPress 7.0へ実際に更新してみた｜事前チェックから更新後確認まで
WP7.0が正式リリースされたので、実際の運用サイトを使って検証してみました。今回の目的は単純なアップデートではなく、
- 更新前に何を確認するべきか
- 更新後にどこを見るべきか
- 実運用サイトで問題が起きるのか
を観測することです。
目次
リリース前に確認した検証環境
環境は以下の通りで、エックスサーバーでの「一般的」な環境での検証になります。うちはドメインとかもちょこちょこ操作していますが、今回はWPの更新なのでデータベースとPHPのバージョンとかその辺だけの確認でも十分です。
| 項目 | 状況 |
|---|---|
| WordPress | バージョンは6.9.4（これから7.0にアップ） |
| PHP | 8.3.30 |
| データベース | MariaDB 10.5（WordPressはまだ10.6はリリース予定なし） |
| サーバー | Xserver |
| テーマ | TCD系（子テーマでカスタマイズ運用） |
| サイトヘルスチェック | 良好 |
条件としてはこのくらい調べておけば、まず1段階目の判断として「アップデートしても大丈夫？」がわかります。
PHPとデータベースの環境が、WordPress推奨環境（PHP Version 8.3以上・MariaDB 10.6+ or MySQL 8.0+.・HTTPS）と少し違いますが、テスト環境では動いてたので特に問題ないという判断で入れてみることにしました。
ただしこれは「10.5で完全保証される」という意味ではなく、あくまで今回の構成・プラグイン群・運用状態での検証結果です。実際の現場では、WordPress推奨値と国内レンタルサーバーの実環境に差があるケースも多く、その意味でも「事前観測」が重要だと感じました。
ヘルスケアチェック
WordPressにはサイトヘルスケアという機能があり、解決するわけではないんですがレポートを吐き出してくれる機能があります。この機能を使えば現在の健康状態をある程度わかります。
こんな感じで、「これを解決するととっても健康体になるよ！」って教えてくれる簡易診断書です。簡単に解説すると
| 表示内容 | 説明 |
|---|---|
| WordPressの更新が可能 | 言わずもがな、更新してください！ってメッセージです。 |
| 古いデータベースサーバー | これは環境がMariaDB10.5だから10.6以上にして！ってこと。 この辺はサーバーによって違いますが、この環境では手が出せないのでこのままです。 |
| 予約したイベントが遅れてます | こちらが、WP-Cronの設定に関してです。WPはCronってサイト内部の「時間管理・定期処理」を担当している系のものでそれによってWPの機能が動いているんでが、それが遅れがちだよって注意です。 今はWP標準のCronにしてますが、後でサーバー寄せにしようと思います。 |
| 永続オブジェクトキャッシュ | これは、WPが何度もDBにアクセスするので、その一部を「一旦記憶しておく」為の機能で、効果は高速化です。XserverにはRedis常駐型ってその機能を補填するものが無いし導入もできないので、放置です。そんなに緊急性はないです。 |
| ConsentAPIのところ | 最近よくサイト訪問時に見かけるCookieのことを聞くアレ（Cookie利用について確認する表示）の設定がまだなので、これはそのアラートです。同じく緊急性はないです。 |
私のサイトの簡易健康診断結果です（SWDではもうちょっと突っ込んだ健康診断を行います）。
大丈夫そうじゃないかな？と思うので思い切ってアップデートしてみます（ローカルでは確認ずみ）。
アップデート
アップデートは非常に簡単です。極端な話、大丈夫な環境である確認さえ取れていれば（これが大変なのですが）、ボタンを押したらコンニチワ状態です。ものの30秒くらいで終わりますが、確認には日々メンテしている状態でも30分くらいかかります。
動作確認
動作確認ができるということは、致命的なエラーが起きてないということ。便りがないのは良い便り。早速動作確認を行いますが、チェックするのは以下のような点を、それぞれのサイトのサービスに合わせて行います。
- 表示系
- トップページや固定ページ
- デザイン系
- ブログの表示
- フォームやショートコード
- ACFの表示漏れがないか
- デザイン系
- CSSがおかしくないか
- JSも組んだやつは動いてるか
- 編集画面は変じゃないか
- 機能系
- APIの接続は問題ないか
- ちゃんとフォームから狙った場所にメールが飛ぶか
- 本体系
- debug.logにログを記録しておくので、そこの内容
- サイトヘルスがちゃんと良好になってるか
- プラグイン大丈夫か
こんな感じの点をチェックして回ります。この時点でどこかに表示のエラーがある場合は適宜対処しますが、事前に調査して事故が起きそうな場所を把握しておけば何も怖くはないです。
私のサイトの場合は、注文や問い合わせを受けた際の記録台帳を外部に作っていてそこをAPIで繋いでいますので、そこの挙動や、カスタムテンプレートを使っているところや、自作のmu-plugin（必須プラグイン）の挙動が問題なければ、概ね問題ないだろうという判断でした。
最終的にどのチェック事項もクリアになったのでアップデートに関してはほぼほぼOKと言えるでしょう。
まとめ
WP7.0のアップデートは確かに環境によっては危険なこともあるかと思います。ですが、事前に環境を整えてアップデートに耐えうる健康状態を一度作ってしまえば、そこからのアップデートは自身でも不安なく行なっていけるようになります。
さらに、WP7.0以降はAIとの親和性も高くなっていくので、より構造をシビアに考えられている環境が求められる段階でもあります。この機会に是非、アップデートを備えた健康診断をご検討ください！
あとがき
7.0にアップデートした後、念のためにClaudeにfunctions.phpの状況を監視してもらって感想を聞いたら、「危険３箇所」「標準化からのズレ4箇所」「その他2か所」と、多分100点満点中60点くらいの指摘をされました。
言い訳ですが新機能追加した時に結構いじったからなあ。。まあ、毎日いじってたってこの位の点数つけられちゃうってことで🖐️さらに言えば、こういった「少しずつ積み上がるズレ」は、普段サイトが動いていると気付きにくいものでもあります。今回改めて感じたのは、「壊れてから直す」より、「壊れにくい構造へ少しずつ整える」ことが大事ですね。
はい！直しまーす！
この記事へのコメントはありません。