WordPress 7.0.1 と 7.1 の React 19 — 自作テーマ・プラグインを今から通す準備

WordPressの管理画面に7.0.1の更新通知が出ている。ボタンを押す前に、次の7.1で自作テーマとプラグインが本当に壊れないかを確かめておきたい。筆者もSSHでログインしたまま、その手を一度止めた。

筆者は当サイトを含む実運用のWordPressサイトを、SSH＋WP-CLIで日常的に触っている。子テーマと自作プラグインを抱えている立場だと、保守リリースそのものより「その次のメジャーで足元が崩れないか」のほうが気になる。

今回は7.0.1を実際に当てたうえで、8月19日に控える7.1のReact 19移行に向けて、自作側で先に潰しておくべき点を洗い出した。

何が起きたのか
React 19の差し戻しが残した宿題
自作テーマとプラグインのどこが壊れうるか
開発者としての実践ポイント
よくある質問
まとめ
参考

何が起きたのか

WordPress 7.0.1は2026年7月9日に公開された保守リリースだ。中身はCore本体とブロックエディタを合わせた31個のバグ修正で、新機能は入っていない。

公式のリリース投稿にはReactの話は一行も書かれていない。純粋にバグを潰しただけの、当てても挙動が大きく変わらない種類の更新だ。

次のメジャーである7.1は、2026年8月19日のWordCamp USに合わせて予定されている。開発者が身構えているのはこちらのほうで、話題の中心はReact 19への移行になっている。

まず7.0.1を当てる作業自体は、WP-CLIなら数コマンドで終わる。筆者は更新前に必ず現状を確認してから当てている。

# コア更新が来ているか確認する
wp core check-update

# バージョンを明示して7.0.1へ更新する
wp core update --version=7.0.1

# 更新後にDBスキーマ側も合わせる
wp core update-db

# 更新が必要なプラグインを一覧で把握する
wp plugin list --update=available

ここまでは、いつもの保守リリースと同じ流れだ。問題はこの先にある。

React 19の差し戻しが残した宿題

7.1でReactを18から19へ上げる計画は、一度つまずいている。経緯を知っておくと、なぜ今テストしておくべきかが腑に落ちる。

Gutenberg 23.3が6月3日にReact 19を載せた。ところがReact 18を前提に書かれていた多くのプラグインがこれで動かなくなり、2日後の6月5日、Gutenberg 23.3.2で18へ差し戻された。

短命だった。

この失敗を受けて、コアチームは新しい進め方を出してきた。React 18と19を切り替えられる実験的なフィーチャーフラグを用意し、あわせて既存プラグイン向けの互換レイヤーも入れる、という段取りだ。だから7.1でReact 19が予定どおり載るかどうかは、今の時点では「planned」であって確定ではない。一度スリップして差し戻された経緯がある以上、鵜呑みにはできない。

レガシー企画の復活がやたら話題になる週だが、WordPressのReact移行で問われているのは後方互換をどう保つかという地味な一点だ。派手さはない。

開発者にとっての救いは、この移行を今すぐ手元で試せることだ。最新のGutenbergを入れ、設定の「Experiments（実験）」ページを開いて、「React 19」の実験を有効化する。これで自作コードがReact 19下でどう振る舞うかを、本番の7.1が来る前に確認できる。

自作テーマとプラグインのどこが壊れうるか

React 19下で自作側が引っかかりやすい箇所は、経験上いくつかに絞れる。ブロックエディタを拡張しているプラグインほど影響が出やすい。

筆者がまず見ているのは、ブロック関連のスクリプトが何に依存しているかだ。エディタ側のJSは`wp-element`など`@wordpress`系のハンドルに依存を宣言しておく。ここで生のReactを直接読みに行っていると、切り替え時に足をすくわれる。

<?php
// ブロックエディタ用スクリプトの登録例
wp_enqueue_script(
	'my-block-editor',
	plugins_url( 'build/index.js', __FILE__ ),
	// React本体ではなく wp-element を経由させる
	array( 'wp-element', 'wp-blocks', 'wp-block-editor', 'wp-components' ),
	filemtime( plugin_dir_path( __FILE__ ) . 'build/index.js' ),
	true
);

`@wordpress/element`はWordPressがReactを包んでいる抽象レイヤーだ。ここを通しておけば、コア側がReactのバージョンを差し替えても影響を吸収してくれる余地がある。自前で`react`や`react-dom`をバンドルして持ち込んでいる場合は、二重ロードや挙動差の温床になる。

具体的に見ておくべき観点を、切り替え前後で整理した。

チェック観点	React 18（現行）	React 19実験フラグON
非推奨React API	警告どまりで動く場合がある	削除済みAPIは実行時エラーになりうる
ブロックの再レンダリング	従来どおり描画される	エディタ画面でブロックが消える・崩れる例が出る
@wordpress/element依存	wp-element経由なら安定	wp-element経由なら互換レイヤーが吸収
自前バンドルのReact	とりあえず動く	二重ロードで警告・不整合が出やすい

とくに古いチュートリアルを写して書いたコードは要注意だ。`ReactDOM.render`のような書き方はReact 18の時点で非推奨になっていて、19では完全に消えた。エディタ画面でブロックが真っ白になる不具合は、たいていこの周辺から出てくる。

