ACFブロックが編集画面で表示されない時の原因と対処（React 19実験を無効化）
GutenbergのReact 19実験が有効になると、ACFで登録したブロックが編集画面で「このブロックでエラーが発生したためプレビューできません」と表示され、プレビューできなくなることがある。この症状はACFがReact 19に未対応の段階で起こる互換性問題で、テーマのfunctions.phpにフィルターを追記してReact 18に固定すれば回避できる。
なぜACFブロックだけが編集画面でエラーになるのか
ACFで登録したブロックは、編集画面のプレビュー部分がReactコンポーネントとして扱われる。React 19ではコンポーネントの渡し方や内部処理が変更されたため、ACF 6.8.10以前の実装と噛み合わず「要素のタイプが無効です」という趣旨のReactエラー（コンソール上はReact error #130）が発生する。
コアブロックでは発生せずACFブロックだけに症状が出るのは、このエラーがブロックエディタ全体の不具合ではなくACFプラグイン側の互換性に起因するためだ。フロントエンドはサーバー側で描画されるため影響を受けず、編集画面のプレビューだけが壊れる。
編集画面では赤いエラー表示だけが出て手も足も出ないが、フロントエンドが正常ならこの互換性問題を強く疑ってよい。
React 19実験はなぜ自動で有効になるのか
GutenbergのReact 19実験は、互換性のないプラグインやテーマが見つからない限り自動で有効になる設計だ。不要なテーマやプラグインを整理した直後など、互換性チェックが通るようになったタイミングで突然有効化されることがある。
管理画面の「Gutenberg」メニューの「実験」画面で有効かどうかを確認できる。ただし一部のホスティング環境では、チェックを外しても保存されず、設定が既定値（有効）に戻ってしまう。そのため管理画面からの無効化だけでは対処できない場合がある。
この流れでReact 19が有効になった結果、ACFブロックのプレビューだけが壊れる。管理画面の設定が保存されない環境では、次の手順で強制的にReact 18へ固定する。
functions.phpでReact 18に固定する手順
対処は子テーマのfunctions.phpにフィルターを追記し、Gutenbergの実験オプションを上書きしてReact 18を維持する方法が確実だ。親テーマを直接編集するとアップデートで上書きされるため、必ず子テーマを使う。
// ACFがReact 19に対応するまでブロックエディタをReact 18に固定する
$theme_disable_react_19 = function($experiments){
$experiments = is_array($experiments) ? $experiments : [];
$experiments['gutenberg-react-19'] = false;
return $experiments;
};
add_filter('option_gutenberg-experiments', $theme_disable_react_19);
add_filter('default_option_gutenberg-experiments', $theme_disable_react_19);このフィルターは、Gutenbergの実験設定を保存するオプションに対して gutenberg-react-19 フラグを常にfalseに上書きする。管理画面でチェックを外しても戻ってしまう環境でも、テーマ側から強制できるため再発しない。
ACFがReact 19に対応したバージョンにアップデートされたあとは、このコードを削除して通常の設定に戻す。削除し忘れると新しいReactを使うべきタイミングでも18に固定されたままになるため、ACFの更新履歴は確認しておく。
修正後にブロックが表示されるか確認する方法
functions.phpにコードを追加したあとは、サーバー側とプラグイン側のキャッシュを削除し、ブロックエディタをハード再読み込み（Ctrl + Shift + Rなど）する。ACFブロックを再配置し、プレビューが表示されることを確認する。
ブラウザのコンソールを開き、React error #130が消えていることも確認すると確実だ。本番環境で直接試すのが不安な場合は、ステージング環境に同じコードを入れて挙動を確認してから反映する。
ACF側の対応と今後のアップデート
この症状はACFがReact 19に正式対応するまでの過渡期の互換性問題として認識されており、ACFの開発側でも修正が進められている。今後のアップデートでReact 19対応が含まれた場合は、本記事のフィルターを外して編集画面の挙動を再確認する。
それまでの間は、本番環境でReact 19実験を有効にしたまま使い続けるリスクを避けるため、本記事のフィルターでReact 18に固定しておくのが現実的だ。関連するプラグインやテーマが更新されたタイミングで、ステージング環境から互換性を確認する流れを作っておくと安全だ。
よくある質問
React 19実験を無効化すればACFブロックは直るのか
直る。ただし一部のホスティング環境では画面上のチェックが保存されず、既定値の有効に戻ってしまう。その場合はfunctions.phpのフィルターで強制的に無効化する。
functions.phpを直接編集せずに対処する方法はあるか
コードスニペットプラグインを使ってフィルターを追加する方法がある。いずれも親テーマを直接編集しないこと。親テーマを更新するとコードが消えるため、子テーマかスニペットプラグインを使う。
フロントエンドは表示されるのに編集画面だけ壊れるのはなぜか
ACFブロックの公開ページはサーバー側で描画されるため、React 19の影響を受けない。編集画面のプレビューだけはReactで組み立てられるため、互換性の問題が表面化する。
ACF以外のブロックが同じエラーを出す場合はどうすればよいか
同じReact error #130がコアブロックや他のプラグインブロックでも出る場合は、React 19実験だけでなくブロックの登録方法やプラグインの競合も確認する。一旦全プラグインを無効化して切り分けるのが早い。
フィルターを入れたままACFをアップデートしても問題ないか
問題はないが、ACFがReact 19に対応した後もフィルターが残っていると、React 18に固定され続ける。ACFの更新履歴を確認し、対応が完了したらフィルターを外して動作を再確認する。
この記事のポイント
- React 19実験の有効化でACFブロックの編集画面プレビューがエラーになる
- フロントエンドは影響を受けず、編集画面だけに症状が出る
- 管理画面のチェックが保存されない環境ではfunctions.phpから強制する
- ACFがReact 19に対応したらフィルターを外して再確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.2開発サイクル始動、Gutenberg 23.8と23.9の開発者向け新機能まとめ
WordPress 7.1「Mary Lou」が2026年8月にリリースされた。レスポンシブスタイルステート、アイコン登録機能などが含まれる大型アップデートだ。まだ更新していない場合は早めの対応が推奨される。
続くGutenberg 23.8と23.9では開発者向けの改善が多数入っている。コードリファレンスの実行可能コード例、ブロックのキーボードショートカット宣言API、テーマJSONスキーマの修正など、実務に直結する変更が多い。
WordPress 7.2のBeta 1は2026年10月20〜22日、正式版は12月8〜10日に予定されている。本記事では2026年9月時点の開発者向け変更点を整理して解説する。
コードリファレンスがブラウザ上で実行可能に
WordPress公式のコードリファレンスで大きな変化があった。コード例をその場で実行できるようになったのだ。WP_HTML_Processorクラスのclass_list()メソッドのページを開き、「Run」ボタンを押すと、Playgroundを使った実際のWordPress環境でコードスニペットが実行される。
従来のコードリファレンスは静的ページであり、コード例を読むだけだった。だが今回の変更で、関数の動作確認がブラウザ内で完結する。ドキュメントと関数定義が同じファイルに存在するため、コードと実行結果の乖離が起きにくい構造だ。
実装方法はDocBlocksの中に「php interactive」というコードフェンスを書くだけ。関数の説明コメント内に実行可能なコードを埋め込む仕組みで、ドキュメント提案として長く議論されてきた内容が実現した形だ。
ブロック開発の新APIと改善点
キーボードショートカットを宣言的に定義可能に
Gutenberg 23.9では、ブロックのキーボードショートカットを宣言的に登録するAPIが追加された。これまで「Alt+Shift+2」で段落をHeading 2に変換する機能はハードコードされており、エディタパッケージごとに個別実装が必要だった。
新しいAPIでは、ブロックバリエーションにshortcutオブジェクトを指定するか、ブロック変換にshortcuts配列を指定する。後者の場合、1つの変換で最大6つのショートカットをまとめて定義できる。
インナーブロックテンプレートがブロック設定へ移行
Gutenberg 23.8では、templateとtemplateInsertUpdatesSelectionがブロックタイプ設定として追加された。従来のInnerBlocksコンポーネントのpropsを使う方式は非推奨となり、WordPress 7.2リリース前に移行することが推奨される。
この変更の背景にはリアルタイム共同編集の開発がある。propsベースの方式はマウント後にテンプレートを適用するため、3人の共同作業者がドキュメントを開いている場合、Listブロックを挿入すると3つのリスト項目が生成される問題があった。ブロックタイプ設定として宣言することで、ブロックとテンプレートが単一のストア操作で処理される。
kebab-case変換がJSとPHPで完全一致
WordPress Coreの_wp_to_kebab_case()は、数字の扱いに関して一般的なライブラリと異なる挙動をしていた。今回、JavaScript側でも同じ変換結果を返す@wordpress/kebab-caseパッケージが公開された。
kebabCase(‘font2xl’) → font2xl
kebabCase(‘white4th’) → white4th
kebabCase(‘font2xl’) → font-2-xl
kebabCase(‘white4th’) → white-4th
このデモで示したように、JSとPHPの間でスラッグ生成ロジックが統一された。ブロック名やCSSクラス名の変換で環境による差異がなくなる。
エディタが管理者カラースキームに対応
投稿エディタ、ウィジェットエディタ、カスタマイザーのウィジェットエディタが、アクティブな管理者カラースキームを反映するようになった。getAdminThemeColors()が@wordpress/admin-uiの公開APIとして提供され、拡張開発者も同じ仕組みを自前の管理画面に組み込める。
Data Viewsの改善と時刻フィールド追加
DataViewsパッケージからプライベートAPIの依存が排除された。これまで同パッケージをプラグインにバンドルすると「ロックされていないオブジェクトをアンロックできない」というエラーが出る問題があった。対応に伴い、CalendarやRangeCalendarなどのコンポーネントが公開APIとして移行している。
Gutenberg 23.8ではtime型のフィールドも追加された。営業時間やイベント開始時刻、予約枠など、日付を伴わない時刻データを扱う用途に向いている。値はHH:mm形式で保存されるため、訪問者のタイムゾーンに左右されない。
テーマ開発者向けの変更点まとめ
theme.jsonスキーマの修正
WordPress 7.1で導入されたレスポンシブスタイルステートと擬似クラスステートのスキーマが不完全だった。Gutenberg 23.8で複数の修正が入り、コードエディタでtheme.jsonを編集する際にステートが不正として表示されないようになった。
スタイルUIの制御オプション追加
blockStatesEditingEnabledとresponsiveEditingEnabledという2つのフラグが追加された。block_editor_settings_allフィルターを通じて無効化できる。クライアント向けのサイト構築で、設計済みのスタイルを崩させずに編集機能をロックダウンする用途に有効だ。
label要素とフォーム要素のスタイル対応
Gutenberg 23.9ではlabel要素がtheme.jsonのスタイル対象に追加された。styles.elements.labelで指定でき、Search、Form Input、Post Comments Form、Archives、Categoriesブロックなどでレンダリングされるlabelタグに適用される。
続けてcite、textInput、select要素もエディタのStylesインターフェースから直接編集できるようになった。エディタのTypographyパネルとColorsパネルで操作できる。
GroupブロックのblockGapが軸別指定に対応
GroupブロックのblockGapサポートが水平方向と垂直方向の両方に対応した。theme.jsonでblockGapの値として通常の文字列に加えて、topとleftのキーを持つオブジェクト形式を指定できる。エディタUI上ではflexレイアウトとgridレイアウトでのみ軸別コントロールが表示される。
そのほか、Listブロックがwideとfullの配置をサポート、Query No Resultsブロックがボーダーとスペーシングをサポート、Query Loopブロックがblock gapをサポートするようになった。Accordion Headingブロックのtheme.jsonスペーシングがトグルボタンに正しく適用される修正も入っている。
Playgroundの進化とWordPress 7.2の展望
WordPress PlaygroundがWebMCPに対応した。これはAIエージェントが呼び出せるツールとしてブラウザ内のアクションを公開する草案APIだ。PlaygroundはWordPressをネストされたiframeで実行するため、新しいプロキシが埋め込みサイトのツールを外部ページに広告し、呼び出しを転送する仕組みになっている。
さらに、Playground上でWordPress 0.7まで遡って実行できるようになった。設定パネルで「Include older versions」にチェックを入れると、6.2までの全バージョンが選択肢に含まれる。PHPのバージョンも自動的にペアリングされるため、「いつこの機能が壊れたのか」を確認する用途に役立つ。
このタイムラインで示したように、WordPress 7.2の開発サイクルは約2ヶ月にわたって進行する。開発者向け機能の実装状況を確認しながら、互換性の検証を進めるのが良いだろう。
この記事のポイント
- コードリファレンスがブラウザ上でコード実行に対応、Playgroundを使った動作確認が可能になった
- ブロックのキーボードショートカットを宣言的に定義するAPIが追加された
- インナーブロックテンプレートはブロックタイプ設定への移行が推奨される
- theme.jsonのスキーマ修正とスタイルUIの制御オプションでテーマ開発が改善された
- WordPress 7.2は12月8〜10日に正式リリース予定、Beta 1は10月20〜22日
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1正式版が8月19日リリース。レスポンシブスタイルと疑似状態の全容
WordPress 7.1の正式版が2026年8月19日にリリースされる。WordCamp US最終日と重なるタイミングで、すでにRC1とRC2が公開され、機能セットは確定済みだ。先月にはセキュリティリリース2件も出ており、影響を受けるサイトは自動更新が強制された。
今回のアップデートで注目が大きいのは、レスポンシブブロックスタイルと疑似状態スタイルのコア導入だ。テーマ開発者はモバイルとタブレットの表示をtheme.jsonだけで制御できるようになる。プラグイン開発者もリストテーブルの構造変更に注意が必要だ。正式版まで残り数日、互換性確認のポイントを解説する。
WordPress 7.1は8月19日リリース、RC2まで公開済み
正式版はWordCamp US最終日に到着
WordPress 7.1は8月19日にリリース予定だ。ちょうど8月16日から19日にかけて米国フェニックスで開催されるWordCamp USの最終日と重なる。年次フラッグシップイベントの最終日に正式版が出るのは珍しいスケジュールで、現地参加者はその瞬間をライブで目撃できる。
先週までにRC1とRC2が立て続けに公開された。RC（Release Candidate / リリース候補版）とは、正式版の一歩手前の段階だ。ここまで来ると新機能の追加は終了し、バグ修正だけが行われる。Field Guideも公開済みで、全機能の開発者向け詳細がまとまっている。
セキュリティリリース2件、強制自動更新も発動
先月はセキュリティリリースが2件公開された。7月17日に出たWordPress 7.0.2は、重大な脆弱性1件と高深刻度の脆弱性1件に対処したものだ。深刻度が高かったため、影響を受けるバージョンのサイトには強制自動更新が適用された。続いて8月6日には7.0.3が公開され、十数件の追加修正が入っている。
管理しているサイトが両方の自動更新を何らかの理由で逃していた場合、先にそちらの更新を済ませることが最優先になる。7.1のテストはその後でかまわない。
レスポンシブスタイルがコアに登場
上記の図は、theme.jsonでデスクトップ・タブレット・モバイルのパディングを切り替える様子を視覚化したものだ。実際には端末の画面幅に応じて、この3つの状態が自動的に切り替わる。
theme.jsonでモバイルとタブレットのスタイルを定義
春先から開発が進められていたレスポンシブスタイルが、WordPress 7.1で正式にコアに導入された。ブロックのスタイルをタブレットとモバイルのビューポートごとに定義できる。Global Styles（グローバルスタイル）ではブロックタイプ単位で、個別のブロック単位でも設定可能だ。theme.jsonでは@mobileと@tabletというキーの中にネストして記述する。
ここで押さえておきたいのは、@desktopキーが存在しない点だ。ブロックのデフォルトスタイルがそのままデスクトップスタイルになる。モバイルやタブレットで上書きしなかったプロパティは、すべてのビューポートでデフォルト値が適用される。
さらにテーマ側でブレークポイントを設定できる。theme.jsonのトップレベルにsettings.viewportプロパティを追加する仕組みだ。デフォルトはモバイルが480px、タブレットが782px。値はpx、em、remの非負の長さのみ許可され、CSS関数やパーセント、単位なしの値は無視される。タブレット値がモバイル値と同じか小さい場合は、モバイルのみが使われる。
標準ブロックサポートを使っているブロックは、タイポグラフィ、カラー、背景、ボーダー、寸法、スペーシング、レイアウトが自動的に対応する。逆に独自のスタイルコントロールを持つブロックは対象外だ。自作ブロックがある場合、この線引きで対応有無を確認してほしい。
疑似状態スタイルでホバーやフォーカスを制御
ホバーやフォーカスは実際の操作で状態が変わるため、上記は4つの状態を並べて示したものだ。実際の編集画面では「Hover」タブを選んでスタイルを設定する。
かねてから要望の多かった疑似状態スタイルも7.1で実装された。:hover、:focus、:focus-visible、:activeをtheme.jsonとエディタで定義できる。現時点ではButtonブロックとNavigation Linkブロックに限定されている。
さらに初期段階のカスタムステート機能も入った。現状はtheme.jsonのみで、管理画面のUIはまだない。Navigation Linkブロックが現在のメニュー項目をスタイルするために-currentプロパティを使う仕組みだ。カスタムステートは-接頭辞を使い、ブロックのblock.jsonにあるselectors.statesプロパティで宣言したクラス名をターゲットにCSSを生成する。現時点では限定的だが、今後の拡張に向けた重要な布石だ。
新しいデザインツール3点
テーマ開発者が長年待っていた変更を含む、デザインツールの追加が3つある。グラデーションと背景画像を同時に使えるようになるのは特に大きい。
背景グラデーションと背景画像を併用可能に
新しいbackground.gradientは既存のcolor.gradientとは別のサポートとして追加された。違いはCSSの出力先にある。従来のサポートはbackgroundショートハンドを通じて描画されるため、background-imageを含むすべてのbackground関連プロパティをリセットしてしまっていた。ブロックにグラデーションか画像のどちらか一方しか使えなかった理由だ。
新しいサポートはbackground-imageロングハンドで描画される。スタイルエンジンが1つの宣言内にグラデーションと画像をカンマ区切りで出力できるようになった。7.1ではGroup、Accordion、Pullquote、Post Content、Quoteがコアで対応する。値はstyle.background.gradientに保存される。
最小幅とテキストシャドウ
dimensions.minWidthは既存のminHeightと同じパターンで、CSSのmin-widthとして適用される。テーマがdimensionSizesプリセットを提供していれば、それを活用できる。1点注意があり、この設定はデフォルトではブロックインスペクターに表示されない。ブロック側で__experimentalDefaultControlsを通じてopt-inした場合のみ表示される。Global Stylesではデフォルトで表示される。
テキストシャドウもGlobal Stylesでサポートされた。これまでは個別ブロックやCSSでしか指定できなかったが、theme.jsonからサイト全体またはブロックタイプ単位で制御できる。
SVG Icon APIが正式公開
アイコン名の衝突を防ぐため、コレクション名が名前空間の接頭辞になる。プラグイン独自のアイコンを登録しても、コアのアイコンと混同される心配がない。
WordPress 7.0でエディタとIconブロック向けにSVGアイコンのセットが同梱された。7.1ではこれが正式な公開APIになり、プラグインやテーマから登録できるようになった。wp_register_icon_collection()でコレクションを登録し、wp_register_icon()でアイコンを追加する。PHPの任意の場所でwp_get_icon()を使えば、サイズやクラス、ラベルを指定してアイコンを表示できる。
計画時に意識したい制限が2つある。登録したSVGはwp_ksesによって保守的な許可リストでサニタイズされる。許可されるのは<svg>、<path>、<polygon>のみ。許可リストの拡大作業は進行中だ。fillは図形部分にのみ許可され、外側の<svg>には付けられない。またwp_get_icon()単体で呼び出すとSVG自身のfill（黒）で描画される。周囲のテキスト色に合わせたい場合は、渡したクラスに対して自前でCSSを指定するのが推奨される。
エディタのiframe化とプラグインへの影響
投稿エディタは常時iframe表示へ
テンプレートエディタがiframe化されたのはWordPress 5.8からだ。それ以来、投稿エディタも段階的に移行してきたが、7.1で最終段階に入った。テーマの種類や登録ブロックのAPIバージョン、コンテンツ内のブロックのAPIバージョンに関係なく、投稿エディタは常にiframeで表示される。レガシーメタボックスを登録しているサイトも同様だ。
7.0では投稿ごとに挿入されたブロックに基づいて判断されていた。つまりコンテンツによってiframedモードと非iframedモードが切り替わり得た。この条件付き動作がなくなり、挙動が単純化された。
大半のブロックは変更なしで動作する。問題が起きる場合、ほとんどは1つの根本原因にたどり着く。iframeは管理者ページとは別のdocumentとwindowを持つ。エディタスクリプトが実行される管理者ページからグローバルのdocumentやwindowにアクセスしてキャンバスを操作しようとすると、間違ったドキュメントを見ていることになる。対処としては、キャンバス内の要素からownerDocumentとdefaultViewでドキュメントを取得するか、useRefEffectでキャンバス要素にリスナーをアタッチ・クリーンアップするのが一般的だ。
リストテーブルの行ヘッダーが移動
カスタムCSSやJavaScriptを書いているプラグインにとって、静かに何かを壊す可能性が高いのがリストテーブルの変更だ。投稿一覧テーブルで、プライマリのth scope="row"がチェックボックス列からタイトル列に移動した。チェックボックスセルはtdになり、タイトルセルがthとして投稿タイトルを含むaria-labelを持つ。レスポンシブ表示で折りたたまれるセルはflexレイアウトを使うようになった。
これはアクセシビリティの大きな改善だ。スクリーンリーダーは各行を、場合によっては存在しないチェックボックスではなく投稿名で認識できるようになる。ただしこのマークアップは2010年以降ほぼ安定していたため、多くの拡張が暗黙的に依存している。th.check-columnを選択するCSSやJavaScript、td内の行アクションや投稿タイトルを期待するコードがある場合は確認が必要だ。
この記事のポイント
- WordPress 7.1は8月19日リリース予定、RC2まで公開済みで機能セットは確定
- セキュリティリリース7.0.2と7.0.3が先月公開され、強制自動更新も適用された
- レスポンシブスタイルがコアに入り、モバイルとタブレットのスタイルをtheme.jsonで定義可能に
- 疑似状態スタイルでホバー、フォーカス、アクティブをテーマから制御できる
- SVG Icon APIが公開され、プラグインが名前空間付きでアイコンを登録可能に
- 投稿エディタは常時iframe化され、リストテーブルの行ヘッダー移動も要確認
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.1ベータ公開、ノート機能の大幅強化とCSS不要のレスポンシブ編集
WordPress 7.1のベータ版が7月下旬に公開され、編集体験に大きな改善が盛り込まれた。ノート機能がチームでの共同編集に本格対応し、CSSを一行も書かずに端末ごとの見た目を調整できるようになる。正式版はWordCamp USが開催期間中の8月19日にリリースされる予定だ。
今回の目玉は「ノート機能の強化」「レスポンシブスタイリング」「ホバーやフォーカス状態の視覚編集」の3本柱である。さらに、かねてから要望の多かったタブブロックとプレイリストブロックが追加され、管理画面の使い勝手も向上する。テスト段階のため本番環境への適用は避ける必要があるが、正式版までに知っておきたいポイントを詳しく見ていこう。
ノート機能がチーム編集ツールに進化
WordPress 6.9で導入されたノート機能は、ブロック単位の簡素なコメント機能だった。WordPress 7.1ではそれが一変し、複数人でのフィードバックに耐える本格的なツールへと変わる。
@メンションで担当者を直接指名
ノートの入力欄で「@」を打ち込むと、サイトの共同編集者の一覧が検索候補として表示される。目的のメンバーを選択すれば、その人を指名したノートが作成される。これにより「この修正は誰に伝えればいいのか」という迷いがなくなり、チーム内でのやり取りが格段にスムーズになる。
インラインノートで誤解を減らす
これまでのノートはブロック全体に対してしか付けられなかったため、長文の中で「ここを直してほしい」と書いても具体的な箇所が伝わりにくかった。WordPress 7.1では、文章内の特定の語句や文を選択し、その部分だけにノートを付けられる。該当部分はハイライト表示されるため、どの言葉に対する指摘なのかが一目でわかる。WP Beginnerの記事でも「『この部分を言い換えてほしい』という指示が、長い段落の中のどの単語を指すのかを推測する必要がなくなった」と評価されている。
このように、修正箇所と指示がピンポイントで結びつくため、レビューにかかる時間が劇的に短縮される。
その他の改善点
- 同じブロックに対して複数のノートスレッドを立てられる。議題ごとに会話を分離できる
- ノート本文に太字、斜体、コード、リンク、絵文字を使ったリッチテキストが可能
- 長いノートは初期状態で折りたたまれ、サイドバーが散らからない
CSS不要のビジュアルスタイリングが編集画面で完結
WordPress 7.1で最もインパクトが大きいのが、レスポンシブデザインのビジュアル操作である。これまではスマホやタブレット用の見た目を調整するには、CSSメディアクエリを手書きするか、テーマの設定に頼るしかなかった。今回のアップデートで、ブロックエディタ上でプレビューを切り替えながら、直感的にスタイルを設定できるようになる。
端末別のスタイル設定
エディタ上部のプレビュー切り替えで「デスクトップ」「タブレット」「モバイル」を選択すると、以降のブロックスタイルの操作はその画面サイズにだけ適用される。たとえばモバイル表示を選んで見出しのフォントサイズを小さくすれば、実際のスマホでの表示だけが変わる。デスクトップ表示には影響しない。
さらに、ブロック設定パネルには、現在どの画面サイズを編集中かを示す小さなバッジが表示される。意図しない画面用のスタイルを上書きしてしまうミスを防げる。エディタキャンバス自体も、プリセットの3サイズに縛られず、横幅をドラッグして任意の幅での表示をリアルタイムに確認できるようになった。テーマがtheme.jsonで独自のブレイクポイントを定義していれば、その値に合わせたプレビューも可能である。
CSSを書く必要がなくなり、カスタマイズのハードルが大きく下がる。サイト全体に一括適用したい場合は、グローバルスタイルで設定し、変更内容を選択的にグローバルへ反映させることもできる。
ホバーやフォーカス状態も視覚的に編集
ボタンなどのブロックには新たに「状態」ドロップダウンが追加され、ホバー時やフォーカス時、アクティブ時の見た目をエディタ上で直接編集できる。背景色や枠線、テキスト色を状態ごとに変え、その場でプレビュー確認できる。これまではほんの小さな変更であっても、カスタムCSSを追加せざるを得なかったが、今後は組み込みのデザインオプションで完結する。
待望のタブブロックとプレイリストブロック
これまでプラグインで実装していたタブ切り替えのレイアウトが、ついにコアブロックとして導入される。また、音声ファイルをまとめて再生できるプレイリストブロックも新登場する。
タブブロック
商品の仕様、よくある質問、料金プランの比較など、情報をパネルで区切って見せたい場面で重宝する。クリックでパネルを切り替える形式で、長いページを避けたい場合に効果的だ。既存のプラグインで作成したタブは、自動的にはコアブロックに変換されないため、移行の際は手作業が必要になる点に注意しておきたい。
プレイリストブロック
複数の音声ファイルを一つのプレイヤーにまとめ、タイトルやアーティスト名、カバーアート、波形グラフィックとともに表示できる。ミュージシャンや教会、教育機関、ポッドキャスト運営者にとっては、エピソードをまとめて提供するのに理想的なブロックだ。WordPressだけで手軽に音声配信の体裁を整えられるようになる。
加えて、既存のブロックにも多くの改善が加わっている。背景グラデーションと画像の同時適用、テキストシャドウのtheme.json対応、HTMLブロック内でのブロックネストの編集、装飾画像をスクリーンリーダーに読み上げさせない設定、ショートコードのEmbedブロックへの自動変換、ColumnsやGalleryからのグリッドレイアウト変換、アイコンブロックの回転・反転・アイコンセット登録機能など、日常的な制作を後押しするアップデートが多数含まれている。
画像編集とメディア処理の刷新
WordPressに組み込まれている画像編集機能が大幅に変わる。従来の狭いインライン操作から、専用のモーダルウィンドウでの本格的な編集へと進化した。
専用の画像編集モーダル
画像ブロックの「切り抜き」ボタンを押すと、フルスクリーンに近い編集画面が開く。自由トリミング、アスペクト比のプリセット、回転・反転、メタデータの編集を一か所で行える。カバーブロックにも対応しており、背景画像をその場でトリミングできる。本格的な写真編集ソフトには及ばないものの、サイト運営者が日常的に行う作業としては十分な機能を備えている。
ブラウザで画像を前処理しHEICにも対応
WordPress 7.1では、画像のリサイズや圧縮、サムネイル生成の大部分を、アップロード前にブラウザが処理する仕組みが導入される。これにより、サーバーの負荷が大幅に減り、低スペックなホスティング環境でもアップロードエラーが起きにくくなる。
さらに、iPhone標準の画像形式であるHEICをはじめ、UltraHDR、AVIF、WebPといった最新フォーマットへの対応が強化される。これまではサーバー側のImageMagickのバージョンに依存してHEICの変換が失敗することがあったが、ブラウザが変換を担うことで環境を選ばずに済むようになる。なお、ChromeとEdgeではフル機能が利用でき、Safariでは一部がサーバー処理に委ねられ、Firefoxでは従来通りサーバー側で処理される。
アップロードの堅牢性と細かな改善
アップロード中にネットワークが切断されても、キューが自動で一時停止し、再接続後に中断したところから再開される。一括アップロード時には進行状況が表示される。このほか、投稿に添付された画像を自動で引っ張ってくる動的ギャラリーモード、投稿専用の「添付画像」セクションがインサーターに追加され、メディアライブラリは自動読み込みの無限スクロールに対応する。日々のメディア管理のストレスを確実に減らす改良が詰め込まれている。
管理画面と編集体験の快適化
WordPress 7.1では、編集画面と管理画面の連携を改善する数々の小さな改良も施されている。
管理ツールバーが常に表示される
ブロックエディタやサイトエディタで編集しているときも、管理ツールバーが非表示にならず、画面上部に固定される。これにより、作業中でもサイトの管理メニューに素早くアクセスできる。ツールバーそのものもデザインが整理され、戻るボタンがわかりやすい山形アイコンに変更され、サイトアイコンと丸いプロフィールアバターが表示される。アイコン類も旧来のDashiconsからモダンなSVGに置き換わった。もちろん、集中執筆モードではツールバーが隠れるため、文章だけに集中したい場合も安心だ。
コマンドパレットとアイデンティティ設定の進化
コマンドパレット（Ctrl+K / Command+K）は、最近使ったコマンド、一致する候補、おすすめの3つに分類されるようになった。利用履歴はログインをまたいで保存されるため、よく使う操作に素早くたどり着ける。サイトエディタのサイドバーも、ユーザーが選んだ管理画面のカラースキームを反映するようになり、全体的な統一感が増した。
サイトのタイトル、キャッチフレーズ、ロゴ、サイトアイコンといった基本情報は「デザイン」内の「アイデンティティ」セクションにまとめられ、設定画面とテンプレートを行き来する手間がなくなった。
「あの日何を書いたか」ウィジェットとコメント親変更
ダッシュボードに新たに「On This Day」ウィジェットが追加され、過去の同じ日に公開した記事を表示してくれる。長く続けているブログにとっては、更新のネタを見つけるきっかけになる。また、コメント編集画面では「どのコメントへの返信か」を後から変更できるようになり、誤って違うスレッドにぶら下がったコメントを正しい位置に付け替えられる。対象は同一投稿内に限られるが、コメント管理の柔軟性が向上した。
見送られた機能と開発舞台裏
今回のリリースには含まれなかったが、注目すべき開発項目がいくつかある。
リアルタイム共同編集は次期以降に持ち越し
Googleドキュメントのような複数人同時編集は、WordPress 7.1では搭載が見送られた。Gutenbergプラグイン上では既に動作しており、複数人が同じ投稿を同時に編集できる段階にある。しかし、コアチームは協調編集データの保存方法や、完全な機能を提供するか基盤だけを先にリリースするかといった重要な判断を続けている。コミュニティによるテストも継続中で、時期尚早な投入によるデータ消失リスクを避けるための慎重な判断と見られている。WP Beginnerの記事でも「作業内容を失う共同編集機能ほど最悪なものはない」と指摘されており、この慎重さは妥当だろう。
Unicodeメールアドレス対応も見送り
日本語などの非ラテン文字を含むメールアドレスへの対応も、ベータテスト中に課題が見つかり延期された。互換性とセキュリティの検証をコミュニティプラグインで続けた後、改めてコアへの導入を目指す方針だ。
パフォーマンスと開発者向けの内部改善
投稿エディタは常にiframe内で動作するようになり、管理画面のCSSによる表示崩れを根本的に防ぐ。ただし、旧APIで作られたブロックは影響を受ける可能性があるため、プラグイン開発者はBlock API v3への移行が推奨される。アイコンAPIが公開され、プラグインやテーマが独自のSVGアイコンセットを登録・レンダリングできるようになった。そのほか、デザインシステムの成熟や、外部サービス接続の認証方式拡充など、長期的な安定性と拡張性を見据えた改良も進められている。
この記事のポイント
- ノート機能に@メンションとインラインノートが追加され、チームでのフィードバックが格段に正確になった
- レスポンシブスタイリングとホバー・フォーカス状態の編集がCSS不要で行える
- タブブロックとプレイリストブロックがコアに加わり、コンテンツ表現の幅が広がった
- 画像編集モーダルとブラウザベースの画像処理で、メディアまわりの操作性と安定性が向上
- 管理ツールバーの常時表示やアイデンティティ設定の集約など、管理画面の使い勝手が改善された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Events ManagerでGutenbergのイベントが公開できない時の直し方
Events ManagerをGutenberg編集モードで使っているときに新規イベントが公開できず、クラシックエディタでは問題なく動作する場合、プラグインのバージョンが7.3.1〜7.3.4のいずれかであることが主な原因だ。7.3.5以降へアップデートすると修正される。
どんな操作をしたときに発生するのか
Gutenbergモードを有効にしたEvents Managerで新規イベントを作成する。すべての項目を入力して「公開」ボタンを押しても、画面が再読み込みされステータスが「下書き」のままになり、公開状態に切り替わらない。一方でクラシックエディタに切り替えると、同じ内容でも問題なく公開できるという状況だ。
この現象は、WP標準テーマ（Twenty Twenty-FourやTwenty Twenty-Five）に切り替えても、他のプラグインをすべて無効化しても変わらない。Events Manager側のGutenberg統合部分にバージョン固有の不具合が存在しているために起きる。
公開ボタンが反応しない直接の原因は何か
Events Managerのバージョン7.3.1から7.3.4には、Gutenbergエディタ上でイベントを保存する際に走るバリデーション（検証）処理に問題がある。具体的には、イベントの必須項目が正しく入力されていても内部的な検証に失敗し、「公開」操作が受理されない状態になる。
とくに繰り返しイベント（定期的な開催設定）を扱う場合、「Main recurrence set times are required（メインの繰り返し時刻設定が必要です）」という趣旨の検証エラーが返され、公開をブロックされるケースが報告されている。このバリデーションエラーは管理画面の見た目には表示されず、ブラウザの開発者ツール上で確認できる。
このデモが示すように、エディタの見た目上は正常に操作しているのに、プラグイン内部のAPI応答が原因で公開処理が止まる。Events Manager 7.3.5でこのバリデーション不具合が修正されている。
Events Managerを最新版にアップデートして修正する
最も確実な解決策は、Events Managerをバージョン7.3.5以降にアップデートすることだ。管理画面から数ステップで完了する。
サイトの運用途中でアップデートをためらう場合は、まずステージング環境（テスト用の複製サイト）でアップデート後の動作を確認すると安全だ。近年の国内レンタルサーバーでは、管理パネルからワンクリックでステージング環境を作成できるものも多い。
すぐに公開したい場合の一時的な回避策
プラグインのアップデートが何らかの理由ですぐにできない場合、以下の回避策で公開できることがある。
- 公開ボタンを2回以上連続でクリックする。1回目でいったん下書きとして保存され、2回目以降のクリックで公開状態に切り替わるケースが報告されている。
- イベント編集画面の「Events Manager」設定パネルで、Gutenbergモードを無効にしてクラシックエディタを使う。クラシックエディタでは問題なく公開できる。
これらの回避策は、あくまでアップデート前の応急処置として使う。根本的には7.3.5以降へのアップデートが必要だ。
アップデート後も繰り返しイベントでエラーが出る場合の対処
7.3.5以降でも、繰り返しイベントの設定時にまれに「Main recurrence set times are required（メインの繰り返し時刻設定が必要です）」という趣旨のバリデーションエラーが表示されることがある。このエラーは、繰り返し設定の中核となる日時情報がバリデーションAPIに正しく渡っていない場合に発生する。
まず試すべきは、繰り返し設定を一度クリアして再入力することだ。とくに開始日時と終了日時、および繰り返しパターンの「初回の日時」が空欄になっていないか確認する。カスタムコードでGutenberg有効化を制御していた場合は、そのコードが完全に削除されているかも確認する。残留したコードがAPI通信に干渉している可能性がある。
よくある質問
Events ManagerのGutenbergモードはどこで切り替えられるか
管理画面の「Events」→「設定」→「管理画面」タブにある「イベントエディタの種類」で切り替えられる。ここで「Gutenberg」を選択するとブロックエディタが有効になり、「クラシックエディタ」を選ぶと従来の編集画面に戻る。
Gutenberg有効化のカスタムコードが原因になることはあるか
過去にfunctions.phpなどへ追加したGutenberg有効化コードが削除されずに残っていると、プラグインの設定と競合して予期しない動作を起こす可能性がある。コードが完全に削除されているか、もしくはコメントアウトされているか確認する。
公開ボタンを押しても何も反応しない場合はどうすればよいか
ブラウザの開発者ツール（F12キー）の「コンソール」タブにJavaScriptエラーが表示されていないか確認する。別のプラグインがGutenbergと競合してJavaScriptエラーを起こしている場合、それが原因で公開処理が止まることがある。
クラシックエディタでは問題ないのにGutenbergだけ不具合が出る理由は何か
GutenbergはREST APIを介してデータを保存する仕組みをとっている。Events Managerのバリデーション処理も、GutenbergモードではAPI経由で実行される。クラシックエディタの場合は異なる保存経路を使うため、API側の不具合の影響を受けずに公開できる。
7.3.5はいつリリースされたのか
Events Manager 7.3.5は2026年7月下旬にリリースされ、本件のGutenberg公開不具合が修正されている。管理画面の更新通知から適用できる。
この記事のポイント
- Events Manager 7.3.1〜7.3.4のGutenbergモードには公開できない不具合がある
- 7.3.5以降へアップデートすると修正される
- アップデートできない場合は公開ボタンの複数回クリックやクラシックエディタで一時回避できる
- 繰り返しイベントでの検証エラーは設定の再入力で直ることが多い
- 過去のカスタムコードが競合していないか確認することも大切だ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressカスタムHTMLブロックが編集画面で消える原因と直し方
WordPress のブロックエディターでカスタム HTML ブロックを保存後に編集画面を開き直すと、ブロックの中身がまるごと消えて空欄に見える現象は、Gutenberg の React 側パーサーが HTML 構造を正しく解析できずに描画を放棄しているのが主な原因だ。script タグや閉じタグのない要素、複雑なインラインスタイルなどが引き金になる。
なぜカスタムHTMLブロックが編集画面で空になるのか
フロントエンドでは正しく表示されるのに、管理画面のブロックエディターだけで中身が空になるのは、データそのものはデータベースに保存されている証拠だ。コードエディターモードに切り替えれば、貼り付けた HTML が消えずに残っているのが確認できる。この現象が起こるのは、ブロックエディターがビジュアルモードでブロック内容を再表示するときに、DOM パーサーが特定の HTML を「壊れた構造」と判断してレンダリングを飛ばしてしまうからだ。
具体的には、Gutenberg が内部的に使用している React の DOM レンダリング機構が、管理画面の安全な枠組みの中で処理できないタグや構文に遭遇すると、そのブロック全体を安全のためにスキップする。結果として視覚的には空のブロックに見えるが、データベースの post_content には元のコードがそのまま格納されている。
カスタムHTMLブロックの中身が消える原因を特定する手順
まず、どの部分が問題を引き起こしているのかを切り分ける。以下の手順で原因箇所を絞り込む。
ブロックエディターのコードエディターモードで現状を確認する
編集画面右上の「︙」メニューから「コードエディター」を選択すると、ビジュアル表示ではなく生の HTML 構造が表示される。カスタムHTMLブロック内のコードがここで確認できれば、データは失われていない。このとき、Markdown 記法でブロック境界を示す <!-- wp:html --> と <!-- /wp:html --> のコメント行の内側にコードが残っているかを確かめる。
HTMLを最小単位に分解して原因のタグを特定する
ブロックに貼り付けた HTML を、1つのタグ単位で分割してカスタムHTMLブロックに1つずつ入れ直す。たとえば script タグ、style タグ、空要素（<div></div> など）、インラインイベントハンドラ（onclick など）をそれぞれ別のブロックに分けて保存し、再読み込み時に消えるかどうかをテストする。問題を起こすタグが特定できれば、その部分だけ別の実装方法に切り替えられる。
プラグイン競合の可能性を調べる
特定のプラグインがブロックエディターの動作に干渉して、カスタムHTMLブロックの描画を阻害しているケースもある。特にエディター拡張系のプラグインや、セキュリティ目的でスクリプトをフィルタリングするプラグインが入っている場合は、すべてのプラグインを一度無効化して標準テーマに切り替え、問題が再現するか確認する。プラグインが原因であれば、1つずつ再有効化して犯人を特定する。
カスタムHTMLブロックを正常に表示させる具体的な修正手順
原因が特定できたら、次は実際にブロックを正常に表示させる。script タグや複雑な HTML 構造が原因だった場合、以下のアプローチで回避できる。
script タグや iframe はカスタムHTMLブロックではなく適切な場所に配置する
Gutenberg のカスタムHTMLブロックは、セキュリティ上の理由から script タグの実行を制限している。また、ビジュアルエディターでの再レンダリング時に script タグを含むブロックを空として扱う挙動が確認されている。JavaScript を埋め込みたい場合は、カスタムHTMLブロックではなく、functions.php に wp_enqueue_script で登録するか、専用のコード埋め込みプラグインを使う。iframe も同様に、エディターのプレビューで空白になることがあるため、フロントエンドのみで描画される仕組みを検討する。
閉じタグのない空要素を見直す
カスタムHTMLブロックに <div></div> のような中身のない空タグや、閉じタグを省略した要素が含まれていると、Gutenberg のブロックパーサーが構造を正しく解釈できずにブロック全体をスキップすることがある。空の div や span は削除するか、 を入れて実体を持たせる。とくに WordPress の自動整形機能（wpautop）が余分な p タグや br タグを挿入することで、意図しない空要素が生まれることもある。
複雑なHTML構造はカスタムフィールドやショートコードに置き換える
テーブルやフォーム、装飾を多用したマークアップは、カスタムHTMLブロック1つにまとめるよりも、ACF（Advanced Custom Fields）のテキストエリアフィールドや、ショートコード化して出力する方が安定する。とくにクライアントが自分で編集する前提のサイトでは、カスタムHTMLブロックを直接触らせると今回のようなトラブルが再発しやすい。テーマ側でテンプレートパーツとして管理し、投稿画面では入力欄だけを提供する設計が安全だ。
今後同様のトラブルを防ぐための運用ポイント
カスタムHTMLブロックに貼り付ける前にコード検証を行う
外部の HTML スニペットをそのまま貼り付ける前に、W3C のバリデーターや VSCode の構文チェック機能でタグの閉じ忘れや文法エラーがないかを確認する。コピー元の Web ページから取得したコードには、不要な属性や非推奨のタグが混じっていることが多い。貼り付け前に一度テキストエディターにペーストし、明らかな問題を取り除いてからブロックに入力する習慣をつける。
WordPress と Gutenberg を最新バージョンに保つ
Gutenberg プラグインを単体でインストールしている場合は、定期的に更新することでブロックパーサーの改善や既知の不具合修正が適用される。コア組み込みのブロックエディターであっても、WordPress 本体のアップデートによってパースエンジンの挙動が改良されることがある。編集画面でカスタムHTMLブロックが空になる現象の一部は、過去のバージョンで修正されたバグに起因している可能性もあるため、まずは最新の状態であることを確認する。
どうしても必要な場合はコードエディターモードを常用する
ビジュアルエディターで空になってしまう HTML をどうしてもページに残したいときは、編集時にコードエディターモードに切り替えて作業する方法が最終的な回避策になる。データベースにコードが正しく保存されているなら、コードエディター表示では常に中身が確認できる。手間は増えるが、複雑なマークアップや埋め込みコードを扱うページでは、あらかじめこの運用を前提にしておくとトラブルが起きても編集が止まらない。
よくある質問
カスタムHTMLブロックの中身は完全に消えたのか
ビジュアルエディターでは空に見えても、コードエディターモードに切り替えると HTML が残っていることがほとんどだ。データベースの post_content にも保存されているため、失われたわけではない。
プラグインをすべて無効化しても直らない場合はどうすればいいか
テーマの functions.php や使用中の子テーマがエディターの動作に干渉している可能性がある。標準テーマ（Twenty Twenty-Five など）に一時的に切り替えて再現するか確認し、テーマ側のフィルターやアクションを調査する。
script タグをカスタムHTMLブロックで使う正しい方法はあるか
原則としてカスタムHTMLブロック内の script タグは推奨されない。管理画面でのレンダリング問題に加え、セキュリティプラグインやサーバー側のフィルターで除去されるリスクもある。どうしても必要な場合はショートコード化するか、wp_enqueue_script でテーマに登録するのが安全だ。
ビジュアルエディターで空白になる特定の HTML タグの一覧はあるか
公式の一覧は存在しないが、script タグ、style タグ、iframe、object、embed、空の div や span、コメントアウト行、複雑に入れ子になったインラインスタイル付き要素などが報告されている。問題が起きたら該当タグを一つずつ検証するのが確実だ。
ビジュアルエディターで空になる現象は Gutenberg のバグなのか
仕様とバグの両面がある。script タグの実行制限はセキュリティ上の意図的な制限であり、空要素のパース失敗はブロックエディターの改善が期待される領域だ。WordPress コアのバージョンアップによって挙動が変わることもあるため、最新バージョンへの更新が有効な場合が多い。
この記事のポイント
- カスタムHTMLブロックが空に見えてもデータはデータベースに残っている
- script タグや空要素、閉じタグ省略がパース失敗の主原因
- コードエディターモードで中身を確認し原因タグを特定する
- 複雑な HTML はカスタムフィールドやショートコードで管理する
- WordPress と Gutenberg の最新化で改善するケースがある
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.0リリース後の開発者情報まとめ（2026年6月版）
2026年5月20日にWordPress 7.0が正式リリースされた。その後1ヵ月の間に、メディア編集の刷新やクライアントサイドでの画像処理、テーマ向けスタイル機能の強化など、開発者にとって見逃せないアップデートが続いている。
本記事では、Developer WordPress News の「What’s new for developers? (June 2026)」を読み解きながら、6月に登場した主要トピックを整理する。プラグイン開発者、テーマ制作者、そしてサイト運営者が押さえておきたいポイントを中心に、実務への影響をわかりやすく解説する。
メディア編集モーダルがデフォルトに、画像処理の進化
画像の切り抜きがより直感的に
Gutenberg 23.3では、画像の切り抜き操作が専用のモーダルウィンドウで行われるようになった。これまでは編集画面内で直接操作していたが、今回の変更により、縦横比の指定や回転、反転、ズーム、メタデータの編集までひとつのモーダルに集約されている。
操作の入り口はこれまで通り「切り抜き」ボタンだが、編集体験は格段に整理された。プラグインで画像編集機能を独自に拡張している場合や、画像メタデータに依存する処理を組んでいる場合は、実際の画像を使ったキーボード操作やタッチ操作のテストが必要だ。
ブラウザ上で画像リサイズを行うクライアントサイド処理
もうひとつ注目したいのが、クライアントサイドメディア処理のテスト呼びかけだ。これは、可能な場合にはブラウザ上で VIPS/WASM パイプラインを使って画像のサブサイズを生成し、必要に応じてサーバーサイド処理にフォールバックする仕組みである。
対応形式はAVIFやWebP、HEIC、Ultra HDR、JPEG XL、GIFから動画への変換など多岐にわたる。ただし、現時点ではChromiumブラウザと最新のGutenbergプラグインの組み合わせに限られ、FirefoxやSafariでは無効、メモリが2GB以下のデバイスではスキップされる。通信速度が遅い場合やContent Security Policyの worker-src が制限的な場合も利用できない。
このデモでは、従来のようにサーバーがすべてのリサイズを担当する方法から、可能なときはブラウザが先に処理を引き受ける流れへの変化を示している。サーバーの負荷軽減とユーザー体験の向上が期待されるが、環境による制限があるため、フォールバックを含めたテストが欠かせない。
プラグインとツールを取り巻く重要な更新
React 19への移行は一時的に巻き戻されたが準備は続く
WordPress 7.0ではReact 19へのアップグレードが計画されていたが、Gutenbergでは一時的にこの変更が巻き戻された。理由は、複数のプラグインがReact 18のJSXランタイムヘルパーをバンドルしており、React 19と同時に読み込むとクラッシュする問題が発生したためだ。
コアチームはWordPress 7.1でのReact 19導入を目指し、より段階的な戦略で進める方針を示している。コンパイル済みのJSXを同梱しているプラグインや、@wordpress/element を使っている場合、またはエディターのプライベートAPIに触れている場合は、引き続きテスト環境で最新のGutenbergを試すことをおすすめする。
Abilities APIの拡充が進行中
Abilities APIはこれまでのラウンドアップでも取り上げられてきたが、6月も継続的に改良が進んだ。ライフサイクルフィルターや入出力のバリデーションフィルター、wp_get_abilities() へのフィルタリングサポート、サイトやユーザー、環境情報のレスポンス拡張、RESTスキーマの堅牢化などが行われている。
能力（アビリティ）を使った実験を始めている開発者は、以前の想定に頼りすぎず、トランクの最新の挙動を確認しておくとよい。
PHPサポートの明確化とUnicodeメールアドレス対応の提案
WordPress 6.9および7.0では、PHP 8.5を完全にサポートすることが正式に明文化された。これにより、古い「ベータサポート」ラベルは廃止され、WordPress 7.0時点での最低動作バージョンはPHP 7.4、推奨はPHP 8.3に整理されている。
一方で、メールアドレスやユーザー名、スラッグにおけるUnicode対応を拡張する提案も公開され、フィードバックが募られている。この提案は is_email() や sanitize_email() などの関数、フィルター、データベース格納、文字の正規化などに影響を及ぼす可能性があり、メールアドレスを扱うプラグインは早めに内容を確認しておく価値がある。
AI Clientを使った画像生成プラグインのチュートリアル
4月・5月のラウンドアップで紹介されたAI ClientとConnectors APIに関する実践的なチュートリアルが登場した。ここでは、画像生成プラグインを構築する方法が解説されており、特に機能検出パターンが参考になる。プラグインは、プロバイダーが設定済みかどうか、そして必要な機能をサポートしているかを確認したうえでUIを表示すべきであり、チュートリアルではメディアライブラリから画像を生成し、添付ファイルとして保存する一連の流れが実装されている。
テーマ開発者向けのスタイルとブロックの改善
単一ブロックインスタンスへの擬似状態スタイルの適用
Gutenberg 23.3では、個別のブロックインスタンスに対して :hover や :focus、:visited といった擬似状態のスタイルを設定できるようになった。これまではサイト全体のブロックすべてに影響するスタイルしか設定できなかったが、この変更により、特定のボタンだけホバー時の色を変えるといった細やかな制御が可能になる。
この機能は、Add supports for pseudo states on single block instances というPRで実装されており、長年課題となっていたインタラクティブな状態の標準化に向けた動きとして注目されている。ボタンやリンク、ナビゲーションのデザインにこだわるテーマ制作者は、Gutenbergでテストしてみるとよい。
レスポンシブ対応のスタイル状態がさらに拡張
レスポンシブかつ状態を考慮したスタイル設定は、Gutenberg 23.2と23.3で大きく前進した。23.2ではグローバルなブロックスタイルに状態付きのレスポンシブ設定が導入され、23.3ではレイアウトのレスポンシブスタイルや、状態選択時に一部のコントロールを隠すUI調整が加えられている。
まだGutenbergプラグインでのテスト段階だが、theme.jsonのプリセットや設定、レイアウトプリセット、ブロックサポート、カスタムレスポンシブコントロールに依存しているテーマにとっては影響が大きいため、Responsive style states for blocks 、 iteration for WP 7.1 のIssueを追いかけておくとよい。
その他テーマ向けのブロックアップデート
細かいが実務に効く変更もいくつか入った。グローバルスタイルのカラーパネルでスラッグベースの色選択が統合され、ホームリンクブロックに不足していたコントロールが追加された。パンくずブロックでは視覚的な区切り文字がスクリーンリーダー向けに非表示となり、ナビゲーションでは非推奨化された block_core_navigation_submenu_render_submenu_icon() 関数のシムが復活している。画像ブロックでは幅か高さの片方だけが設定された場合に出力が崩れる問題も修正された。
また、WordPress 7.0では著者アーカイブリンクのデフォルトの title 属性（「Posts by Author」）が削除されている。マークアップのわずかな変更だが、テーマの表示テストやスナップショットテストに影響する可能性があるため注意しておきたい。
WordPress Playgroundの最新動向
wp-nowが非推奨に、Playground CLIへの移行を
ローカル環境を手早く立ち上げるために wp-now を使っていた開発者は、Playground CLIへの移行が必要になる。Developer WordPress Newsの記事によると、2026年6月8日付でwp-nowが非推奨となり、今後の推奨パスはPlayground CLIに一本化された。
移行は比較的スムーズに行えるよう設計されており、テスト用サイトを素早く立ち上げたいプラグイン開発者やテーマ制作者は、早めに切り替えておくとよいだろう。
PRプレビューとPHPスニペットの公式ガイド
Playground関連では、2つの役立つガイドも公開された。ひとつは「PR Preview with WordPress Playground: What changes in version 3 of the GitHub Action」で、プルリクエストのプレビューを自動化するGitHub Actionの最新バージョンについて解説している。プロジェクトでPlaygroundプレビューを利用しているなら、一度目を通しておきたい内容だ。
もうひとつは「Run PHP examples anywhere with WordPress Playground」で、WordPressの開発者向けドキュメントやチュートリアルに、ブラウザ上で実行可能なPHPサンプルを埋め込む方法を紹介している。技術記事を書く立場の開発者にとって、この手法は読者の理解を大きく助ける強力な武器になる。
保存型Playgroundと古いWordPressバージョンの復元
Playground v3.1.35およびv3.1.36では、サイトの保存とSites APIの機能が大きく進んだ。保存したブラウザ上のWordPressサイトに何度も戻れる永続化の仕組み、自動保存からの復元UX、埋め込みPlaygroundでの不要な保存プロンプト回避などが実装されている。
さらに、WordPress 0.7 のような過去のバージョンを丸ごとロードできるようになり、Virtual WordPress Museum のようなデモも登場した。デモやテスト、教育目的の用途が一層広がる変更といえる。
PHP.wasmによる高度なデモやフレームワーク対応
PHP.wasm周辺の開発も活発だ。新しい「Running PHP Frameworks in Playground」ガイドでは、WordPress以外のPHPフレームワークをPlayground上で動かす方法が示されており、ブラウザベースのツール構築の可能性を大きく広げている。また、@php-wasm/compile-extension ワークフローにより、PHP拡張のコンパイルも以前より容易になった。高度なデモやドキュメント用のサンプルを作る開発者には、これらの進歩も見逃せない。
ユーザーインターフェースとアクセシビリティの改良
実験的なダッシュボードのカスタマイズ機能がウィジェットを追加
カスタマイズ可能なダッシュボードはまだ実験段階だが、Gutenberg 23.3では新たに5つのウィジェット（サイトヘルス、ニュース、イベント、クイックドラフト、サイトプレビュー/URLバー）が追加され、レイアウトの調整も進んだ。ゴーストウィジェットやサイズプリセット、コンテナブレークポイントによるグリッドカラムなど、徐々に実用性が高まっている。
管理者画面の拡張やプラグイン独自の管理パネルを開発しているなら、この実験がどこに向かっているのかを customizable dashboard overview issue で追いかけておくことをおすすめする。
エディターと管理画面でのアクセシビリティの磨き込み
GutenbergとCoreの両方でアクセシビリティ関連の改善が続いている。Gutenberg 23.3ではリビジョン機能が改善され、フォントライブラリのフォーカスナビゲーションも修正された。Core側では、管理画面のカラースキームのコントラスト強化、フロントエンドツールバーのフォーカスアウトライン修正、ハイコントラストモード時のボタンアクティブ状態の不具合対応などが行われている。
カスタム管理画面やエディターパネル、メディア操作UIを提供している場合は、キーボード操作、ハイコントラストモード、文字サイズの拡大設定、標準以外の管理画面カラースキームを組み合わせたテストを定期的に実施することが重要だ。
この記事のポイント
- メディア編集はモーダルに集約され、クライアントサイド画像処理の実験的テストも始まった。サーバー負荷の低減とUX向上が見込まれる
- React 19移行は一時停止中だが、WordPress 7.1に向けた準備は継続。プラグイン開発者は互換性を確認しておく
- テーマ開発では、単一ブロックへの擬似状態スタイル適用やレスポンシブスタイルの拡張など、表現力が高まる変更が多い
- PlaygroundはCLIへの一本化、保存型サイトの強化、過去バージョン対応などで開発者の実験環境が飛躍的に便利になった
- アクセシビリティの改良も着実に進行。カスタムUIを作るならテストにキーボード操作やハイコントラストモードを含める
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WooCommerce商品管理が大幅刷新へ、DataViewsで超高速カタログ操作
WooCommerceの商品管理画面が、WordPressのDataViewsとDataFormsという基盤技術を用いて根本から再構築された。2026年5月21日、Automatticの開発者らが4週間の「Radical Speed Month」で生み出した概念実証（PoC）として公開したものだ。
このPoCは実際に動作し、WooCommerceのコアに機能フラグ付きで組み込まれている。商品一覧の高速な検索・絞り込み、バリエーションの階層表示、そして長年要望の多かったクイック編集と一括編集を、サードパーティ製プラグインなしで実現する。現在50以上存在する補完系拡張機能の多くが不要になる可能性を秘めた、意欲的な試みだ。
これはリリースを約束するものではなく、コミュニティからのフィードバックを得るための実験的ビルドである。大規模カタログでのパフォーマンス、拡張機能向けのAPI整備、一括編集の堅牢化など、まだ多くの課題は残る。しかし、WooCommerceの管理画面体験がどこへ向かおうとしているのか、その方向性をはっきり示すものとなっている。
カタログ管理が抱えてきた構造的な問題
商品管理はWooCommerce店舗運営の中核業務だ。それにもかかわらず、管理画面の体験はマーチャントの期待に追いついていなかった。ユーザーから繰り返し寄せられていた要望は、より優れた検索とフィルタリング、多数の商品を横断的に操作できる一括編集、情報量の多いクイック編集、そしてバリエーションを親商品から開かずに一覧できる仕組みだった。
このギャップを最も如実に物語るのが、エコシステムの現状だ。WooCommerceの商品管理ワークフローを補完するために、クイック編集拡張、一括編集ツール、スプレッドシート形式のグリッド、カスタムカラムマネージャーなど、50以上の拡張機能が存在している。これは「拡張性がある」という健全な状態ではない。コアが基本的な操作フローすら提供できておらず、マーチャントが他社製プラグインで組み立てざるを得ない状況を意味する。
今回のプロジェクトが問いかけたのは、WordPressコアがDataViewsとDataFormsをプリミティブとして提供するようになった今、「全商品」画面をそれらのネイティブ機能で再構築できるのか、そして拡張機能エコシステムが補ってきた機能を失わずに済むのか、という点だ。
この比較図が示す通り、刷新後の画面では商品操作の導線が大幅に短縮される。特にバリエーションの扱いは、従来の「個別クリックで詳細画面へ」から「一覧上で即時展開」へと変化し、数十のバリエーションを持つストアでの作業効率が大きく変わる見込みだ。
4週間で構築された3つの主要機能
この概念実証は、フル機能の再設計ではなく、最も差し迫った3つの要素に集中して開発された。いずれもWordPressコアが提供する既存のプリミティブの上に構築されており、アドオン的ではなくネイティブな操作感を実現している。
これらの機能は、WooCommerceチームがこれまで外部拡張に委ねていた中核的な操作を、ついにコアに取り込む試みだ。特に注目すべきは、WordPress 6.5以降で導入されたDataViewsとDataFormsというプリミティブを活用している点である。これらは管理画面のデータ表示と編集フォームを抽象化するAPIで、サイトエディターなどで実績を積んだ技術だ。WooCommerceチームはこの技術をEC特化の文脈に応用し、商品管理に適したUIへと転用している。
現在の制約とこれからの重点課題
このPoCは完成した機能ではなく、あくまで検証用の実験的ビルドである。現時点で最も重要な制約は、大規模カタログでのパフォーマンスだ。開発チームは4週間という短期間でコア体験の検証を優先したため、商品数やバリエーションが数千を超えるストア向けの最適化はこれから取り組む段階にある。
今後の作業として、開発チームは次の3つの領域を次の重点課題と位置づけている。
いずれも、現時点でPoCを試用する妨げにはならない。しかし開発チームが今このタイミングでフィードバックを募る理由はここにある。APIの基盤設計が本格化する前に、実際の利用者や拡張機能開発者からの具体的な意見を得たいのだ。
コミュニティに求められるフィードバック
開発チームが特に聞きたいのは、次の3つの観点だ。
- マーチャントとストア構築者から 実際の商品管理業務と比較して、この体験が通用するかどうか。どの操作で時間が節約でき、どの部分が作業の妨げになるか。
- 拡張機能の開発者から 現在依存している統合パターンをDataViewsネイティブテーブルにきれいに移行するために何が必要か。仕事に最も影響するフック、フィルター、カスタマイズポイントはどれか。
- すべての人から 粗削りな部分、「10秒間混乱した」瞬間、挙動に驚いた点、探したが見つからなかった機能。
なお、移行とAPI連携の作業はこのPoCの範囲外だが、その計画は現在進行形で進められている。このテーブル基盤を利用・拡張する人々から早期に意見を得られれば得られるほど、最終的な実装の形はより良いものになる。
実際に試す方法
このPoCには、技術的な環境構築なしで触れられる手段を含め、複数の試用経路が用意されている。
Playgroundデモは特に注目に値する。WordPressのブラウザ上で動作する瞬間実行環境であり、サーバーやローカル環境の準備が一切不要だ。WooCommerceの開発チームが専用のブループリントを用意したことで、数クリックで刷新された商品管理画面を試せる。このようなハードルの低さは、コミュニティからの広範なフィードバック収集を促す重要な施策である。
この記事のポイント
- WooCommerceの商品管理画面がDataViewsとDataFormsで再構築され、概念実証として公開された
- バリエーションの階層表示、カスタマイズ可能なテーブル、クイック編集・一括編集のネイティブ実装が含まれる
- 大規模カタログでのパフォーマンス、拡張機能向けAPI、一括編集の堅牢化が今後の重点課題
- Playgroundデモで環境構築不要の即時試用が可能で、コミュニティからのフィードバックを募集中
- これはリリース確定機能ではなく、方向性を探るための実験的ビルドである
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0 RC4リリース、正式版は5月20日予定
WordPress 7.0のリリース候補第4版（RC4）が2026年5月14日に公開された。正式版のリリース予定日は5月20日で、今回のRC4はその最終段階にあたるバージョンだ。すでに本番環境への適用は推奨されていないが、テスト環境での検証を通じて、より安定したWordPress 7.0のリリースに貢献できる段階に入っている。
リリース候補版とは、正式版と同等の品質を持つと判断されたバージョンのことだ。しかし、さまざまな環境やプラグインとの組み合わせで予期せぬ問題が発生する可能性は常に残る。そのため、RC4の段階でもコミュニティ全体でのテストが引き続き重要になる。本記事ではRC4のテスト方法と協力の手段を整理し、WordPress 7.0の正式リリースに向けた現状を解説する。
WordPress 7.0 RC4の概要とテスト方法
RC4はリリースサイクルの最終段階
WordPressの開発プロセスでは、アルファ版、ベータ版、リリース候補版（RC）の順に段階を踏んでいく。RCは「リリース可能」と判断された状態を指し、新機能の追加は停止され、バグ修正と安定化に集中するフェーズだ。RC4はこの最終段階の4回目のビルドにあたる。WordPress 7.0の開発において、これまでのRC1〜RC3で発見された問題が修正され、さらに安定性が高められている。
今回のRC4では、2026年5月8日以降に報告された問題に対応する修正が含まれている。具体的な変更点はWordPress Core TracやGutenbergのGitHubリポジトリで確認できる。特にブロックエディタ関連のコミットが多く、エディタの動作安定性が向上している点が特徴だ。
テスト環境を用意する4つの方法
RC4のテストは以下の4つの方法で行える。いずれも本番サイトでの使用は避け、必ずテスト用の環境で実行することが前提だ。
上記の4つの方法のうち、WordPress Playgroundは特に導入のハードルが低く、環境構築の手間なくRC4の動作を確認したい場合に有効だ。テストサーバーを用意できない場合でも、ブラウザひとつでブロックエディタの新機能やテーマとの互換性を試せる。
RC4に含まれる修正と技術的な詳細
WordPress Core Tracのクローズチケット
RC4では、2026年5月8日から5月14日までの間に報告されたWordPress Coreのチケットがクローズされている。これらは主にRC3までのテストで発見されたバグや、エッジケースでの動作不具合に対応するものだ。具体的なチケットの一覧は公式のTracで公開されており、コンポーネントごとに分類された修正内容を確認できる。
また、Gutenbergのコミットログにも同期間の修正が反映されている。ブロックエディタはWordPress 7.0の中核機能であり、RC段階でのエディタ関連の修正は正式版の品質を左右する重要な要素だ。GitHubのコミット履歴を追うことで、どのブロックやAPIに変更が加えられたかを詳細に把握できる。
ハードストリングフリーズと言語翻訳
RC4の公開と同時に、翻訳のハードストリングフリーズ（Hard String Freeze）が実施された。これは、WordPress 7.0のインターフェースに含まれる文字列が確定し、これ以上の変更が行われないことを意味する。翻訳コントリビューターはこのタイミングで、100以上の言語へのローカライズ作業を集中して進められる。
翻訳作業に参加するには、WordPressの翻訳プラットフォーム（translate.wordpress.org）でプロジェクトに参加し、未翻訳の文字列を各言語に翻訳していく。日本語を含む多くの言語で、正式リリースまでに翻訳を完了させることが目標とされている。
WordPress 7.0の正式リリースに向けたスケジュール
5月20日の正式リリース予定
WordPress 7.0の正式リリースは2026年5月20日に予定されている。RC4がテストでの最終関門となり、ここで重大な問題が発見されなければ、予定通り正式版が公開される見込みだ。ただし、リリース候補版の段階で新たな重要課題が見つかった場合には、RC5やさらなる修正が行われる可能性もある。
WordPress 7.0の開発スケジュール全体は、Make WordPress Coreブログで公開されている。7.0関連の投稿にはタグが付与されており、過去のベータ版やRC版の詳細、フィールドガイド（開発者向けの技術解説）などがまとめて参照できるようになっている。
テスト参加が正式版の品質を左右する
RC版のテストに参加することは、WordPressの品質向上に直接貢献する手段だ。テストは開発者だけでなく、普段WordPressを使用しているサイト運営者であれば誰でも参加できる。使用しているテーマやプラグインとの互換性を確認し、問題があれば報告することで、正式リリース時のトラブルを未然に防げる。
バグの報告は、サポートフォーラムのAlpha/Betaエリアか、WordPress Tracで直接行う。再現手順を明確に記載したバグ報告は、開発チームが問題を迅速に特定し修正するための重要な手がかりとなる。また、既知のバグ一覧と照合することで、重複報告を避けられる。
コミュニティによる協力と貢献の方法
テスト参加の具体的な手順
WordPress 7.0のテストに参加するための詳細なガイドが公式テストチームから公開されている。このガイドでは、テスト環境のセットアップから、確認すべき機能、バグ報告の方法までが段階的に説明されている。テスト初心者向けの一般的なセットアップガイドも用意されており、初めてテストに参加する場合でも迷わずに始められる。
テスト中に問題を発見した場合は、前述のAlpha/BetaフォーラムかWordPress Tracに報告する。Tracでの報告に慣れている場合は、再現手順を含めた詳細なチケットを作成することで、開発チームが効率的に対応できる。また、Make WordPress Slackの#core-testチャンネルでは、テストに関する最新情報の共有や、他のテスターとのコミュニケーションが行われている。
翻訳以外の貢献手段
WordPressはオープンソースプロジェクトであり、コードのコントリビューション以外にもさまざまな貢献手段が用意されている。ドキュメントの作成、フォーラムでのサポート、イベントの運営、アクセシビリティの検証など、技術スキルに関係なく参加できる分野が多い。
WordPress 7.0のリリースに向けては、テストと翻訳が特に重視されている段階だ。RC4の段階ではコードの変更は最小限に抑えられているため、テストと翻訳がコミュニティによる主な貢献領域となる。Make WordPress Coreブログでは、7.0関連の最新情報が継続的に発信されているため、関心のある分野の投稿をフォローすることで、自分に合った参加方法を見つけられる。
この記事のポイント
- WordPress 7.0 RC4が5月14日に公開され、正式リリースは5月20日を予定している
- テスト方法はプラグイン、直接ダウンロード、WP-CLI、Playgroundの4つから選択できる
- RC4では5月8日以降のバグ修正が含まれ、翻訳のハードストリングフリーズも実施された
- テストと翻訳は正式版の品質を左右する重要なコミュニティ貢献の手段である
- 本番環境でのRC4の使用は避け、テスト環境での検証を行うことが前提となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0 RC3リリース。RTCは延期、最終版5月20日を前に最後のテストを
WordPress 7.0の3回目のリリース候補版（RC3）が、2026年5月8日に公開された。すでにテストを開始しているサイト管理者や開発者にとっては、最終版の品質を左右する重要なマイルストーンだ。今回のRC3では、前回のRC2以降に報告された143件以上の問題が修正されている。
正式版のリリース日は5月20日を予定しており、このRC3は「最後の仕上げ」をする段階に入ったことを意味する。本番運用中の重要なサイトへのインストールは避け、必ずテスト環境で検証することが強く推奨されている。
とりわけ今回大きな動きとして、かねてから注目を集めていた「リアルタイムコラボレーション（RTC）」機能が、7.0への搭載を見送られることが正式に発表された。この決定により、RC3は当初の開発計画から一部構成が見直されたバージョンとなっている。
RC3で何が変わったのか
RC3は、3月26日に公開されたRC2以降に報告されたバグや課題を集中的に潰し込んだバージョンだ。WordPress.orgの公式発表によれば、今回のRC3では以下のリンク先で確認できるすべての修正が含まれている。
RC2からの主な修正範囲
開発者向けの詳細な技術情報は、WordPress 7.0 Developer Notesにまとめられている。また、コア部分の修正については、3月26日以降にクローズされたTracチケット、およびGutenbergのコミット履歴から追跡できる。これらの情報を確認することで、自分の運用するテーマやプラグインへの影響を事前に評価できるだろう。
リアルタイムコラボレーションは7.1へ延期
最大のトピックは、RTC（Real Time Collaboration）機能の延期決定だ。この機能は、複数ユーザーが同時にブロックエディタ上でコンテンツを編集できるようにするもの。Googleドキュメントのような共同編集体験をWordPress管理画面で実現する構想として、多くの注目を集めていた。
しかし、7.0のリリースサイクル中に十分な安定性を確保できないと判断され、今回のRC3では搭載が見送られた。WordPressコアチームは、この機能を7.1の開発サイクルで再評価するとしている。RC3は、この変更に伴い「新たなBeta 1」とは見なされないポジションとなったことにも注意が必要だ。
RC3のテスト方法
テストは、本番環境を避け、テストサーバーやローカル環境で行うことが大前提だ。WordPress 7.0 RC3を試す方法は大きく4つ用意されている。
wp core update --version=7.0-RC3 コマンドを実行する。なかでもWordPress Playgroundは、ブラウザだけで完結するため手軽だ。環境を汚さずに新機能や互換性をざっくりと確認したい場合に適している。より本格的なテストには、テストサーバーへの直接インストールを推奨する。
開発者とホスティング事業者に求められる対応
RC3の登場は、テーマやプラグインの開発者、そしてホスティング事業者にとっても重要な意味を持つ。最終リリースまで2週間を切った今、互換性の最終確認を急ぐ必要がある。
テーマ・プラグイン開発者のやるべきこと
プラグインやテーマの製作者は、RC3を使って自社製品の動作検証を完了させ、「Tested up to」のバージョンを7.0に更新することが求められている。これは、プラグインのreadmeファイルに記載する情報で、ユーザーが「このプラグインは最新のWordPressで動作確認済みか」を判断する重要な指標となる。
互換性に問題が見つかった場合は、詳細な情報をサポートフォーラムのAlpha/Betaエリアに報告することで、コア開発チームや他の開発者との情報共有につながる。
ホスティング事業者のテスト協力
Webホスト各社も、WordPressのメジャーアップデートに向けて重要な役割を担っている。特に今回の7.0開発サイクルでは、RTCアーキテクチャのテストに複数のホスティング事業者が協力した。Kinsta、Bluehost、GoDaddy、WordPress.com、XServer、Ionosなどの企業が、さまざまなサーバー構成での動作検証に参加している。
ホスティング環境でのテストに関心がある事業者は、Make WordPress Hostingチームのドキュメントに従って分散テストの設定を始めることができる。
翻訳も最終段階。100言語以上への対応が進行中
RC3のリリースは、翻訳作業における「ハードストリングフリーズ」のタイミングでもある。これは、これ以上翻訳対象の文字列が変更されないことを意味し、翻訳ボランティアが安心して作業を進められる段階に入ったということだ。
日本語を含む100以上の言語への翻訳作業が進行中で、5月20日の正式リリースに向けて最終的な仕上げが行われている。翻訳プロジェクトへの参加は、技術的なスキルがなくてもWordPressコミュニティに貢献できる方法のひとつだ。
不具合を見つけたら報告を
テスト中に不具合や予期しない動作を発見した場合、以下のいずれかの方法で報告できる。
- サポートフォーラムのAlpha/Betaエリアに投稿する
- 再現手順を明記したバグレポートをWordPress Tracに直接登録する
- 既知のバグ一覧と照合し、報告済みかどうかを確認する
テストの経験が浅い場合でも、公式のテストガイドが用意されている。手順に沿って進めることで、開発に貢献しながらWordPressの内部構造への理解も深められるだろう。
この記事のポイント
- WordPress 7.0 RC3が5月8日に公開。RC2から143件以上の問題を修正
- RTC（リアルタイムコラボレーション）機能は7.0への搭載を見送り、7.1で再検討
- 正式リリースは5月20日を予定。テスト環境での検証が急がれる
- テーマ・プラグイン開発者は「Tested up to 7.0」への更新を
- テスト方法はプラグイン、直接DL、WP-CLI、Playgroundの4種類
- 翻訳作業はハードストリングフリーズに入り、100言語以上が最終段階
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験