WordPress 7.1では、投稿や固定ページを書く「投稿エディター」が常にiframe内で動くようになります。iframeと聞くと、ブログの記事表示やSEOまで変わるのでは、と身構えるかもしれません。
先に結論を言えば、今回の変更は主にWordPress管理画面の編集環境に関するものです。公開中の記事そのものをiframe表示にする変更ではありません。普通に文章を書き、画像やブロックを配置しているだけなら、仕組みを細かく理解する必要はありません。
ただし、テーマ独自ブロック、ブロック追加プラグイン、編集画面を拡張する機能を使っているサイトでは、WordPress 7.1への更新後に「いつもの投稿編集」が問題なくできるか確認しておく価値があります。
2026年8月18日時点：WordPress 7.1の公式リリース日は8月19日です。公式のRelease Day Processでは8月19日23:10 UTCから公開予定とされており、日本時間では8月20日8:10ごろに当たります。
WordPress 7.1で投稿エディターは常時iframe化する
WordPressは数回のリリースをかけて、ブロックエディターをiframe内で動かす仕組みへ移行してきました。サイトエディターやテンプレートエディターなどは、すでにiframeを利用しています。
WordPress 7.0の投稿エディターでは、記事内で使っているブロックのAPIバージョンなどに応じてiframeを使うかどうかが変わる互換性のための仕組みが残っていました。WordPress 7.1ではこの条件分岐がなくなり、テーマの種類や登録ブロック、記事内ブロックのAPIバージョンにかかわらず、投稿エディターは常にiframeで動きます。
古いメタボックスを登録しているサイトも含めて常時iframe化されるため、7.1は投稿エディター移行の一区切りと考えられます。
WordPress開発者向け資料では、iframe化によって管理画面側のCSSと記事編集領域のCSSを分離しやすくなり、表示領域に応じたCSSやメディアクエリも扱いやすくなることが利点として説明されています。
iframe化しても公開中のブログ記事がiframe表示になるわけではない
今回の「iframe」は、WordPressの投稿編集画面の中に、記事を編集するための領域を分けて持つための仕組みです。読者が見る公開ページをiframeに入れるという話ではありません。
そのため、一般的なブログ運営者が「iframe化したから検索順位が変わる」「公開ページ全体が別ページとして読み込まれる」と考える必要はありません。まず確認したいのは、公開ページよりも管理画面での編集操作です。
iframeの内側と外側では、JavaScriptが参照するdocumentやwindowが別になります。ここが今回の互換性問題の中心で、投稿エディター内部へ独自のJavaScriptやCSSで触れているテーマやプラグインでは調整が必要になる場合があります。
普通のブログ運営者で影響を確認したいケース
WordPress公式は、大半のブロックはiframe化されたエディターでも変更なしで動作すると説明しています。つまり、7.1へ更新したらすべてのサイトで投稿画面が壊れる、という性質の変更ではありません。
一方で、次のような使い方をしている場合は、更新後に投稿画面を一度確認しておくと安心です。
- テーマが提供する独自ブロックを日常的に使っている
- ブロックを追加・拡張するプラグインを使っている
- 投稿編集画面に独自の入力欄やメタボックスが表示される
- 子テーマや独自プラグインで編集画面用のCSS・JavaScriptを追加している
- 長く更新されていない古い独自ブロックや編集補助機能を使っている
特に「公開ページでは正常なのに、投稿画面だけ装飾が違う」「クリック操作が効かない」「独自ブロックの設定パネルが動かない」といった現象は、iframe化との互換性を疑う材料になります。
WordPress 7.1へ更新したら投稿画面で確認したいこと
専門的な検証をする必要はありません。WordPress公式のテストガイドも、普段と同じ使い方をテスト環境で再現することを勧めています。ブログ運営なら、新しい記事を1本書くつもりで操作するのが分かりやすい確認方法です。
- 既存の記事を開き、段落・見出し・画像などを編集できるか確認する
- 普段使うテーマ独自ブロックや追加ブロックを新しく挿入する
- ブロックの色、余白、表示設定などを変更し、編集画面へ反映されるか見る
- 下書き保存や更新を行い、再読み込み後も設定が残っているか確認する
- 公開ページを表示し、編集画面だけでなく実際の記事表示も崩れていないか確認する
問い合わせフォームや決済機能などがあるサイトでは別途その動作確認も必要ですが、iframe化の記事としては「投稿画面で普段使うブロックを編集できるか」を優先すれば十分です。
Cocoonなどテーマ独自機能は「いつもの編集」で試す
このサイトのようにCocoonを使っている場合も、WordPress 7.1のiframe化だけを理由に「Cocoonは使えなくなる」と考える必要はありません。今回確認できたWordPress公式資料でも、特定テーマに不具合が出るという案内ではなく、独自ブロックやブロックを拡張するプラグインの互換性確認を求めています。
実際の確認では、吹き出し、FAQ、ボタンなど自分が普段使っているCocoonブロックを1つずつ全部テストするより、日常の投稿でよく使うものを優先します。ブロックを挿入できるか、設定パネルが操作できるか、保存後も設定が残るかを見るだけでも、かなりの不具合を拾えます。
子テーマで編集画面向けのCSSやJavaScriptを独自に追加している場合は、標準的なCocoon利用より確認優先度が上がります。iframeの内外で参照先が分かれるため、以前は動いていた独自処理だけが影響を受ける可能性があるからです。
iframe化で問題が起きたときの切り分け方
WordPress 7.1への更新後に投稿画面だけがおかしくなった場合、いきなりWordPress本体の不具合と決めつけるより、どの機能で起きているかを切り分ける方が解決しやすくなります。
- 問題が起きるブロックや編集機能を特定する
- テーマと関連プラグインが最新版か確認する
- 可能ならステージング環境でプラグインを一つずつ停止して原因を絞る
- 独自CSS・JavaScriptを入れている場合は、それを外した状態でも再現するか確認する
なお、WordPress本体を更新する前にはバックアップを用意しておきます。WordPress公式ドキュメントでも、問題が起きた場合に復元できるようアップデート前のバックアップが案内されています。
リリース直前のRC版を試す場合は、本番サイトではなくステージングやテスト環境を使います。WordPress 7.1 RC4の案内でも、本番・重要サイトへ開発版を入れずテスト環境で評価するよう明記されています。
WordPress 7.1のiframe化についてよくある質問
- QWordPress 7.1で公開中の記事もiframe表示になりますか？
- A
いいえ。WordPress 7.1で常時iframe化されるのは投稿エディターの編集領域です。公開ページ全体をiframeへ変更する機能ではありません。
- Q普通にブログを書くだけでも何か設定変更が必要ですか？
- A
通常利用者がiframe用の設定を追加する必要はありません。更新後に、普段使うブロックの挿入・編集・保存が問題なくできるか確認しておくのが実用的です。
- QCocoonを使っているとWordPress 7.1で不具合が出ますか？
- A
今回確認した範囲では、WordPress公式はCocoon固有の不具合を案内していません。テーマ独自ブロックや編集画面を拡張する機能について、更新後にいつもの操作を確認するという考え方が適切です。
まとめ：更新ボタンより先に「普段の投稿編集」を確認する
WordPress 7.1のiframe化は、一般的なブログ運営者が新しい操作方法を覚えるための変更ではありません。投稿エディター内部の構造を統一し、ブロックやテーマを作る側にとって扱いやすい編集環境へ寄せていく変更です。
利用者側で大切なのは、テーマやプラグインを最新版にしたうえで、普段どおり記事を編集できるか確認することです。特にテーマ独自ブロックや編集画面のカスタマイズを使っているなら、バックアップを用意し、可能ならステージング環境で一度試してから本番サイトを更新すると判断しやすくなります。
コメント