通常の投稿編集だけなら、WordPress 7.1への更新を過度に恐れる必要はありません。ただし、独自ブロック、エディター用CSS、編集画面を拡張する機能がある案件では、更新前に編集・保存まで確認する必要があります。
WordPress 7.1で何が変わったのか
WordPress 7.1では、投稿エディターの編集領域が常にiframe内で動作します。iframeは、管理画面の中に別のページを入れ子で表示するような仕組みです。内側の編集領域と外側の管理画面は、それぞれ別の文書とウィンドウを持ちます。
これまでは、テーマや本文内のブロックによってiframeになる場合とならない場合がありました。7.1では、テーマ形式やブロックAPIのバージョンにかかわらず、投稿エディターが常にiframeになります。WordPress公式は、多くのブロックは変更なしで動く一方、カスタムブロックやブロック拡張プラグインは完全にiframe化された投稿エディターで確認するよう案内しています。
影響を受けやすい実装
- 独自のカスタムブロック：編集領域の要素を、管理画面側のグローバルなdocumentやwindowから直接操作している。
- 編集画面の拡張機能：キャンバス内の要素へイベントを登録するボタンやパネルを追加している。
- エディター用CSS：管理画面全体の階層や、iframeの外側にある要素を前提にセレクタを組んでいる。
iframe内の編集キャンバスは管理画面側とは別のdocumentとwindowを持つため、グローバル参照では意図した編集領域を操作できない場合があります。公式が挙げる代表的な対応は、対象要素のownerDocumentとdefaultViewを参照すること、キャンバス要素のイベント登録と解除にuseRefEffectを使うことです。
ただし、独自機能があるから必ず不具合が起きる、という意味ではありません。実装内容を確認し、対象機能を実際に操作して判断します。
更新前は5段階で確認する
- 案件で使うカスタムブロック、編集拡張、エディター用CSSを一覧にする。
- 編集領域のDOM操作やイベント登録を行う箇所があるかコードを確認する。
- 本番外の確認環境へWordPress 7.1を適用する。
- 投稿・固定ページで、追加、編集、並べ替え、保存、再読込まで操作する。
- 問題箇所、修正内容、確認結果、本番での戻し方を記録する。
外注先へ渡す検収メモ例
架空の確認依頼
対象：カスタムブロック「お知らせバナー」、編集拡張「目次自動生成」
環境：本番ではなく確認用環境
操作：ブロックの追加・編集・保存・再読込、拡張ボタンの操作、編集画面の表示
報告：確認結果と、問題があった場合の修正箇所・戻し方
機能名だけでなく、どの環境で、どの操作を行い、何を報告するかまで書くと、発注側と実装側で検収条件をそろえられます。制作会社の既存チェックシートがある場合は、その更新項目へ追加すれば十分です。
既存の制作フローに合わせて確認できます
GreenCodingでは、制作会社・広告会社の既存フローやコーディング規約に合わせ、WordPressの既存テーマ調整、更新画面の構築、プラグイン・PHP更新、表示崩れの原因調査を支援します。独自ブロックや編集拡張の確認範囲、確認環境、本番反映後の読戻しまで、必要な工程だけご相談いただけます。
参考にした公式情報
- Make WordPress Core：Iframed Editor Changes in WordPress 7.1
- Make WordPress Core：WordPress 7.1 Field Guide
- WordPress Developer Resources：Editor styles
最終確認日：2026年9月15日。検収メモは説明用の架空例です。実際の確認対象は、案件のテーマ、プラグイン、独自実装に合わせて決めます。