先に、壊れやすい場所から書きます。WordPress 7.0（2026年5月リリース）は、5.0以来いちばん変更の大きいバージョンです。プラグイン作者にとって、特に壊れやすいのは次のあたりでした。
- 管理画面の一覧をカスタムしている（DataViewsがWP_List_Tableを置き換え）
- REST APIの
permission_callbackを省略している - 古いメタボックス＋エディタのiframe化
- カスタムブロック（React 19 / Block API v3）
- PHP 7.4未満のサーバー
自分もWordPress.orgにプラグインを出しているので、7.0が来たとき、まず自分のプラグインを上から順に点検しました。この記事は、その確認の観点と対処です。（2026年7月時点。最終的には公式のフィールドガイドで確認してください）
1. 管理画面の一覧カスタム（DataViews）
いちばん影響が大きいところです。7.0で、投稿・固定ページ・メディアの一覧が、従来のWP_List_Table（PHPで組まれた静的テーブル）から、React製のDataViewsに置き換わりました。
壊れやすいのは、この一覧に手を入れているプラグインです。カスタムカラムの追加、独自のフィルタ、一括操作をWP_List_Table系のフックで足している場合、そのまま効くとは限りません。とくに、JavaScriptで一覧のDOMを読んでいた（tr のIDを拾う、.editinline のクリックを監視する等）コードは、行が従来の静的な tr ではなくなったので壊れます。
確認：投稿・固定ページ・メディアの一覧で、自分のカラムやフィルタが出ているか、クイック編集まわりが動くかを見ます。
対処：データを見せたいだけなら、register_post_meta で show_in_rest => true を付けて登録すると、React側のUIが自然に読めます。
register_post_meta('post', 'my_meta_key', [
'show_in_rest' => true,
'single' => true,
'type' => 'string',
]);
クイック編集のJSは、.editinline のクリック監視ではなく、コア側のフック（inlineEditPost 等）に乗せ替える。凝ったカスタムは、DataViewsの拡張APIに寄せていくのが本筋です。なお、DataViewsの groupByField（文字列）は groupBy（オブジェクト）に変わっています。ここを使っている場合は要修正です（当面は旧プロパティが警告つきで通ることもあるので、自分の環境で確認を）。
2. REST APIの permission_callback
見落としやすいのに、はっきり壊れます。7.0は、REST route の permission_callback の指定に厳しくなりました。省略すると doing_it_wrong の通知が出て、リクエストが弾かれることがあります。
対処：公開エンドポイントなら __return_true、権限が要るなら current_user_can() を明示します。
register_rest_route('my-plugin/v1', '/data', [
'methods' => 'GET',
'callback' => 'my_callback',
'permission_callback' => '__return_true', // 公開データの場合
]);
「今まで省略しても動いていた」箇所ほど、ここで引っかかります。自分のプラグインでも、まずは全ルートの permission_callback を見直しました。
3. 古いメタボックス＋iframeエディタ
7.0で、投稿エディタのiframe化が段階的に始まりました（完全な強制は7.1・2026年8月の予定）。エディタの外側（wp-adminのDOM）にアクセスしていたブロックやスクリプトは、iframeの内側からは届かなくなるので、順次壊れます。
加えて、クラシックなメタボックスを付けた投稿タイプは、リアルタイム共同編集が無効になります。これは不具合ではなく、意図した制約です。
対処：.wp-admin セレクタや、エディタ外のDOMを直接触っているコードは、移行を検討します。メタデータは、メタボックスではなく register_post_meta ＋ show_in_rest の形に寄せると、新しいデータ層に乗れます。
4. カスタムブロック（React 19 / Block API v3）
7.0でブロックエディタがReact 19に上がり、Block API のバージョン3が前提になっていきます。独自ブロックを持つプラグインは、エディタ内での表示や挙動をテストしておきます。
確認：自分のブロックが、7.0のエディタで崩れず編集できるか。register_block_style を core/heading に対して当てている場合、見出しがH1〜H6の個別バリエーションに分かれた影響で、一部のレベルに効かないことがあります。
5. PHP 7.4未満のサーバー
7.0の最低要件はPHP 7.4です。7.2・7.3のサーバーには、そもそも7.0の更新が降ってきません（6.9系のセキュリティ更新に留まります）。推奨はPHP 8.3以上です。
確認：自分の環境と、プラグイン作者ならREADMEの「Requires PHP」を見直します。利用者の環境はまちまちなので、下限を上げるなら告知とセットで。
確認の順番（まとめ）
- 管理画面の一覧に手を入れている → DataViewsを最優先で確認
- REST route を持っている →
permission_callbackを全部見直す - エディタ外のDOMを触るJS・古いメタボックス → iframe化に備えて移行
- 独自ブロック → React 19 / Block API v3 でテスト
- Requires PHP → 7.4以上になっているか
自分のように小さいプラグインでも、7.0は「どこか一つは引っかかる」規模の変更でした。いきなり本番を上げず、ステージングで上から確認するのが安全です。役に立ったらストックして、7.0対応のとき見返してください。
参考（公式）:
- WordPress 7.0 Field Guide: https://make.wordpress.org/core/2026/05/14/wordpress-7-0-field-guide/
ふだんはraplsworks.comで、WordPressプラグイン開発やClaude Codeまわりのことを書いています。