React 19で削除された書き方は、`ReactDOM.render`だけではない。文字列で書くref、関数コンポーネントに付けた`propTypes`と`defaultProps`、レガシーなContext APIも軒並み外れる。自作プラグインの管理画面マウント部分で引っかかりやすいのが、次のような旧式の書き方だ。筆者の環境にも、数年前に書いたこの手のコードが残っている。

// React 19では動かなくなる旧式の書き方
import { render } from '@wordpress/element';
import App from './App';

// createRootではなくrenderで直接マウントしている
render( <App />, document.getElementById( 'my-admin-root' ) );

// 文字列refは19で削除済み。実行時に落ちる
class Panel extends Component {
	render() {
		return <input ref="nameField" />;
	}
}

これを19対応の形に直すと、マウントは`createRoot`経由に、refは`useRef`か`createRef`に置き換わる。`@wordpress/element`は`createRoot`を再エクスポートしているので、生の`react-dom/client`を読みに行かずに済む。

// React 19で通る書き方
import { createRoot, useRef } from '@wordpress/element';
import App from './App';

const container = document.getElementById( 'my-admin-root' );
const root = createRoot( container );
root.render( <App /> );

// 文字列refはuseRefに置き換える
function Panel() {
	const nameField = useRef( null );
	return <input ref={ nameField } />;
}

筆者の自作プラグインでも、ブロックのエディタ側は`@wordpress/element`経由なので影響を受けにくい。危ないのは、数年前に別のチュートリアルを見ながら書いた設定画面のマウント処理のほうだ。同じプラグインの中でも、書いた時期によって当たり外れが分かれる。7.1の実験フラグを今のうちに有効化して、こうした箇所を先に洗っておきたい。

例えば、自作の商品紹介ブロックで`useState`と`useEffect`を使い、編集画面で入力値をプレビューに反映させているとする。React 18ではそのまま描画できていたものが、19だと副作用の実行タイミングの違いで初回のプレビューが空になる、という差が出ることがある。投稿を開いた瞬間だけ表示が抜けて、一度クリックすると直る。この手の「たまにおかしい」は、本番で踏むと原因の切り分けに時間を取られる。

実運用サイトでこれを本番当日に食らうと厄介だ。編集者から「ブロックが表示されない」と連絡が来て、更新直後だから原因の見当がつかず、切り戻すべきか調べるべきかで判断が鈍る。先に実験フラグで踏んでおけば、原因の当たりが最初からついている。この差は大きい。

互換レイヤーが用意されるとはいえ、それが自作コードの全パターンを吸収してくれる保証はない。互換レイヤーは既存プラグインの延命策であって、自作側のテストを省いていい理由にはならない。

開発者としての実践ポイント

7.0.1はステージング環境で当ててから本番へ。wp core update --version=7.0.1 の前に、必ずDBとファイルのバックアップを取る。保守リリースは基本安全だが、手順は横着しない。
最新のGutenbergを入れ、Experimentsページで「React 19」を有効化する。この状態で自作ブロックのエディタ画面を一通り開き、崩れる箇所をスクリーンショットで記録しておく。
自作JSの依存宣言を棚卸しする。array( 'wp-element', ... ) のようにwp-element経由になっているかを確認し、生のreactを直接読んでいる箇所を洗い出す。
非推奨React APIを検索する。ReactDOM.render・古いライフサイクル・レガシーなrefの書き方を全ソースからgrepし、React 19で消えたものに当たっていないか照合する。
ブロックの登録と描画を実機で通す。wp plugin status my-custom-plugin で有効状態を確かめつつ、投稿編集画面で保存・再読込まで往復して確認する。
結果をメモに残し、7.1公開後に再検証する。今の「planned」が本当に載るかは未確定なので、8月19日以降にもう一度同じ手順を回す前提でいる。

WordPressをコマンドラインで運用する具体的な流れは、ヘッドレスWordPressのデプロイ実例にまとめてある。今回のWP-CLI手順と合わせて読むと、更新から検証までの一連の動きがつかみやすい。

よくある質問

7.0.1はすぐ当てていいのか。

当てていい。中身は31個のバグ修正だけで新機能はなく、Reactのバージョンにも手を入れていない。React 19の話は次の7.1のロードマップ側にあって、7.0.1本体とは別件だ。ステージングでバックアップを取ってから当てる手順さえ守れば、挙動が大きく変わる心配はない。

7.1では確実にReact 19になるのか。

今の時点では「planned」で、確定ではない。6月にGutenberg 23.3が一度React 19を載せて多くのプラグインを壊し、2日で差し戻した経緯がある。コアチームは実験フラグと互換レイヤーで慎重に進める方針に切り替えた。7.1に予定どおり載るか、また先送りになるかは8月19日が近づくまで見えない。筆者は載る前提と載らない前提の両方で身構えている。

自作テーマは何を見ればいいのか。

最初に見るのはJSの依存宣言だ。`wp_enqueue_script`の依存配列が`wp-element`など`@wordpress`系のハンドルを経由しているかを確認する。次に`ReactDOM.render`・文字列ref・関数コンポーネントの`propTypes`を全ソースからgrepし、React 19で消えた書き方に当たっていないか照合する。最後に最新Gutenberg＋React 19実験フラグONの状態で、エディタと管理画面を一通り開いてコンソールエラーを見る。この三段で大半の地雷は先に踏める。