目次
WordPress 7.2 Beta 2が2026年10月27日に公開されました。テーマやプラグイン、独自の管理画面を保守するチームは、正式版を待つ前に編集業務への影響を確かめられます。最初に行うのは本番の更新ではなく、現行版での基準を残したテスト環境の準備です。保存できるかだけでなく、保存後の再編集と公開側の表示まで一組で比較します。
本稿は2026年10月29日に確認したWordPress公式のBeta 2発表に基づく実践解説です。公式はベータ版をテスト・開発用途に限定し、本番や重要なサイトで実行しないよう案内しています。以下の比較設計は本サイトの提案であり、Beta 2を実環境へ導入して動作確認した結果ではありません。
スポンサーリンク
ベータ公開を本番更新の合図にしない
正式版の予定日は2026年12月8日と案内されていますが、これは公開の保証ではありません。現時点でベータを使う目的は、採用を急ぐことではなく、正式版に向けて問題を見つけ、担当者と再現手順を整理することです。通常の保守更新の計画と、開発版を評価する計画を分けて管理します。
確認対象は自分たちが実際に使う機能から選びます。記事を作るメディアなら見出し、画像、再利用するパターン、予約公開など、日常の編集経路が中心です。独自画面を持つプラグインなら、その画面で一覧を開き、条件を変え、値を保存して再表示する操作を対象にします。使わない機能を網羅するより、停止すると困る経路を先に通します。
試用と互換性確認で環境を使い分ける
公式はWordPress Beta Testerプラグイン、ZIPの直接ダウンロード、WP-、WordPress Playgroundを検証方法として挙げています。画面を短時間で触るなら公式発表からPlaygroundへ進む方法があります。一方、既存サイトの互換性を判断するには、利用中のテーマやプラグインをそろえた別環境での比較が必要です。
ブラウザー内で新しい画面を確認できたことは、自社のPHP構成、DB、外部サービスとの連携が動く証拠にはなりません。最初の試用では操作の変化を把握し、次の段階で本番に近い構成へ移ると目的が明確になります。試用の結果と移行可否の判定を同じチェック欄にまとめないようにします。
既存サイトを複製する場合は、送信先を必ず見直します。問い合わせメール、決済、、予約通知が本番の相手へ届く構成のまま、検証で何度も保存してはいけません。これはBeta 2固有の不具合ではなく、本サイトが勧める検証環境の前提です。実データの複製範囲を絞り、試験用の宛先と識別できるデータで操作します。
スポンサーリンク
更新前の構成と操作結果を記録する
比較前にWordPress、PHP、テーマ、プラグインの版を記録します。新しいコアへ変えるのと同時に全プラグインを更新すると、不具合がどの変更で生まれたかを追いにくくなります。まず現行構成で正常な操作を記録し、同じ構成の複製でコアだけを変える比較を用意します。別の更新が必要なら、その差分も記録へ追加します。
WP-CLIを使える環境なら、core versionの公式資料、plugin list、theme listを参照して構成を採取できます。次は検証用ディレクトリーを指定する例で、パスは実際の環境へ置き換えます。
wp --path=/srv/wp-beta-test core version --extra
wp --path=/srv/wp-beta-test plugin list --fields=name,status,version --format=json
wp --path=/srv/wp-beta-test theme list --fields=name,status,version --format=jsonコマンドの出力は、比較する環境ごとに区別して保存します。プラグイン名だけでなく有効状態も必要です。無効なプラグインを一覧に含めたまま、全部の連携を試したと解釈しないでください。マルチサイト、常時読み込むプラグイン、など、一覧の見方だけでは十分でない構成もあるため、管理対象の独自設定を併記します。
対象を明示してBeta 2を入れる
公式発表はWP-CLIでの指定を示しています。core updateの仕様では、--versionで対象版を選べます。次の例は検証サイトだけで実行する想定です。本稿ではこのコマンドを実行しておらず、成功メッセージや所要時間を実測値として示していません。
wp --path=/srv/wp-beta-test core update --version=7.2-beta2
wp --path=/srv/wp-beta-test core version指定を省略した更新と特定のベータ版を入れる操作は目的が異なります。再現に使った版を確定したいときは、更新後の表示を読んで記録します。コマンドが終了しただけで、管理画面の操作まで正常になったとは扱いません。更新処理の成功、ログイン、記事編集、公開側の表示を順番に分けて確認します。
取得や更新に失敗した場合は、その環境とエラーを残し、公式の別の検証方法を検討します。証明書検証を弱めたり、稼働中かもしれない更新ロックを機械的に消したりすることを通常手順にはしません。目的は再現できる比較環境を作ることであり、エラー表示だけを消して先へ進むことではありません。
スポンサーリンク
編集して保存し再び開くまでを試す
代表的な記事を複製し、見出し、段落、リスト、表、画像を含むサンプルを用意します。新規作成だけでなく、既存記事を開いて一箇所を修正する操作も含めます。保存前の画面が正常でも、保存された内容や再編集時の解釈が変わる可能性を確認するためです。長い記事と短い記事で操作感が違うなら結果を分けます。
試験では、変更内容、保存結果、ページを開き直した結果、公開側の結果を残します。プレビューだけの成功と、保存後のページ表示の成功も区別します。画像の代替テキスト、リンク、表の内容など、見た目だけでは見逃す項目を選ぶとよいでしょう。問題がなかった場合も、どのデータで何を確認したかを記録します。
複数の編集者がいる運用なら、普段使う役割でも確認します。管理者だけで通る機能が編集担当者でも通るとは限りません。権限エラーを見つけたときは、すぐに強い役割へ変えて回避せず、現行版の同じ役割と比較します。必要な操作ができることと、想定しない操作が増えていないことの両方を受け入れ条件にします。
比較するデータと判定表を固定する
例えば「画像のある既存記事を編集担当者が開き、説明文を変えて保存する」を一行の試験にします。入力する文、使う画像、操作する役割を固定し、現行版とBeta 2で同じ順序を通します。途中で素材を差し替えると、再現しない理由が版の違いなのか入力の違いなのか分からなくなるためです。
判定表には、操作名、前提、期待結果、実際の結果、証拠の場所を用意します。画面のスクリーンショットだけでなく、保存したページや該当ログへたどれる情報も添えます。検証担当と公開判断の担当が別でも、何が確認済みかを読み取れる粒度にします。失敗した行を消さず、修正後の結果を別に残すと経過を追えます。
作業時間が限られる場合は、停止したときの業務影響で優先順位を付けます。公開不能や保存内容の欠落を先に、表示上の小さな差をその後に確認します。この優先付けは試験対象を明示するための提案で、未確認部分が安全だという意味ではありません。次回へ持ち越す行と担当を決めておけば、検証の抜けを見失わずに続けられます。
不具合は一度に一つの条件を変えて絞る
不具合が出たら、最初に同じ操作が現行版でも起きるかを確認します。次に、別のテスト用複製でテーマや関連プラグインの条件を一つずつ変えます。すべてを無効化して直ったという結果だけでは原因の範囲が広すぎます。独自ブロックなら最小の記事、独自管理画面なら最小の入力へ絞り、再現に不要な要素を減らします。
画面が固まる場合は、操作した時刻、ブラウザーのコンソール、通信のステータス、サーバー側の記録を対応付けます。通信が失敗したことと、返ったデータを画面が処理できなかったことは別です。ログへ個人情報や秘密値を丸ごと残さず、調査に必要なエラーと対象操作を中心に保存します。キャッシュを変えた場合も、その条件を記録します。
再現しないことも結果の一つです。毎回起きる現象と、一度だけ観測した現象を分け、回数と条件を添えます。推測した原因を確定事項として報告せず、確認できた手順と期待した結果、実際の結果を先に書きます。別の担当者が同じ複製環境で試せる記録なら、コア側と拡張側のどちらへ相談する場合も役に立ちます。
検証が終わった環境を次回も比較できる形にする
ベータ版で変更したDBやファイルを、そのまま本番へ戻す計画にはしません。検証開始前の状態から作り直せるよう、元の構成と試験データを保持します。コアのファイルだけ古い版へ戻しても、保存した設定やデータの変化まで取り消せるとは限らないからです。検証環境の復元と本番への移行は別の手順として扱います。
合格判定は「エラーが出なかった」だけにしないでください。普段の役割で記事を保存できる、開き直して内容が保たれる、公開側が意図どおり表示される、必要な連携が試験用の宛先で成立する、といった具体的な条件を置きます。未確認の項目は未確認と残し、合格の範囲を広げて表現しないことが大切です。
最後に、対象版、環境の構成、試した経路、問題、担当者、再確認する条件をまとめます。今後のBetaやRCで同じ経路を再実行できれば、一回の試用が継続的な互換性確認になります。正式版の公開予定が近づいても、本稿だけを根拠に本番更新を決めず、実際の提供状況と自分たちの検証結果を改めて照合してください。
スポンサーリンク
参考資料
WordPress公式：7.2 Beta 2の公開と検証方法
WP-CLI：core update
WP-CLI：core version
WP-CLI：plugin list
WP-CLI：theme list
