WordPress 7.1で編集画面が変わる！更新前に確認したい新機能と注意点

スマホ表示を調整するためにCSSを書き、タブ表示のためにプラグインを増やす。そんな作業が、WordPress 7.1では編集画面の標準機能で減る可能性があります。一方、編集画面の仕組みが変わるため、古いブロックや管理画面用CSSを使うサイトは更新前の確認が欠かせません。

この記事では、運営者に影響しやすい新機能を「何が便利か」だけでなく「どこが壊れうるか」とセットで整理します。公開サイトへ直接ベータ版を入れず、バックアップとテスト環境を用意してから判断してください。

最大の変化はレスポンシブ設定を画面で扱えること

WordPress 7.1では、ブロックの見た目を画面幅に応じて設定するレスポンシブスタイルが進化しています。これまで追加CSSやテーマ機能へ頼っていた余白、文字サイズ、表示の調整を、グローバルスタイルや各ブロックから扱える範囲が広がります。

便利だからと既存CSSをすぐ削除してはいけません。テーマ側のブレークポイント、追加CSS、プラグインのスタイルと新設定が重なると、特定の幅だけ崩れることがあります。スマートフォン、タブレット、パソコンの代表的な幅で比較します。

タブとプレイリストでプラグインを減らせる可能性

タブブロックは、料金プラン、商品仕様、よくある質問など関連情報を切り替えて表示する用途に向きます。プレイリストブロックは複数の音声をまとめ、波形を表示できるため、ポッドキャストや講座にも使えます。

ただし「標準に入ったから既存プラグインを削除」と急ぐと、過去ページのショートコードが表示されなくなる場合があります。新規ページで標準ブロックを試し、既存ページは移行対象を一覧化してから変更します。タブ内の内容がキーボードで操作できるか、閉じたタブの文章が読み上げられるかも確認します。

画像編集とアクセシビリティが使いやすくなる

画像のインライン切り抜き、アップロードの安定性、メディア形式の扱いが改善されます。また画像ブロックには「装飾としてマーク」する設定が加わり、意味を持たない飾り画像をスクリーンリーダーから除外しやすくなります。

装飾設定は、説明を書くのが面倒な画像へ一律に使うものではありません。商品写真、操作画面、グラフなど本文理解に必要な画像には、内容を伝える代替テキストを付けます。背景模様や区切りの飾りだけを装飾として扱います。

古いブロックと管理画面CSSは重点確認

投稿エディターが常にiframe内で動く方向へ進むため、管理画面全体へ読み込ませたCSSやJavaScriptが編集キャンバスまで届かなくなることがあります。Block APIの古い方式で作られた独自ブロックも、開発元の対応状況を確認します。

• 編集画面だけに適用している独自CSS
• 長期間更新されていないブロックプラグイン
• ショートコードをブロックへ変換する機能
• 管理バーや投稿一覧を変更するプラグイン
• 画像圧縮、WebP変換、外部ストレージ連携

更新後に真っ白画面や500エラー、ログイン不能が起きた場合の切り分けは、WordPressの代表的なエラー対処手順を別端末から開けるようにしておくと安心です。

安全に更新する7ステップ

公式はベータ版を本番サイトや重要サイトへ入れないよう明記しています。正式版でも、公開直後に自動更新へ任せるかはサイトの構成で判断します。更新前の準備ができていれば、問題が起きても短時間で戻せます。

1. WordPress本体、PHP、テーマ、主要プラグインのバージョンを記録する
2. データベースとファイルを両方バックアップする
3. 復元手順と管理画面以外の接続方法を確認する
4. ステージング環境へ複製して更新する
5. トップ、記事、固定ページ、フォーム、検索、広告を点検する
6. スマホ、タブレット、パソコンで編集画面と公開画面を見る
7. 問題がなければアクセスの少ない時間に本番更新する

バックアップの範囲や自動更新の判断は、WordPressを安全にアップデートする方法で詳しく確認できます。更新ボタンを押す前に、戻す方法を用意することが最優先です。

公開画面だけでなく編集作業もテストする

更新確認ではトップページを一度表示して終わりがちです。しかし今回は編集画面の変更が多いため、新規投稿、既存記事の編集、画像アップロード、下書き保存、プレビュー、予約投稿まで一連の作業を試します。

特にCocoonなどテーマ固有ブロック、広告ブロック、ランキング、吹き出し、ブログカードを使う場合は代表ページを決めます。表示だけでなく、編集画面で選択・移動・複製・保存ができるか確認してください。問題があればスクリーンショット、ブラウザ、操作手順、エラーログを残すと開発元へ相談しやすくなります。

新機能を全部すぐ使う必要はない

