0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WordPress 7.0でプラグインが壊れる箇所、全部まとめ【保存版・7.1完全強制の前に】

0
Last updated at Posted at 2026-07-21

2026年8月に追記しました。7.1 が8月19日にリリースされ、この記事で「7.1で完全に強制される」と書いていた項目に答えが出たので、そこを書き直しています。追記箇所は3番の節と、末尾の「7.1で新しく見る箇所」「入らなかったもの」の2節です。

**iframe 化は、条件付きではなくなりました。**7.1 からは、テーマの種類にもブロックの API バージョンにも関係なく、投稿エディタは常に iframe の中で動きます。レガシーなメタボックスを登録しているサイトも例外ではありません。

7.0 に対応させようとして、どこから手をつければいいのか分からず、しばらく固まりました。変更が一箇所ではなく、あちこちに散っていて、全体像が見えなかったからです。

自分のプラグインを一通り対応させたので、見るべき箇所を一枚にまとめておきます。個別の詳しい対処は、それぞれ別記事へのリンクを置いています。

検証環境:【WordPress のバージョンと確認日を入れる】。7.1 の項目は 7.1-RC2 を Local の別サイト(テーマは Twenty Twenty-Two、Gutenberg プラグインなし)で確認したものです。最終的な挙動は、公式のフィールドガイドと自分の環境で確かめてください。

7.0 で影響を受けるのは、4つの箇所でした

REST API の権限チェックが厳しくなった。投稿一覧が React(DataViews)に変わった。エディタが iframe の中に入った。そして、クラシックなメタボックスが新しい編集体験と噛み合わなくなった。

上から順に、症状と対処の要点を書きます。

1. REST API の permission_callback が必須になった

いちばん多くの人が引っかかるのが、ここだと思います。

7.0 では、register_rest_routepermission_callback を省略すると、警告が出るか、ルートが正しく動かなくなります。今まで省略しても動いていたのが、動かなくなる。

// ❌ 7.0で問題になる:permission_callback がない
register_rest_route('myplugin/v1', '/data', [
    'methods'  => 'GET',
    'callback' => 'myplugin_get_data',
]);

// ✅ 明示する。公開APIなら __return_true、権限が要るなら current_user_can
register_rest_route('myplugin/v1', '/data', [
    'methods'             => 'GET',
    'callback'            => 'myplugin_get_data',
    'permission_callback' => '__return_true',
]);

公開してよいエンドポイントでも、公開してよいと明示的に書く必要があります。省略は、もう許されません。

詳しい書き方と、権限が要る場合の実装はこちら。

2. 投稿一覧が React(DataViews)になった

管理画面の投稿一覧が、従来の PHP で組むテーブル(WP_List_Table)から React 製の DataViews に置き換わりました。

影響を受けるのは、manage_posts_columns などでカスタムカラムを足していたプラグインです。PHP でセルの HTML を出す従来のやり方は、そのままでは効きません。見せたいデータを REST API 経由で読める形にして、React 側に拾わせます。

// カスタムカラムのデータは register_post_meta + show_in_rest で公開する
register_post_meta('post', 'my_score', [
    'show_in_rest' => true,
    'single'       => true,
    'type'         => 'number',
]);

HTML を足す、からデータを公開する、へ。発想が変わります。

カラムの出し方・フィルタ・グループ化の具体はこちら。

3. エディタが iframe の中に入った(7.1 で強制が完了)

ここが今回いちばん書き直した箇所です。

7.0 までは条件付きでした。投稿に挿入されているブロックの API バージョンが全部 3 以上なら iframe 化し、1つでも古いものがあれば iframe を外して互換性を保つ、という判定です。

**7.1 からは、その判定がなくなりました。**テーマがブロックテーマかクラシックテーマかにも、ブロックの API バージョンにも関係なく、常に iframe 化されます。レガシーなメタボックスを登録しているサイトも含めて、例外はありません。

不具合の原因は、ほぼ1つに集約されます。iframe が独自の documentwindow を持っていて、エディタスクリプトが動く管理画面とは別だからです。グローバルな documentwindow を掴んでキャンバスを触るコードは、全部違うドキュメントを見に行きます。

// ❌ iframe化で動かない:外側からエディタ内DOMを掴む
const el = document.querySelector('.editor-post-title__input');

修正の定石は2つ示されています。

ひとつは、キャンバス内の要素から ownerDocument と、その defaultView を辿ること。もうひとつは、イベントリスナの登録と解除に useRefEffect を使うことです。DOM を直接掴むのをやめて、エディタのデータ API を経由する方向は、7.0 のときと変わりません。

なお、Gutenberg プラグインの 22.6 以降はプラグインが有効なら強制的に iframe 化されるので、**7.1 を待たずに手元で再現できます。**検証だけ先にやりたいなら、こちらが早いです。

4. クラシックメタボックスが、同時編集を無効にする

7.0 では、複数人が同じ投稿を同時に編集する仕組みが入りました。ここに制約があります。クラシックなメタボックス(add_meta_box)がある投稿タイプは、その同時編集が無効になります。Classic ブロック(core/freeform)がある投稿も同様です。

