WordPress 7.0 に備えて今チェックしておくこと — PHP 要件・FSE 移行・エディタ拡張の 3 つの論点

過去のメジャーアップグレードで実際に起きた事故 5 パターンの末尾に「同じ構造が次のメジャー（7.0 や 8.0）でも別の形で再現する」と書きました。今回は WordPress 7.0 を射程に置いて、今のうちに確認できる 3 つの論点を整理します。

7.0 が出る前にチェックリストを持っておくことが目的です。W1 の事前確認 7 項目に加えて、7.0 固有の文脈で準備できることを補完する形で読んでください。

論点 ① — PHP 最小要件の引き上げ（W3 パターン 3 の再現）

W3 のパターン 3 は「PHP 最小要求引き上げで古いプラグインが構文エラー」でした。これはメジャーアップグレードのたびに繰り返される汎用パターンで、WP 7.0 でも同じ構造で出てくると予想されます。

現状の背景:

PHP 7.4 は 2022 年 11 月に PHP 本家のアクティブサポートが終了（セキュリティ修正も 2023 年末で終了）
WordPress 6.6 の時点で PHP 7.2 以上を要求
WP 7.0 では PHP 8.0 以上への引き上げが方向性として議論されている

これが実際に起きると、PHP 7.x 系で動かしているサーバー上の古いプラグインやテーマが「今まで問題なかったのにアップグレード後に構文エラーで落ちる」という症状になります。

今のうちにできること:

# サーバーの PHP バージョン確認
php -v

# プラグインの更新状況確認（Tested up to が古いものを洗い出す）
wp plugin list --fields=name,version,update,update_version --format=table

# PHP 8.x 環境でプラグインリストが正常取得できるか確認
wp plugin list --format=json

特に注意が必要なのは「PHP は上げられるが、Tested up to が古いプラグインを残している」という中間状態です。PHP 8.0+ に対応していないプラグインがあると、コア更新と同時に壊れます。

PHP 8.2+ と WP-CLI の組み合わせで出る Deprecated 警告が JSON 出力を汚染する罠も、PHP 要件引き上げの文脈で出やすい副作用です。アップグレード前に確認リストに入れておく価値があります。

論点 ② — FSE（Full Site Editing）の主流化とテーマ移行（W3 パターン 4 の深化）

W3 のパターン 4 は「6.0 FSE 移行期に子テーマのカスタマイズが効かなくなる」でした。6.x を通じて FSE と Block Theme は着実に標準の位置に移ってきており、7.0 ではこの移行がさらに進む方向にあります。

現状の整理:

WordPress 5.9（2022 年）で FSE / Block Theme が正式導入
6.x 系でブロックテーマの機能・ドキュメントが整備され、Classic Theme は「使えるが、新機能の恩恵を受けにくい」状態に
WP 7.0 では Block Theme が主要な標準となり、Classic Theme の扱いが「レガシー」に近づく可能性

これが保守現場で意味するのは、Classic Theme のまま 7.0 へアップグレードする選択肢は「今すぐ壊れるわけではないが、今後のテーマ更新やプラグイン互換性でジワジワ摩擦が増す」という構図です。

今のうちにできること:

管理しているサイトのテーマが Classic か Block かを把握する
bash wp theme list --status=active --format=table # style.css に "block-templates/" ディレクトリがあれば Block Theme
Block Theme への移行が必要なサイトを優先度付けして識別する
子テーマでカスタマイズが深いサイトの「移行コスト」を事前に見積もる

「コア更新とテーマ移行を同タイミングでやらない」という分離が重要です。7.0 のコア更新を当てることと、Classic → Block Theme を移行することは別の判断として扱うべきです。一緒にやると、問題が起きたときの切り分けができなくなります。

論点 ③ — Gutenberg Phase 3（協調編集）でエディタ拡張が再び影響を受ける（W3 パターン 1 の継続）

W3 のパターン 1 は「5.0 Gutenberg 移行でクラシックエディタ前提の UI 拡張が一斉に消えた」でした。Gutenberg の開発は段階的に進んでいて、Phase 3（協調編集・リビジョン管理強化・データライブラリ）の完成に伴って、エディタ周辺の拡張プラグインがまた影響を受ける構造になっています。

協調編集（複数人が同時に記事を編集できる）は、エディタの状態管理モデルを根本から変えます。5.0 の Gutenberg 移行と同様に、エディタの DOM 構造やデータフローを前提としているサードパーティ拡張が、Phase 3 の UI 変更で動作しなくなるリスクがあります。

今のうちにできること:

エディタ拡張系プラグイン（カスタムメタボックス・カスタムフィールド UI・エディタサイドバー拡張等）の使用状況を把握する
bash wp plugin list --status=active --format=table # エディタ拡張系を手動でリストアップする
主要ベンダーが Phase 3 対応を表明しているか確認する（Advanced Custom Fields / Pods / Meta Box 等）
Phase 3 がコアに入ったタイミングで影響が出る可能性があるプラグインを、代替候補と並べてリスト化しておく

注意点として、「協調編集を使わないからといって影響を受けない」わけではありません。Phase 3 でのエディタ内部 API の変更は、協調編集を使わないサイトのプラグインにも影響することがあります。

今のうちにできること — 3 項目まとめ

論点	今すぐできる確認	対応が必要になるタイミング
PHP 要件引き上げ	`php -v` + `wp plugin list` で Tested up to 棚卸し	PHP 8.0+ 必須が正式発表されたとき
FSE 主流化	テーマが Classic か Block かの識別 + 移行コスト見積もり	7.0 リリース発表時に「Classic は引き続き使えるか」を確認するとき
エディタ拡張影響	エディタ拡張プラグインのリストアップ + ベンダー対応状況確認	Phase 3 コア統合の前後

3 つに共通しているのは「7.0 が出てから始めると間に合わないことがある」という点です。PHP 要件の引き上げでプラグインを差し替えるには代替調査と検証の時間が必要です。テーマ移行はコンテンツとデザインの両方に影響する大きな作業です。エディタ拡張の問題は、移行先のプラグイン自体がアップデートを出すまで待つ必要があります。

W4 の段階的な実行手順と組み合わせると、「準備ができたサイトから順番に当てる」分散戦略が取れます。全サイト一斉に 7.0 を当てるのではなく、リスクプロファイルの低いサイトで先行検証してから本番サイトに展開する ── W2 の段階適用判断軸と合わせて読むと、7.0 の適用計画が立てやすくなります。

まとめ — W シリーズ全体の関係

記事	テーマ
W1 = 何を確認するか	アップグレード前チェックリスト 7 項目
W2 = いつ当てるか	x.0.1 を待つ判断軸 5 つ
W3 = 何が起きうるか	過去の事故 5 パターン
W4 = どう当てるか	WP-CLI 実行コマンドと確認ポイント
W5 = 7.0 に備える	3 つの論点と今のうちにできること ← 本記事
W6 = 更新後に確認する	アップグレード後の動作確認 7 ステップ

W3 のパターン知識が最も役立つのは「事故が起きてから使う」ではなく「次のメジャーが来る前に使う」タイミングです。7.0 のリリースアナウンスが出てから動き始めると、プラグイン棚卸しもテーマ移行の調査も、リリースまでの時間で終わらないことがあります。アップグレードの準備は、リリース発表の前が最も効率的に動ける時間です。