WordPress 7.0にプラグインを対応させようとして、どこから手をつければいいのか分からず、しばらく固まりました。変更が一箇所ではなく、あちこちに散っていて、全体像が見えなかったからです。
自分のプラグインを一通り対応させたので、「7.0で見るべき箇所」を一枚にまとめておきます。7.1(2026年8月)で完全に強制される変更もあるので、その前に確認する索引として使ってください。個別の詳しい対処は、それぞれ別記事に書いたものへのリンクを置いています。
(※ 7.0まわりは開発中に仕様の変動がありました。最終的な挙動は、必ず公式のフィールドガイドと自分の環境で確認してください)
全体像：4つの箇所を見る
7.0でプラグインが影響を受けるのは、大きく次の4つでした。
REST APIの権限チェックが厳しくなった。投稿一覧がReact(DataViews)に変わった。エディタがiframeの中に入った。そして、クラシックなメタボックスが、新しい編集体験と噛み合わなくなった。
上から順に、症状と、対処の要点を書きます。
1. REST APIの permission_callback が必須に
いちばん多くの人が引っかかるのが、ここだと思います。
7.0では、register_rest_route で permission_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を出す従来のやり方は、そのままでは効きません。7.0では、見せたいデータを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 の中に入った
ブロックエディタが、iframeの中で動くようになりました。段階導入で、7.1で完全に強制されます。
iframeは外側のページとは別の文書なので、外から document.querySelector でエディタ内の要素を掴んでいたJavaScriptは、動かなくなります。null が返ってくる。エディタ内を触りたいなら、DOMを直接掴むのをやめて、エディタのデータAPI(@wordpress/data など)を経由します。
// ❌ iframe化で動かない：外側からエディタ内DOMを掴む
const el = document.querySelector('.editor-post-title__input');
// ✅ DOMではなく、エディタが管理するデータを経由する
DOMの位置に依存したコードは、この先も壊れやすい。位置ではなくデータで扱う、が前提になりました。
4. クラシックメタボックスが、同時編集を無効にする
7.0では、複数人が同じ投稿を同時に編集する仕組みが入りました。ここに制約があります。クラシックなメタボックス(add_meta_box)がある投稿タイプは、その同時編集が無効になります。Classicブロック(core/freeform)がある投稿も同様です。
つまり、add_meta_box を使い続けると、その投稿タイプだけ新機能から外れる。対処は、メタボックスでやっていたことを register_post_meta + show_in_rest に移し、入力UIはエディタのサイドパネルに置くことです。3番のiframe対応と、これは同じ方向の作業になります。
add_meta_box の洗い出しから、パネルへの移行まではこちら。
確認する順番
対応したら、この順で見ます。
まず、register_rest_route を全部見て、permission_callback があるか。次に、manage_posts_columns や add_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" ./
この4つの grep で、7.0で見るべき箇所は、だいたい洗い出せます。
早見でまとめ
- permission_callback は省略不可。公開APIも
__return_trueと明示する - カスタムカラムは PHP で HTML を出す方式が効かない。
register_post_meta+show_in_restでデータ公開 - エディタが iframe 化(7.1で完全強制)。外側から
document.querySelectorでエディタ内は掴めない - クラシックメタボックスがある投稿タイプは同時編集が無効。パネル + register_post_meta へ移す
- 洗い出しは
register_rest_route / manage_posts_columns / add_meta_box / querySelectorを grep
7.0対応は、一つひとつは難しくないのですが、散らばっているのが厄介でした。この4つと grep のセットを、対応作業のあいだ開いておくと、見落としが減ります。役に立ったらストックして、7.0/7.1対応のとき手元に置いてください。
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。