つまり add_meta_box を使い続けると、その投稿タイプだけ新機能から外れる。対処は、メタボックスでやっていたことを register_post_meta + show_in_rest に移し、入力 UI をエディタのサイドパネルに置くことです。3番の iframe 対応と、これは同じ方向の作業になります。

add_meta_box の洗い出しから、パネルへの移行まではこちら。

7.1 で新しく見る箇所

ここからが追記です。7.0 の4つに加えて、7.1 で見る場所が増えました。

メディアまわり

画像処理の一部がブラウザ側で行われるようになりました。REST 側にも、寸法の検証、サイズごとのエンコード品質、1つのサイドロードファイルを複数の画像サイズとして登録する仕組みが入っています。

添付ファイルの生成や登録をやっているプラグインは、ここを確認してください。**自分の環境では、この変更を体感できませんでした。**画面上で何が変わったのか分からなかったので、確認できなかったものとして書いています。

メディアライブラリのグリッドは、無限スクロールが既定になりました。ユーザー単位で従来のページ送りに戻せます。メディア選択の UI を使っているなら、表示の確認を。

jQuery UI

1.14.2 に更新されました。jQuery UI の挙動やスタイルに依存している管理画面の UI があれば、テストが要ります。

Abilities API と AI Client

wp_get_abilities() にフィルタリングが入り、実行ライフサイクルのフック、public フラグの統一、クライアント互換の JSON スキーマが追加されました。加えて AI Client 側で execute_abilities()is_ability_call() を先に確認するよう変わっています。

ability を登録しているプラグインは、ここも見る対象です。

管理画面に「デザイン」が増えた

これは壊れる話ではありませんが、RC2 を触って一番目についたので書いておきます。

外観の下に「デザイン」という新しい管理画面が入りました。ブロックテーマだと Identity・スタイル・固定ページ・ナビゲーション・パターン・テンプレートの6項目で、Identity にサイトタイトル・キャッチフレーズ・サイトロゴ・サイトアイコンが集約されています。

余談ですが、**クラシックテーマでも「デザイン」画面は出ます。**手元の Cocoon で確認したところ、外観メニューは テーマ/デザイン/カスタマイズ/ウィジェット/フォント/メニュー/背景/テーマファイルエディター の並びになり、カスタマイザーは残ったままでした。ただしデザイン画面の中身は「スタイル」と「パターン」の2項目だけで、ブロックテーマで出る4項目はありません。

もうひとつ余談。RC 段階では日本語化が終わっていませんでした。Identity 画面が SITE TITLE / SITE TAGLINE のままで、固定ページ一覧の Drafts / Trash も英語。日本語版の RC パッケージ自体が配布されていないことと地続きの話だと思います。

入らなかったもの

構えていた側からすると、こちらも重要でした。

**Classic ブロックをインサーターから隠す変更は、取り下げられました。**議論とテストのあとで見送られたので、7.1 でも従来どおり使えます。React 19 への更新も見送られ、Gutenberg プラグイン側の実験として継続します。リアルタイム共同編集も、最終リリースには入りませんでした。

多くの解説記事は、入ったものしか扱いません。入らなかったものを知っておくと、不要な対応を減らせます。

確認する順番

対応したら、この順で見ます。

まず register_rest_route を全部見て、permission_callback があるか。次に manage_posts_columnsadd_meta_box を使っていないか grep する。あれば register_post_meta + show_in_rest への移行対象です。最後に、エディタ内の DOM を document.querySelector で掴んでいる JavaScript が残っていないか。

grep -rn "register_rest_route\|manage_posts_columns\|add_meta_box\|querySelector" ./

7.1 を足すなら、wp_get_abilities と、添付ファイルの生成まわりも見てください。

grep -rn "wp_get_abilities\|wp_insert_attachment\|media_handle_sideload\|jquery-ui" ./

まとめ

  • permission_callback は省略不可。公開 API も __return_true と明示する
  • カスタムカラムは PHP で HTML を出す方式が効かない。register_post_meta + show_in_rest でデータ公開
  • iframe 化は 7.1 で強制が完了。テーマ種別にもブロック API バージョンにも関係なく、常に iframe
  • 直し方は ownerDocumentdefaultView を辿る、リスナは useRefEffect
  • クラシックメタボックスがある投稿タイプは同時編集が無効。パネル + register_post_meta へ移す
  • 7.1 で増えるのはメディア処理、メディアライブラリの無限スクロール、jQuery UI 1.14.2、Abilities API
  • Classic ブロックの削除と React 19 は見送られた。対応は要らない
  • 洗い出しは register_rest_route / manage_posts_columns / add_meta_box / querySelector を grep

一つひとつは難しくないのですが、散らばっているのが厄介でした。この索引と grep のセットを、対応作業のあいだ開いておくと見落としが減ります。

そして、冒頭に戻ります。**iframe 化に条件が付いていた時期は終わりました。**7.0 のときに「うちのブロックは API バージョンが古いから、まだ iframe にならない」で先送りしていたなら、8月19日からはその逃げ道がありません。


ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?