2026年7月22日に WordPress 7.1 Beta 3 が出た。正式版は8月19日予定で、残り3週間ほど。子テーマを自分で書いて運用しているサイトにとって、この期間にやるべきことは絞れる。11年かけて開発された Unicode メールアドレス対応が 7.1 から外れた件も、7.1 の性格を示している。
目次
Beta 3 で確定した変更
開発者に関係する変更は2つある。
WordPress Coding Standards が 3.4.0 へ更新された。自作テーマやプラグインに静的解析をかけている場合、指摘の内容が変わる可能性がある。
Unicode メールアドレス対応は 7.1 に含めない。コアへマージされてから6週間後の判断で、Unicode が持ち込む影響範囲の広さとセキュリティ面の懸念が理由とされている。作業はコミュニティプラグインで継続し、互換性やデータの扱いを広くテストする形になる。
ほかにメディア処理まわり（GIF アップロード、EXIF による回転、HEIC の扱い）とブロックインスペクタのスタイリング調整が入っている。
WPCS 3.4.0 で指摘が増える箇所
コーディング規約の更新は、地味に見えて作業量に直結する。ルールが追加されれば、これまで通っていたコードに指摘が付く。
子テーマで指摘が出やすいのは、テンプレート内で変数をそのまま出力している箇所になる。echo $title; のような書き方は、エスケープ関数を通す形へ直す必要がある。数が多いと、機械的な置き換え作業が数十箇所ぶん発生する。
ここで判断が要るのは、どのエスケープ関数を使うかだ。HTML の本文なら esc_html()、属性値なら esc_attr()、URL なら esc_url()。用途を取り違えると、動作は変わらないのに保護が効かない状態になる。静的解析は「エスケープしていない」ことは指摘するが、「間違ったエスケープを選んでいる」ことまでは教えてくれない。
筆者は指摘の一覧を出した後、まとめて直す前に3件ほど手で直してみるようにしている。パターンが掴めてから残りを処理すると、取り違えが減る。
11年の機能が直前で外れたという事実の読み方
Unicode メールアドレス対応は、長く議論されてきた機能だ。コアにマージされた時点で 7.1 に載ると考えた人は多かったはずで、筆者もそう思っていた。
ここから読み取れるのは、マージ済み＝リリース確定ではないという運用の実態になる。ベータ期間中に外れる機能がある前提で、自分のサイトの準備を組む必要がある。
具体的には、新機能を当てにした実装を正式版前に入れない。「7.1 で入るはずだから」と先回りして書いたコードは、外れた瞬間に無駄になる。今回はメールアドレスの検証まわりが該当した。
ベータ情報を追う手間をどこまでかけるか
毎回のベータを丁寧に追うのは、個人でサイトを運営していると負担になる。筆者が見ているのは、リリースノートの中の2種類だけだ。
自作コードに関係する変更（コーディング規約、API の非推奨、ブロック関連の仕様）と、自動で走る処理に関係する変更（メディア処理、更新の挙動）。デザインや新機能の紹介は、正式版が出てから読んでも遅くない。
この絞り方をしていると、ベータの記事1本を読むのに5分もかからない。今回で言えば、WPCS の更新と Unicode 対応の見送りの2点が引っかかった。前者は手を動かす対象で、後者は待つ判断の材料になる。
子テーマ持ちが3週間でやること
筆者は WordPress サイトを子テーマで運用していて、更新のたびに壊れる箇所を探す作業をしている。優先順位をつけると、次の順番になる。
| 優先 | 作業 | かかる時間の目安 |
|---|---|---|
| 1最優先 | WPCS 3.4.0 を子テーマに1回走らせる | 検査は数秒。指摘を読むのに30分程度 |
| 2 | ベータ環境で子テーマを読み込み、表示崩れを確認 | 1〜2時間 |
| 3 | ブロックインスペクタまわりのカスタマイズを確認 | カスタマイズしていれば1時間 |
| 4 | メディア処理（画像アップロード・回転）の動作確認 | 30分 |
1番から始めるのは、機械的に終わるからだ。人の目で探す作業は時間が読めない。静的解析は走らせれば結果が出る。
優先順位をこう置いている理由は、残り3週間という期間にある。全部やる時間が取れる保証はないので、途中で止まっても意味のある順番に並べておく。1番だけ終わった状態でも、セキュリティ面の確認は済んだことになる。上から3つ終われば、表示崩れの主要な経路は押さえられる。
逆の順番にすると、時間切れになったときに何も終わっていない状態になりやすい。表示確認から始めると、細かい崩れを追ううちに数時間が過ぎる。追う価値のある崩れかどうかの判断も、静的解析の結果を見た後のほうがつけやすい。
# WPCS 3.4.0 を入れて子テーマに走らせる
composer global require --dev wp-coding-standards/wpcs:^3.4
phpcs --config-set installed_paths ~/.composer/vendor/wp-coding-standards/wpcs
# 子テーマだけを対象にする（親テーマの指摘まで拾うと量で埋もれる）
phpcs --standard=WordPress --extensions=php \
wp-content/themes/mytheme-child/
# 件数だけ先に見る（全部直す必要はない。傾向をつかむ）
phpcs --standard=WordPress --report=summary wp-content/themes/mytheme-child/いきなり全件を直そうとしないほうがいい。指摘の多くは書式の統一に関するもので、動作に影響しない。先に見るべきなのはエスケープ漏れとサニタイズ漏れで、これは表示の安全性に直結する。
# セキュリティ関連の指摘だけ抜き出す
phpcs --standard=WordPress --sniffs=WordPress.Security.EscapeOutput,WordPress.Security.ValidatedSanitizedInput \
wp-content/themes/mytheme-child/このサイトの子テーマに走らせた結果
ここまでの手順を、本サイトの子テーマ mag_tcd036_child にそのまま当てた。対象は PHP が3ファイル（functions.php 51KB、books-data.php 11KB、search.php 2.6KB）。
composer で ^3.4 を指定したところ、入ったのは 3.4.1 だった。Beta 3 が取り込んだのは 3.4.0 なので、リリースノートを読んでから手を動かすまでの間に patch が1つ進んでいたことになる。
走らせる前に環境で引っかかった。Windows に scoop で入れた PHP 8.5.8 は、拡張が php.ini で全部コメントアウトされたままになっている。composer を叩くと The openssl extension is required for SSL/TLS protection but is not available. で止まった。
共有の php.ini を書き換えると他の作業に影響が出るので、検証用の ini を別に作って -c で当てた。
; 検証用に作った php.ini（既存の設定は触らない）
extension_dir = "C:\Users\<user>\scoop\apps\php\current\ext"
extension=openssl
extension=curl
extension=mbstring
extension=zipphp -c ./php.ini composer.phar require --dev "wp-coding-standards/wpcs:^3.4"
php -c ./php.ini vendor/bin/phpcs --standard=WordPress --report=summary \
wp-theme/mag_tcd036_child/出た数字がこれになる。
| 測ったもの | 実測値 |
|---|---|
| 全体の指摘 | 519 errors / 54 warnings（3ファイル） |
| phpcbf が自動修正できる数 | 456件 |
| 検査にかかった時間 | 1.24秒 |
| セキュリティ3 sniff だけに絞った数読む対象 | 7件（全体の1.3%） |
指摘を多い順に並べると、1位が配列の空白 98件、2位がコメント前の空白 67件、3位が関数呼び出しの改行 61件。上位は書式で埋まった。519 という数字を最初に見たときは身構えたが、読む対象は7件しか残らなかった。
検査そのものは1.24秒で終わる。30分かかるのは、出た指摘を読んで直す側の作業だった。
7件のうち6件は、筆者が書いた行ではなかった
functions.php の1件は、親テーマが出した <title> と meta description を差し替えるために、出力バッファを取って書き戻している箇所だった。HTMLをそのまま通すことが目的の行なので、エスケープを足すとページが壊れる。phpcs:ignore に理由を書いて残す判断になる。静的解析が「エスケープしていない」と言う箇所の全部が直す対象ではない、という例がこれになる。
残りの6件は search.php に出た。このファイルは親テーマ MAG v4.1.2 の search.php を上書きしたもので、筆者が加えたのは検索結果0件のときに救済モジュールを呼ぶ1行だけだ。
それなら指摘は親テーマ側の問題ではないか。気になったので、サーバから親テーマの search.php を落として、同じ検査にかけた。
| 対象 | errors | warnings | セキュリティ3 sniff |
|---|---|---|---|
| 親テーマ search.php（オリジナル） | 136 | 39 | 6 |
| 子テーマ search.php（1行追加した版） | 137 | 41 | 6 |
セキュリティ関連は6件で一致した。筆者が足した行は指摘を1件も増やしていない。
この結果は、上に書いた「子テーマだけを対象にする」という絞り方が条件つきでしか効かないことを示している。親テーマのテンプレートをコピーして上書きしている子テーマでは、検査結果の大半が親テーマのコードから出る。今回は子テーマの errors 519件のうち137件、26%が search.php から出ていて、その中身はほぼ親テーマのものだった。
上書きしたファイルは、直す前に親テーマの同名ファイルと差分を取っておきたい。親から持ってきた行に手を入れると、親テーマが更新されたときに差分が広がって追えなくなる。
ベータ環境の作り方で手間が変わる
本番サイトでベータを試す選択肢は無い。かといって、環境を一から作ると準備だけで数時間かかる。筆者が取っている方法は、本番のテーマとプラグイン構成をローカルへ写して、そこへベータを入れる形だ。
子テーマだけを実物にして、それ以外は本番の写しで固定する。検証したいのは自分が書いたコードなので、他の要素は変えない。プラグインを減らした環境で確認すると、本番でだけ出る不具合を見逃す。
確認する画面は絞れる。記事の単一ページ、一覧ページ、カスタマイズした管理画面。この3つで崩れが出なければ、正式版当日に慌てる可能性は下がる。
表示崩れの見つけ方
目視だけで探すと見落とす。筆者は表示の確認を目で済ませて失敗した経験があるので、機械的に測る手順を挟むようにしている。図版の文字がはみ出していたことに、公開後まで気づかなかったことがあった。
今回のように CSS まわりの調整が入るリリースでは、要素の重なりと文字のはみ出しが出やすい。ブラウザの開発者ツールで算出スタイルを見るか、スクリーンショットを撮って前後で比較すると、目視より確実になる。
メディア処理の変更が効く場所
7.1 では GIF のアップロード、EXIF による回転、HEIC の扱いに手が入る。画像を扱う自作コードを持っているサイトは、ここで挙動が変わる可能性がある。
筆者のサイトは記事のアイキャッチを一括生成して投稿へ添付する仕組みを自作している。生成した画像をアップロードして、サムネイルのサイズが正しく作られるかを確認する流れだ。この工程は EXIF の回転処理と直接ぶつかる。
確認するなら、実際に画像を1枚上げてみるのが早い。縦横比が想定どおりか、生成されたサイズ違いの画像が揃っているか、回転が二重にかかっていないか。スマートフォンで撮った写真は EXIF に回転情報が入っているので、検証用の素材として向いている。
# アップロード後に、生成されたサイズ違いの画像を確認する
wp media list --format=table --fields=ID,post_title,post_mime_type
# 特定の画像で生成済みサイズを確認する
wp post meta get <attachment_id> _wp_attachment_metadata --format=json | jq '.sizes | keys'HEIC はスマートフォンからの投稿で入ってくる形式になる。自分では使っていなくても、投稿フォームを外部に開いている場合は通り道になりうる。
本番へ当てる前のチェックリスト
更新当日に慌てないよう、確認する項目を先に決めておきたい。筆者が用意しているのは4つだ。
バックアップが直近のものか。データベースとファイルの両方。戻せる状態を作ってから当てる。
子テーマの静的解析が通っているか。セキュリティ関連の指摘が残っていないこと。
記事の表示が崩れていないか。単一ページ・一覧ページ・カスタマイズした管理画面の3つ。
画像のアップロードが通るか。生成されるサイズ違いの画像まで確認する。
正式版の日程と、更新を当てるタイミング
正式版は8月19日予定で、WordCamp US 2026（8月16〜19日）と重なる。イベント期間中のリリースは、情報が出そろうのが遅れる場合がある。
筆者は本番サイトの更新を、リリース当日には当てない。数日から1週間ほど様子を見て、問題の報告が出そろってから上げる。運用ツールを自作した回でも書いたが、自動更新に任せる範囲と手で当てる範囲は分けておいたほうがいい。
そのうえで、ベータ期間中の確認は当日に上げるかどうかと関係なく必要になる。壊れる箇所を知っているかどうかで、更新後の対処時間が変わる。
よくある疑問
WPCS の指摘を全部直す必要があるか。無い。書式の統一は好みの範囲で、動作には影響しない。エスケープとサニタイズの指摘だけは、内容を読んで判断したい。
ベータを試す時間が取れない場合は。WPCS を1回走らせるだけでも意味がある。30分で終わって、セキュリティ面の穴が見つかる可能性がある。
Unicode メールアドレス対応はいつ入るのか。コミュニティプラグインでの作業継続が決まっているだけで、コアへの再投入時期は示されていない。当てにした実装は保留にしておきたい。
まとめ
正式版まで3週間の今やるべきことは、WPCS 3.4.0 を子テーマに1回走らせて、セキュリティ関連の指摘だけ読む。本サイトで実際に測ると、検査は1.24秒、読む対象は519件のうち7件だった。時間が取れるなら、ベータ環境に本番構成を写して表示を確認する。
上書きしたテンプレートを持っている子テーマなら、その7件を読む前に親テーマとの差分を取っておきたい。今回はセキュリティ関連の6件が全部そちら側だった。
Unicode 対応が直前で外れた件は、ベータ期間の情報を追う理由そのものになる。マージ済みの機能でも、正式版に載るまでは確定していない。
