WordPress 7.1へ更新するときは、更新ボタンを押す前に、現在の構成を記録し、複製環境で普段使う操作を一通り試します。バックアップがあるだけでは、編集画面の崩れやフォームの不具合までは見つけられません。テーマ、プラグイン、独自実装、PHPの組み合わせを確認し、本番で問題が出たときの戻し方まで決めてから更新します。
最初に現在の構成を記録する
確認表には、WordPress本体、使用中テーマと子テーマ、必須プラグイン、PHP、データベースの各バージョンを書きます。停止中のプラグインも、削除せず残しているなら対象です。独自のコードを子テーマ、Code Snippets、mu-pluginsなどへ追加している場合は、保存場所と役割も記録します。更新前後の差が追えるため、不具合の原因を切り分けやすくなります。
本番と同じ複製環境で試す
WordPress公式は、更新前のバックアップと、プラグインを含む更新手順を案内しています。実務では、ファイルとデータベースを複製したローカル環境やステージング環境を用意し、そこで先に7.1へ更新します。PHPやテーマだけが本番と異なる環境では、合格しても本番の安全を十分に示せません。キャッシュや画像最適化など、表示へ影響する機能もできるだけ揃えます。
編集画面と独自ブロックを重点確認する
WordPress 7.1のField Guideでは、投稿エディターのiframe化、レスポンシブなブロックスタイル、管理画面やアクセシビリティの改善などが案内されています。特に、編集画面へ独自CSSやJavaScriptを読み込むテーマ・プラグイン、古いBlock APIを使う独自ブロックは確認が必要です。既存ページを開くだけでなく、段落、画像、ボタン、カラム、再利用している独自ブロックを新しく追加し、保存後に再編集します。
- 既存記事を開いたときに警告やブロックエラーが出ないか
- 新規追加、複製、並べ替え、削除ができるか
- 編集画面と公開画面で余白や文字サイズが一致するか
- パソコンとスマートフォンの指定が意図どおり反映されるか
- 管理者以外の担当者権限でも必要な操作ができるか
サイトの主要動線を一件ずつ通す
トップページを見るだけでは不十分です。問い合わせフォームをテスト送信し、確認画面、完了表示、通知メールまで確認します。検索、カテゴリー、パンくず、メニュー、PDFや画像の表示、外部予約先へのリンクも対象です。会員機能や購入機能がある場合は、テスト用の手順を決め、実データや決済を動かさない範囲で確認します。エラーログとブラウザの表示だけでなく、実際の担当者が普段行う操作を基準にします。
更新順は一度にまとめすぎない
WordPress本体、テーマ、全プラグイン、PHPを同時に変えると、問題が出たときに原因を絞れません。まず複製環境でバックアップを取り、更新前の状態を記録します。そのうえで、保守方針に沿って変更単位を分け、各段階で主要ページと管理画面を確認します。セキュリティ修正など急ぐ更新でも、確認項目を省くのではなく、対象を絞って短時間で判断できる表を準備しておきます。
戻せることを実際に確かめる
バックアップは、保存されているだけでなく、復元できて初めて役立ちます。ファイルとデータベースの取得日時、保管先、復元担当者、必要なログイン情報の保管方法を確認します。複製環境で復元テストを行い、どこまで戻るか、作業にどの程度の手順が必要かを記録します。本番更新中に追加された問い合わせや投稿を失わないよう、更新時間帯と差分データの扱いも決めます。
本番更新後も同じ確認表を使う
複製環境で合格しても、本番のキャッシュ、サーバー設定、外部サービスとの接続で差が出ることがあります。本番更新後は、HTTPエラー、トップと主要ページ、フォーム、編集画面、スマートフォン表示を同じ順番で確認します。異常があれば、追加更新を重ねず、直前の変更とログを確認して復元判断をします。GreenCodingでは、WordPress更新前の複製確認や、更新後に続けられる点検手順の整理に対応しています。状況に合わせた確認範囲はお問い合わせからご相談ください。