2026年8月19日、WordPress 7.1 が正式公開された。コードネームは Mary Lou。800人超の貢献者による1,500件以上の改善が入っている。公式告知は投稿エディタの iframe 化について for all themes と書いた。当サイトは7月15日の Beta 1 の回で、これを「全テーマ・無条件」と書いている。予測を書いた記事には精算の回が要るので、10件ぶん並べて数えた。
目次
突き合わせ先は告知の原文で、dev note ではない
先に、この記事がどこまでの材料で書かれているかを書いておく。突き合わせたのは正式リリースの告知ページの原文で、ブロック開発者向けの dev note や移行ガイドの本文ではない。告知文は読者全般に向けた要約なので、書かれていないことが「入っていない」を意味しない。判定の列に「決められない」を用意してあるのは、この材料の限界に合わせたからになる。
取得の方法も書いておく。要約を返すツールを通すと、原文に無い限定が付いて戻ってくることがある。今回は告知ページを Markdown に変換して手元に落とし、該当語で検索して該当行を逐語で読んだ。iframe を含む行は告知全体で1行だけだった。
The post editor is now fully iframed for all themes, matching the Site Editor.当サイトの本番は本稿の時点で 7.1 に上げていない。書けるのは告知の読み方と、何をどこで確かめるかまでになる。
7.1 に入ったもの
| 変更 | 中身 | 子テーマを自分で書いている人への当たり方 |
|---|---|---|
| エディタの iframe 化 今回の焦点 | 投稿エディタが全テーマで完全に iframe 化され、サイトエディタと揃う | テーマ形式に関係なく当たる。管理画面側に注入していたエディタ用 CSS の届き方が変わる |
| 画面サイズごとのスタイル指定 | グローバルスタイルとブロック設定から画面サイズ別のスタイルを指定できる。ブロックテーマは theme.json で独自のブレークポイントを定義できる | 子テーマの @media と守備範囲が重なる。ブレークポイントの上書きはブロックテーマ限定 |
| 管理バーが全エディタに常駐 | 投稿編集でもサイト編集でも管理バーが付いてくる | 管理画面をカスタマイズしている場合、表示位置の前提が変わる |
| 新しい画像エディタ | 自由変形と比率指定のクロップ、水平・垂直の反転、回転、メタデータ編集を1つの画面に集約 | 画像を手で切る運用があれば当たる。生成済み画像を上げる経路では出番が薄い |
| ブラウザ内での画像処理 | 圧縮・リサイズ・サムネイル生成が libvips の WebAssembly ビルドでブラウザ側に移る。AVIF・HEIC・HDR ゲインマップに対応 | PHP のメモリ上限とアップロードのタイムアウトを踏みにくくなる |
| インラインノート | リッチテキストと @メンションに対応。ブロック単位でなくテキスト選択単位で注記できる | 複数人で下書きを回しているサイト向け。1人で書いているなら当たらない |
| 新ブロック2つ | Playlist と Tabs。Icon ブロック用のアイコンセットを登録する API も追加 | コアブロックなので apiVersion の心配は要らない |
| 規模 | 800人超の貢献者による1,500件以上の改善と修正。うち170人超が初参加 | 告知に個別に出てこない改善が大半を占める。差分は自分の画面で見るしかない |
beta1 で書いた予測を1件ずつ精算する
Beta 1 の回で挙げた懸念と、beta3 の回で持ち越した項目を並べて、告知の原文と突き合わせた。外した予測を黙って落とすと、次に同じ書き方で外す。
| # | beta1・beta3 で書いたこと | 正式版の告知 | 判定 |
|---|---|---|---|
| 1 | iframe 化はテーマ種別を見ない（クラシックテーマにも当たる） | fully iframed for all themes |
当たり |
| 2 | apiVersion に関わらず常に iframe。フォールバックは廃止 | 告知が書いたのは適用範囲だけで、apiVersion にもフォールバックにも触れていない | 決められない（告知の材料では判定できない） |
| 3 | 適用範囲は「ブロックテーマのみ」に軟化する可能性があり、確定は RC 時点の dev note 待ち | 軟化していない。全テーマのまま出た | 外れ（留保したほうが外れた） |
| 4 | FAQ「クラシックテーマだから無関係では」に対して「関係はある。iframe 化はエディタ本体の話でテーマ種別を見ない」と答えた | テーマ種別を見ない書き方で確定 | 当たり |
| 5 | 棚卸しの結果、block.json を持つのは Contact Form 7 の1つで apiVersion 3。当サイトは「待つ側」 | 告知に個別プラグインの記述なし | 未実測（正式版で同じ1行を回す） |
| 6 | クライアントサイド画像処理（wasm-vips）に乗ったかを window.__clientSideMediaProcessing で見る |
圧縮・リサイズ・サムネイル生成が libvips の WebAssembly ビルドでブラウザ側へ | 当たり（フラグ名の確認は未実測） |
| 7 | theme.json の viewport 指定で、子テーマ style.css の @media 15個のうち何個を減らせるか続報を書く |
画面サイズ別スタイルが入った。ブレークポイントの上書きはブロックテーマ限定 | 未実測（クラシックテーマでは上書きできない見込みが新たに判明） |
| 8 | 新ブロックは Playlist と Tabs の2つ | Two new blocks, Playlist and Tabs |
当たり |
| 9 | Notes は太字・リンク・絵文字・@メンション対応、テキスト選択単位のインライン注記 | リッチテキストと @メンション、太字・斜体・コード・リンク、テキスト選択単位の注記まで逐語で確認 | 当たり（絵文字だけは告知に記載が無く未確認） |
| 10 | Unicode メールアドレス対応は 7.1 に含めない（beta3 の回） | 告知に記載なし | 決められない |
当たり5件、外れ1件、未実測2件、決められない2件。数えてみると、外したのは断定した側ではなく留保した側だった。
2行目を独立させたのは、beta1 の1文に3つの主張が入っていたからになる。「apiVersion に関わらず」「常に iframe」「フォールバックは廃止」は別々に検証できる主張で、告知が確定させたのは適用範囲だけだ。3つまとめて当たりにすると、確かめていない2つが当たりの数に紛れ込む。予測を書くときは、後から1つずつ判定できる粒度に割っておくほうがいい。
3行目で「ブロックテーマのみに軟化する可能性がある」と書いたのは、beta1 の時点で他所の記事にその読み方が出ていたからになる。両論を並べて「確定は dev note 待ち」と逃げ道を作った形が、今回は外れとして残った。断定した1行目のほうが当たっている。留保は誠実さの担保になるが、当てにいく力を弱める。7.0.3 の修正12件を数え直した回で「原文の箇条書きを数えた」と手順ごと書いたのと同じで、根拠を書いておけば後から精算できる。精算できる形にしておくことと、当てにいくことは別の話だった。
「全テーマ」を「ブロックテーマだけ」と読み違えると、作業の量を見誤る
ここは筆者が実際に踏みかけた落とし穴なので、そのまま書いておく。告知を読み込む工程で、いったん「iframe 化にブロックテーマの限定が付いた」という結論を立てた。7.1 の告知には「ブロックテーマ」という限定語が確かに出てくる。ただしそれが付いているのはレスポンシブブレークポイントの項で、iframe の項ではない。限定語だけを拾って、隣の機能の条件を持ってきていた。
Block themes can now define their own mobile and tablet breakpoints in theme.json,
overriding the defaults for responsive styles and block visibility.読み違えたまま書いていたら、クラシックテーマで運用している当サイトは「無関係」の側に入り、エディタ用 CSS の確認をまるごと省いていた。iframe 化はテーマ形式を見ないので、省いた分がそのまま抜けになる。
防ぎ方は単純で、限定語を含む文を機能ごとに逐語で切り出すことになる。今回は Markdown に落として iframe と block theme でそれぞれ検索した。前者は1行、後者は1行、別々の行だった。1つのページに複数の機能が並んでいるときは、見出しの所属で判定する。語が近い位置にあることは、同じ機能の説明である根拠にならない。
それでも wp_is_block_theme() は1回叩く価値がある
iframe 化はテーマ形式を見ないので、この判定は iframe のためには要らない。要るのは7行目のほうで、theme.json でブレークポイントを上書きできるかがここで決まる。
# 有効なテーマがブロックテーマかどうか
wp eval 'var_dump( wp_is_block_theme() );'
# 有効なテーマの名前とバージョン
wp theme list --status=active --fields=name,version
# ブロックテーマはテンプレートを HTML で持つ
ls wp-content/themes/<有効なテーマ>/templates/
ls wp-content/themes/<有効なテーマ>/theme.json当サイトは親テーマ MAG と子テーマ mag_tcd036_child のクラシックテーマ運用で、beta1 の回でもそう書いている。false が返る側なら、子テーマ style.css の @media 15個を theme.json へ移す話は今回は成立しない。移せないと分かれば、その調査に時間を割かずに済む。判定コマンドを 7.1 の環境で実際に走らせた結果は、本稿には載せていない。
iframe の内側に届かなくなるもの
iframe 化されたエディタで何が起きるかは、beta1 の回に書いた内容から変わらない。ブロックが管理画面側の document へ手を伸ばせなくなる。window や document をグローバルに参照しているコードと、enqueue_block_editor_assets で管理画面側に注入していたエディタ用 CSS が、キャンバスの内側に届かなくなる。
適用範囲が全テーマで確定したので、この確認はクラシックテーマ運用でも省けない。当サイトのように自作ブロックを持たない場合、当たるのは使用中プラグインの側で、対応はプラグイン側の仕事になる。それでも「プラグインが対応済みか」を確かめるのは自分の仕事として残る。棚卸しを書いた beta1 の回と確認の優先順位を付けた beta3 の回は、どちらも「先に数える」ところまでは正式版でもそのまま使える。
何をどこで確かめるか
確認する場所を3層に分ける。ローカルの検証環境、本番の CSS スナップショット、本番そのもの。上の層で済むものを下の層でやらない。
| 確かめること | どこで | 見るもの | 判定 | 状態 |
|---|---|---|---|---|
| エディタ用 CSS の届き方 | ローカル（Playground か検証環境に 7.1） | enqueue_block_editor_assets で読ませている CSS がキャンバス内に当たるか |
当たらなければ block.json 側へ移す | 未実測 |
| block.json の棚卸し | 本番のファイル一覧（読み取りのみ） | block.json を持つプラグインと apiVersion | v2 以下が出たら直す側、v3 だけなら待つ側 | 未実測 |
| 子テーマの表示崩れ | CSS スナップショット | snapshot_site_css.py で取り直したうえで check_contrast.py |
AA 割れが新たに出るか | 未実測 |
| theme.json のブレークポイント | ローカル | wp_is_block_theme() の戻り値 |
false なら上書きは使えない。@media 15個の移設は見送り |
未実測 |
| クライアントサイド画像処理 | ローカル | ブラウザのコンソールで window.__clientSideMediaProcessing |
値が取れるか。取れなければ従来のサーバー処理側 | 未実測 |
| 画像アップロード | ローカル | 生成されたサイズ違いの一覧と EXIF 回転 | サイズが揃うか、回転が二重にかからないか | 未実測 |
| 本文リンクの生存 | 本番（更新した場合のみ） | check_links.py |
200 以外が出ないか | 未実測 |
本番へ当てるかどうかは、本稿の時点で決めていない。beta3 の回に書いたとおり、当サイトは正式版を当日には当てず、報告が出そろってから上げる形を取っている。当てる場合の順番も同じで、データベースとファイルのバックアップを先に取り、記事の単一ページ・一覧ページ・カスタマイズした管理画面の3画面を見る。
# 検証環境に 7.1 を入れて確かめる（本番では実行しない）
wp core update --version=7.1
wp core version
# block.json を持つプラグイン・テーマと apiVersion を並べる
find wp-content/plugins wp-content/themes -name block.json -maxdepth 4 \
-exec sh -c 'echo "$1"; grep -o "\"apiVersion\"[^,]*" "$1"' _ {} \;棚卸しの1行は beta1 の回で使ったものと同じで、正式版で回し直す価値がある。beta1 の時点の結果は 7.0.2 環境のもので、以降にプラグインを増やしていれば数が変わる。
新機能のうち、子テーマ持ちに実際に降ってくるもの
新機能を並べて紹介する形は取らない。子テーマを自分で書いている立場で、手が動くものだけを見る。
画面サイズごとのスタイル指定は、子テーマの style.css と守備範囲が重なる。beta1 の回で数えたときは @media が15個あり、内訳は max-width 600px 系が7個、管理画面境界と同じ 782px 系が3個、残りが5個だった。ブレークポイント自体の上書きがブロックテーマ限定になったので、クラシックテーマ運用の当サイトでは移設の検討そのものが成立しない可能性が高い。ブロック単位のスタイル指定がクラシックテーマでどこまで効くかは、告知文からは決まらない。
ブラウザ内での画像処理は、当サイトのアイキャッチ添付には当たらない。set_featured.py は PNG を SFTP でサーバーの /tmp へ置いてから、SSH 越しに wp media import を叩いている。ブラウザも WebAssembly ランタイムも経路上に存在しないので、圧縮とサムネイル生成はこれまでどおりサーバー側の処理を通る。ブラウザ側へ移るのは、管理画面のメディアアップローダから人が上げた分だけになる。
自由変形の画像クロッパーは、画像を手で切っている運用に効く。当サイトは切る工程が入らないので、降ってはくるが使わない側になる見込みでいる。
インラインノートは、下書きを複数人で回すサイト向けの機能だ。1人で書いているなら当たらない。React 19 まわりの準備を7.0.1 の回で先取りしておいたので、エディタ側の新機能でつまずく箇所があるとすれば、そこは自作コードより使用中プラグインの側になる。
Playlist と Tabs はコアブロックなので、apiVersion の心配は要らない。beta1 の回に書いた理屈がそのまま通る。
一次ソース
- WordPress 7.1「Mary Lou」リリース（WordPress News・公式） — 2026年8月19日
関連記事
- WordPress 7.1 Beta 1 公開 — 自サイトのブロックを1行で棚卸しする
- WordPress 7.1 Beta 3 と正式版までの3週間 — 子テーマ持ちがやる確認
- WordPress 7.0.1 と 7.1 の React 19 — 自作テーマ・プラグインを今から通す準備
- WordPress 7.0.3 の修正は箇条書きで12件 — 前提条件で並べ直した
まとめ
今日やる価値があるのは、告知の該当1行を自分の目で読むことだ。iframe を含む行は告知全体で1行しかなく、そこに for all themes と書いてある。クラシックテーマだからと確認を省くと、エディタ用 CSS の届き方の変化をそのまま踏む。
wp_is_block_theme() は別の理由で1回叩く。theme.json のブレークポイント上書きが使えるかがそこで決まり、false なら @media の移設を検討せずに済む。
予測を書いた記事には、精算の回が要る。10件のうち当たりが5件、外れが1件。外れた1件は、両論を並べて「確定待ち」と留保した行だった。留保は根拠を残すためには要るが、それ自体は当たりを増やさない。
未検証のまま残したこと。本番も検証環境も 7.1 に上げていないので、エディタ用 CSS の届き方・block.json の棚卸し・theme.json のブレークポイント・クライアントサイド画像処理・画像アップロードはいずれも未実測になる。突き合わせ先は正式リリースの告知原文だけで、dev note と移行ガイドの本文は読めていない。表の判定のうち「決められない」の2件は、根拠が別々になる。2行目は告知が別の軸（適用範囲）しか書いていないため、10行目はそもそも言及が無いため。どちらも dev note と移行ガイドの原文を読めば当たり外れに移る可能性がある。9行目の絵文字対応も、告知に記載が無いだけで否定はされていない。
