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まわりのことを書いています。