WordPress 7.2ロードマップ公開。Beta 1は10月20日、wp_kses再構築も注目
WordPress 7.2の開発ロードマップが公開された。2026年最後のメジャーリリースとなる7.2は、Beta 1が10月20日、RC1が11月17日、正式版が12月8日に予定されている。
9月にはWordPress 7.1.1から7.1.3まで、3回のセキュリティリリースが続いた。7.1.1は11件、7.1.2は緊急の1件、7.1.3は7件のセキュリティ修正を含む。自動更新で対処済みなら問題ないが、更新を止めているサイトがある場合は先に済ませておきたい。
この記事では、開発者向けに発表された情報の中から、Web制作会社やプラグイン・テーマ開発者に影響する項目を絞って解説する。
WordPress 7.2のロードマップが公開、Beta 1は10月20日
WordPress 7.2は2026年最後のメジャーリリースだ。ロードマップでは、セキュリティ、ブロックとAPI、デザインツール、管理画面、メディアとパフォーマンスの5分野にわたって、現在進行中の項目が示されている。
ただし、ロードマップに載っている項目はすべて「開発が進められているが、最終版に入るとは限らない」と明記されている。プラグインやテーマを配布している開発者は、Beta 1からRC1までの約4週間で互換性を確かめておきたい。
- セキュリティはアプリケーションパスワードの改善、非HTTPS環境の検出、SameSite Cookieのサポートなどが候補に並ぶ
- ブロックでは説明リストの新ブロック、目次ブロックのサーバーサイドレンダリング移行、アイコンブロックのキーワード検索などが進む
- デザイン面はカスタムブロック状態、グローバルスタイルでのフォーム要素対応、ブロックサポートの拡張などが対象
- 管理画面は拡張可能なサイトエディタ、DataViewsとDataFormsの改良、管理バーとメニューのDashicons置き換えが候補
- メディアとパフォーマンスはダイナミックギャラリー、クライアントサイドメディア、スクリプトとスタイルの連結をプリフェッチへ置き換える作業が含まれる
ロードマップの中でも、プラグインやテーマの互換性に直結しやすいのがブロックサポートの拡張とDashiconsの置き換えだ。Beta 1のタイミングでテスト環境を用意し、管理画面の表示崩れや独自CSSとの衝突を確認するとよい。
セキュリティと管理画面まわりの注目点
セキュリティ分野では、アプリケーションパスワードの改善や非HTTPS環境の検出、SameSite Cookieのサポートなどが候補に挙がっている。SameSite Cookieとは、ブラウザーが別サイトへのリクエストにCookieを自動送信しないよう制御する仕組みだ。ログインセッションを狙った攻撃への対策として関心が高い。
管理画面では、サイトエディタの拡張性を高める作業、DataViewsとDataFormsの改良、管理バーと管理メニューで使われてきたDashiconsの置き換えが進められる。DashiconsはWordPressに組み込まれてきた管理画面用のアイコンフォントで、今回の置き換えは表示の一貫性とカスタマイズ性を高める狙いがある。
React 19と共同編集は7.2に入らない見込み
ロードマップにはReact 19へのアップグレードも載っているが、「WordPress 7.2には完全には入らない可能性が高い」とされている。共同編集機能も今回は意図的にロードマップから外された。開発チームはサーバー側の状態を軸にしたアプローチへ移行する理由を別途説明している。
AI関連ではAbilitiesやMCPアダプターの作業が進むが、これらは専用プラグインとして提供される。コア本体への組み込みは今回の対象外だ。
wp_kses()がHTML APIベースで再構築、出力と互換性に変化
wp_kses() はWordPressが投稿内容などをサニタイズ（無害化）する際に使う関数だ。不正なスクリプトや危険なタグを除去する、サイトの安全を支える部品の1つである。その wp_kses() がHTML APIの上に再構築される計画が明らかになった。7.2か7.3での導入が目標で、テスト結果次第で判断される。
新しいパーサーは、出力するマークアップの表記を正規化し、scriptとstyle要素の中身を除去する。さらに、不正な形式のSVG、MathML、コメントの一部を拒否する。プラグインやテーマでサニタイズ結果を比較したり、保存したり、テストしたりしている場合は、trunkバージョンでの動作確認が必要だ。
この変更でHTMLの加工結果が変わる可能性があるため、比較テストやスナップショットテストを導入している開発者は注意したい。新しいパーサーが自分のHTMLにどう影響するかは、専用のテストツールでも確認できる。HTMLを貼り付けると再構築後の処理結果を確認できる仕組みだ。
旧パーサーへ戻すフィルターも用意、ただし一時しのぎ
互換性を保つための逃げ道として、wp_kses_force_legacy_parser フィルターが用意されている。このフィルターを使えば従来の動作に戻せるが、恒久的な修正ではなく一時的な回避策として扱うべきだとされている。問題を検出した場合はTracチケットへ報告することが推奨されている。
Gutenberg 24.1、ブロック開発者に効く変更点
Gutenberg 24.1はデザインツールの一貫性に焦点を当てたリリースになった。約140件のプルリクエストが、ブロックサポートの適用範囲を広げている。ここではプラグインやテーマを開発するうえで押さえておきたい変更をまとめる。
レスポンシブなカスタムコントロールを自作できる
WordPress 7.1でレスポンシブなスタイル状態が導入されたが、当時はコアブロックしかブレークポイント別のコントロールを作れなかった。内部のヘルパーが公開されていなかったからだ。Gutenberg 24.1で、このビューポート状態を扱うヘルパーが公開された。
@wordpress/block-editor が getStyleForState() と setStyleForState() をエクスポートし、ブロックエディタストアには getSelectedBlockStyleState() と hasSelectedBlockStyleState() というセレクタが追加された。下の例は、モバイルのブレークポイントだけに最低高さを設定するコードだ。
const state = { viewport: '@mobile' };
const stateStyle = getStyleForState( attributes.style, state ) || {};
setAttributes( {
style: setStyleForState( attributes.style, state, {
...stateStyle,
dimensions: { ...stateStyle.dimensions, minHeight: '50vh' },
} ),
} );同じリリースでは、positionプロパティをブレークポイントごとに変えることも可能になった。たとえばヘッダーを「モバイルのときだけ固定表示にする」といった指定ができる。コアブロックと同じ感覚で、端末ごとに最適な表示設定を提供できるようになる。
ほぼ全コアブロックにブロックサポートが展開された
背景画像、グラデーション、影、リンクとボタンの色、ボーダー、テキストカラム、テキスト配置といった既存のブロックサポートが、ほぼすべてのコアブロックで使えるようになった。これまでカスタムCSSで補っていた部分を theme.json の styles.blocks に移せる場面が増える。
注意点として、Accordion、Tabs、Tab Panel、Post Templateの各ブロックでは、リンク色関連のクラスが出力されるようになった。テーマ側でこれらのブロック内リンクをスタイルしている場合は、セレクタの詳細度が衝突しないか7.2までに確認しておきたい。
コアアイコンは塗りではなく線に、コンポーネント5つは非推奨
約330個のコアアイコンが、塗りつぶし方式から線ベースに再描画された。各SVGにはインラインで fill をnoneにする指定が入る。fillプロパティやCSSのfillルールでは色を変更できなくなるため、CSSのcolorプロパティを使うことになる。
fill: none をインライン指定併せて @wordpress/icons と @wordpress/components はセットで更新しておきたい。新しいアイコンと古いIconコンポーネントを混在させると、統合されたスタイルが欠けることがある。
@wordpress/components では、Divider、ResponsiveWrapper、Scrollable、ZStack、Elevationの5つが非推奨になった。これらは7.2から非推奨の扱いで、7.4で削除される計画だ。置き換え先は原則として通常のCSSで、ResponsiveWrapperは aspect-ratio、DividerはSeparatorコンポーネントが推奨される。
なお、MediaUpload の unstableFeaturedImageFlow は featuredImageFlow として安定化した。旧名は同じく7.4で削除される予定だ。
プラグイン配布とデータベースに影響する変更
プラグインの新リリースに自動セキュリティレビューが入る
WordPress.orgディレクトリへプラグインを配布している開発者は、リリース時の扱いが変わる。プラグインチームが新リリース向けの自動セキュリティレビューを導入した。リリース後のクールダウン期間に、複数のAIモデルとJetpack Scanが新しいリリースをスコアリングする。
高リスクと判定された場合は、リリースが自動的にブロックされ、コミッターには結果がメールで通知される。コミッターアカウントに登録したメールアドレスは、実際に誰かが読むものにしておくこと。通知を見逃すと、リリースが止まったまま気づかないという事態になりかねない。
NO_BACKSLASH_ESCAPES SQLモードの既定無効化
WordPress 7.2から、wpdb はデータベースセッションから NO_BACKSLASH_ESCAPES SQLモードを取り除く。多くのサイトには影響しない変更だが、このモードに依存している環境では注意が必要だ。
どうしてもモードを維持したい場合は incompatible_sql_modes フィルターを使う。ただし使えるのは db.php ドロップインからのみで、プラグインやmu-pluginsからは読み込みが遅いため変更できない。
add_filter( 'incompatible_sql_modes', function ( $modes ) {
return array_diff( $modes, [ 'NO_BACKSLASH_ESCAPES' ] );
} );新テーマIpsum、ギャラリー拡張、Playground新ツール
新デフォルトテーマ「Ipsum」が登場
WordPress 7.2では新しいデフォルトテーマ「Ipsum」が同梱される。長く続いた年号ベースの命名から離れ、デフォルトテーマは独自の名前を持ち、カレンダーではなくデザインの必要性に応じて変更される方針になった。Ipsumという名前は、本番のコンテンツが入るまでページを埋める仮テキスト、lorem ipsumに由来する。
Ipsumは意図的にミニマルなブログテーマとして設計された。点線の下線と少数の書体で静かなページを作る。ヘッダー、ヒーロー、サイドバーは必要なときには表示され、執筆中は邪魔にならない。スタイルバリエーションは画像も含めてページ全体を塗り直すほど作り込まれている。開発チームは、デフォルトデザインだけでなくすべての組み合わせがWCAG AAを満たすと説明している。
ギャラリーブロックにグリッド表示とブレークポイント別設定
ギャラリーブロックにはグリッド表示のバリエーションが追加された。Gutenberg 24.0で導入され、Flexが従来どおりのデフォルトだ。既存のギャラリーは切り替えるまで挙動を維持する。
ギャラリーのCSSルールはFlexレイアウトのときだけ適用される形にスコープが絞られた。詳細度自体は変わっていないが、テーマ側で「常に適用される」前提のスタイルを書いている場合は、グリッド表示との組み合わせを確かめる必要がある。
ブレークポイント別の設定も強化された。Flexレイアウトでは列数とクロップ、全レイアウトでアスペクト比をビューポートごとに変えられる。表示端末に応じてギャラリーの見せ方を細かく制御したい場面で役立つ。
Playgroundにターミナルとメール受信トレイを追加
WordPress Playgroundに開発者向けのツールが2つ追加された。1つ目はDev Tools Dockだ。ライブサイトに対してPHPやWP-CLIのコマンドを実行できるターミナルが使えるようになった。TTYはなく、対話型や長時間実行するコマンドは拒否される。Blueprintの wp-cli ステップも同じ制限に従う。
2つ目はメールツールだ。wp_mail() 経由で送信されたメールをすべて捕捉し、ブラウザー上に表示する。通知メールのテストでメールキャッチャーを別途用意する手間が省ける。注意点として、捕捉対象はsendmail経路のみで、SMTPやAPIベースのプロバイダーを使う場合は表示されない。
この記事のポイント
- WordPress 7.2はBeta 1が10月20日、RC1が11月17日、正式版が12月8日に予定されている
wp_kses()はHTML APIベースへ再構築され、出力の正規化と除去ルールが強化される- Gutenberg 24.1でブロックサポートがほぼ全コアブロックに展開され、コアアイコンは線ベースへ移行した
- プラグインの新リリースには複数のAIモデルとJetpack Scanによる自動セキュリティレビューが入る
- 新デフォルトテーマIpsumとPlaygroundのターミナル、メールツールも登場した
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験