レスポンシブ設定やタブが便利でも、既存サイト全体を一度に置き換える必要はありません。まず新規記事やテストページで使い、テーマとの相性、表示速度、操作性、検索エンジンが内容を理解できる状態かを確かめます。

プラグインを減らす場合も、機能一覧だけで判断せず、過去記事が依存していないか検索します。停止、キャッシュ削除、表示確認、削除の順に進め、いつでも元へ戻せるようにします。標準機能へ寄せる価値はありますが、移行の安全性が先です。

サイト別に変える更新判断

個人ブログで標準テーマと少数の有名プラグインだけを使う場合は、対応情報を確認したうえで比較的早く更新しやすいでしょう。それでもバックアップとフォーム送信は確認します。広告コードやアクセス解析が消えても公開画面だけでは気づきにくいため、ソースと計測も見ます。

企業サイトや予約・決済を扱うサイトは、営業時間外の更新、担当者の待機、ロールバック基準まで決めます。「軽微な表示崩れなら続行」「購入不能なら即時復元」のように、作業前に判断線を引くと現場で迷いません。

制作会社が管理するサイトでは、独自テーマと独自ブロックの対応確認が先です。管理者だけで本体を更新せず、保守契約と作業範囲を確認します。自動更新が有効でも、メジャー更新の扱いと通知先が正しいかを点検します。

更新後24時間で見るチェック項目

更新直後に正常でも、キャッシュの再生成、予約投稿、バックアップ、外部APIなど時間がたってから問題が出る機能があります。翌日にもう一度、エラーログ、フォーム受信、予約投稿、アクセス解析、広告表示を確認します。

• サーバーのPHPエラーログに新しい警告がないか
• 問い合わせメールが送受信できるか
• 予約投稿と定期処理が動いたか
• 画像最適化とキャッシュ生成が終わったか
• Search ConsoleやGA4のタグが残っているか
• モバイルでメニュー、タブ、フォームを操作できるか

問題が小さくても、発生ページ、端末、ブラウザ、操作手順を残します。次の更新で再発を防ぐ資料になり、テーマやプラグインの開発元へ正確に問い合わせられます。

よくある疑問

新バージョンの情報を見ると、すぐ更新すべきか待つべきか迷います。サイトごとに答えは変わりますが、判断の基準は共通しています。

ベータ版を本番へ入れてもよい？

入れないでください。公式もテスト・開発用途に限定し、重要サイトや本番環境で使わないよう案内しています。試すならステージング、ローカル環境、WordPress Playgroundなど、本番から分離した場所を使います。

正式版ならすぐ自動更新してよい？

正式版でも互換性確認は必要です。更新頻度が高い主要テーマ・プラグインの対応情報、バックアップ、復元方法がそろっているかで決めます。重要な販売日やキャンペーン中は避けるなど、事業上のタイミングも考えます。

新機能を使わなければ影響はない？

新ブロックを使わなくても、編集画面の基盤やメディア処理の変更は既存環境へ影響する可能性があります。公開画面だけでなく、既存記事を開いて保存する操作、画像追加、プレビューまでテストします。

まとめ：更新日は準備の締切ではなく確認日

更新作業の記録には、開始・終了時刻、担当者、バックアップ場所、更新した項目、確認したページ、発生した問題を残します。問題がなくても記録は必要です。次回の所要時間を見積もれ、前回との違いから新しいリスクを見つけやすくなります。

複数サイトを管理している場合は、一斉更新せず構成が単純なサイトから試します。そこで見つかった互換性問題を他サイトの事前確認へ反映します。同じテーマでもプラグインや追加CSSが違えば結果は変わるため、代表一サイトの成功だけで全サイトを安全と判断しません。

更新後に不具合がなくても、バックアップをすぐ消さないでください。通常の保存期間に従って保管し、個人情報を含む場合はアクセス権と暗号化も確認します。復元できないバックアップは保険にならないため、定期的な復元テストまで運用に含めます。

判断に迷うときは、更新を急ぐ理由と待つリスクを書き出します。安全性修正の有無、互換性情報、業務予定を比べれば、雰囲気ではなく根拠を持って日程を決められます。

WordPress 7.1は、レスポンシブデザイン、タブ、プレイリスト、画像編集、アクセシビリティなど、日常の制作を楽にする変更を含みます。その反面、iframe化された編集画面や古いブロックとの互換性は、カスタマイズの多いサイトほど確認が必要です。

公開日が来た瞬間に更新するのではなく、バックアップ、ステージング、代表ページのテストを済ませてから本番へ進みます。まずテーマと主要プラグインの対応情報を集め、編集画面用CSSや独自ブロックの有無を一覧にしてください。それだけで更新時の見落としを大きく減らせます。