タグ: Wordpress

プラグインやテーマは「使うもの」で、「作って配るもの」ではない。制作の現場ではそういう感覚が普通かもしれません。ただ、案件ごとに小さな自作プラグインを納品したり、テーマを配ったりしている会社は少なくないはずです。欧州連合で動き始めた新しい規則は、そうした立場の人にも関わってきます。

Cyber Resilience Act(サイバーレジリエンス法、CRA)という規則です。欧州委員会の説明によると、2024年12月10日に発効し、主な義務は2027年12月11日から適用されます。そして脆弱性などの報告義務については、それより早い2026年9月11日から適用が始まります。先に動き出すのは報告の部分だ、という順番になっています。

先に始まるのは報告のほう

CRAは、ネットワークにつながるハードウェアとソフトウェア全般を対象に、計画・設計・開発・保守の各段階で安全性を確保することを製造者に求める規則です。欧州委員会は、製品を出したら終わりではなく、製品の寿命が続くあいだ脆弱性を扱い続けることも要件に含まれると説明しています。要件を満たした製品にはCEマークが付き、各国の市場監視当局が運用を見ます。

先行して適用される報告義務は、悪用が確認されている脆弱性や重大なインシデントを、決められた期限内に当局へ知らせるというものです。欧州委員会は2026年7月27日に、規模を問わず事業者が義務を果たせるようにするための実務的な手引きを公開しています。読む側にとっては、9月の適用開始前に手順を確かめておくための材料ということになります。

WordPressの世界ではだれが対象になるのか

WordPressサイトの保守サービスを手がけるWP Umbrellaの解説によると、プラグイン作者はCRAの文脈では製造者にあたります。有料版がある、データを扱っている、会社として保守している。そうした商業的な意図があれば、無料で配っていても対象になり得るという整理です。オープンソースだから関係ない、とは言い切れないわけです。

同じ解説は、コードを書かない制作会社も無関係ではないとしています。第三者のプラグインを選んで納品する立場は流通側にあたり、使っている部品の一覧(SBOM、ソフトウェア部品表)がどこにあるか、セキュリティ更新がどう配られているかを把握しておくことが期待されます。EU向けの案件に自作モジュールを納めていれば、それは自社が作った製品という扱いです。

もっとも、WordPressの構造には難しさもあります。WordPress.orgから配布したプラグインの場合、作者は誰が使っているかを知りません。それでも利用者への通知が求められる、という食い違いが残っている。この点は個々の作者が解決できる話ではなく、配布側の仕組みが変わっていく必要がある、というのが同解説の見立てです。

技術的な中身はまだ標準づくりの途中

Help Net Securityが2026年8月14日に伝えたところでは、CRAの技術的な詳細を埋める17本の標準の草案が、いま意見募集にかけられています。法律は「何を達成すべきか」を定めるだけで「どうやるか」までは書かないため、標準化団体がその部分を担う。CRAを担当する部会の議長は、そうした役割分担だと述べています。

示された草案に沿って作れば適合しているとみなされる仕組みで、今回の対象はパスワード管理ソフトやウイルス対策ソフト、スマートホーム機器、つながる玩具など、リスクが高いとされる区分です。意見を出せるのは欧州経済領域の標準化機関を含む41の加盟組織と、消費者や中小企業の立場を代表する四つの団体で、締め切りは分野ごとに9月半ばから11月半ばの間に置かれています。文言がまだ動くうちに意見が入る、という段取りです。

制作の現場で先にできること

日本の制作会社が明日から欧州の当局に何かを届け出る、という話ではありません。ただ、CRAが求めている作業の中身は、EU向けかどうかに関係なく手元の運用を整えるものでもあります。変更履歴を残す。更新にセキュリティ修正が含まれるときはそれとわかるように書く。脆弱性の連絡先をひとつ決めて公開しておく。可能なら機能追加とセキュリティ修正を分けて出す。WP Umbrellaの解説が挙げているのは、そうした地味な項目です。

保守を請け負っている場合は、どのサイトにどのプラグインが入っていて、いつ更新したかを追える状態にしておくことが効いてきます。何年も更新の止まったプラグインを使い続けている案件があれば、そこは規則以前の問題として見直しどころです。欧州の規則という遠い話に見えて、点検の項目自体は、いま抱えている保守案件にそのまま当てはまります。

WordPressの新しいバージョンが8月19日に公開された。コードネームは「Mary Lou」で、ジャズピアニストのメアリー・ルー・ウィリアムスにちなんでいる。公式の発表によると、800人を超える貢献者が関わり、1500以上の改善と修正が入ったという。ここでは制作の現場で実際に触ることになりそうな変更を、いくつか並べて見ていく。

画面幅ごとのスタイルが標準の操作に

サイトエディターから、タブレットとモバイルの画面幅に対してブロックの見た目を指定できるようになった。グローバルスタイルでブロック種別ごとに設定することも、個々のブロックに設定することもできる。編集しながら表示幅を切り替えて確認する仕組みも付いている。

theme.json では @mobile と @tablet というキーの下に入れ子で書く。@desktop にあたるキーは意図的に用意されていない。ブロックの既定のスタイルがそのままデスクトップのスタイルであり、上書きしなかった項目はどの画面幅でも効き続ける、という考え方になっている。

区切りの位置も theme.json の settings.viewport で変えられる。既定はモバイルが480px、タブレットが782pxで、px、em、rem の非負の長さだけが有効になる。CSSの関数や割合、単位なしの値は無視される。標準のブロックサポート(タイポグラフィ、色、背景、境界線、寸法、余白、レイアウト)を使っているブロックは自動で対応し、独自のスタイル操作を持つブロックは対象外になる。自作ブロックを確認するときの境界線はここになる。

ホバーや押した状態も扱えるようになった

あわせて、擬似的な状態のスタイル指定が入った。theme.json とエディターの両方から :hover、:focus、:focus-visible、:active を指定できる。ただし今のところ対象は Button ブロックと Navigation Link ブロックに限られている。

メニューの現在地を表すための独自状態の仕組みも入っているが、こちらは theme.json のみで画面上の操作はまだ用意されていない。今は存在を知っておく程度でよさそうだ。

背景まわりで長年の回避策が不要に

ブロックサポートに background.gradient が加わった。従来の color.gradient は background の一括指定として出力されるため background-image まで打ち消してしまい、ひとつのブロックで背景画像とグラデーションを同時に使えなかった。新しい方は background-image の個別指定として出力され、画像とグラデーションをカンマ区切りでまとめて書き出せる。Group、Accordion、Pullquote、Post Content、Quote が最初の対応組になっている。

ほかに dimensions.minWidth が min-height と同じ流儀で追加され、グローバルスタイルでは text-shadow も扱えるようになった。

新しいブロックと編集画面の土台

Playlist と Tabs が試験的な扱いから正式なブロックになった。Playlist は複数の音声をひとまとめに並べ、再生中の様子を波形で添えることもできる。Tabs はタブで内容を切り替える表示で、これまでプラグインに頼っていた場面をいくらか置き換えられそうだ。

編集画面側では、管理バーがすべてのエディターで表示され続けるようになった。投稿エディターは、テーマの種類や登録済みブロックのバージョンにかかわらず常に iframe の中で動く。内容によって切り替わっていた従来の挙動はなくなる。エディター用のスクリプトが動く文書とキャンバスの文書は別物なので、素の document や window を見に行っているコードは対象を取り違える。要素から ownerDocument や defaultView をたどる書き方への置き換えが要る。

管理画面まわりの細かい追加

wp_get_tooltip() と wp_get_toggletip() が追加され、これまでエディターの中にしかなかった説明の吹き出しを管理画面全体で使えるようになった。前者はアイコンだけの操作に読み上げ可能な名前を与えるもの、後者は補足説明を開くボタンを添えるもので、コア自身も投稿画面のメタボックスやログイン画面のチェックボックスで使っている。

Navigation ブロックが子のリンクにフォントサイズを渡さなくなった点も、テーマを作っている人には効いてくる。相対単位が入れ子で掛け算になり、編集画面と表示側で文字の大きさが食い違う原因になっていた。has-{slug}-font-size を直接狙っているテーマは、開発者向けノートにある従来の挙動を戻すフィルターを見ておくとよい。

更新の前に、独自ブロックや管理画面を拡張しているプラグインを一度試しておきたいところだ。画面幅ごとの指定がコアに入ったことで、追加CSSで抱え込んでいた部分をテーマ側に戻せる場面は増えそうに思う。

ウェブショップを動かすWooCommerceの新しい版、11.0が公開されました。八月四日付の公開で、551件の変更が取り込まれ、89人が関わった大きめの更新です。中身は目新しい機能を足すより、土台の整理と積み残しの解消に寄っています。その中で買い物客の側から見て分かりやすいのが、ゲスト購入まわりの扱いの変化です。

WooCommerceには以前から、購入手続きを終えたあとにアカウントを作れる仕組みが用意されていました。11.0ではそこから一歩進んで、購入者が過去のゲスト注文を自分で探し出し、メールアドレスの確認を経てアカウントに結び付けられるようになっています。会員登録を後回しにしたまま何度か買い物をした人でも、あとから注文履歴を一つにまとめられる、という流れです。店舗側で名寄せの問い合わせに対応していた手間が、そのぶん減る可能性があります。

規模の大きい店舗向けの速度改善も入りました。内部の問い合わせの最適化、Store APIの改善、注文処理を通した在庫状態の扱いの見直しが挙げられており、商品数や注文数が増えるほど効いてくる部分です。ほかに、計測の取りこぼしを減らす調整、返金を売上の集計に反映する変更、取り込みに失敗した過去データをやり直せる仕組みも含まれています。

直後に出た修正版もあわせて

その六日後には11.0.1が出ています。こちらはセキュリティ更新の扱いで、ゲストのセッションcookieがソルト付きのより強いハッシュに変わりました。古いcookieは期限が切れるまで有効なままなので、更新をまたいでもゲストのカートは残ります。ほかにも、商品の短い説明にもパスワード保護が及ぶようになった点、Store APIでクーポンの利用回数の上限が正しく適用されるようになった点、カートや購入手続きのブロックに表示される通知の中身が安全に処理されるようになった点が並びます。ログの書き込みのたびにフォルダ全体を走査しなくなり、記録がたまった店舗で購入手続きが重くなりにくくなった改善も入りました。あわせて、次のWordPress 7.1に向けた互換性の調整も進んでいます。注文一覧が新しい一覧表の記述に合わせられた、といった地味な内容ですが、本体の更新を控えている店舗にとっては先に当てておきたい版といえます。

会員登録を必須にすると買い物の途中で離れられやすい、という悩みは店舗の規模を問わず共通です。ゲストのまま買えるようにしておき、必要になったときに履歴をアカウントへ寄せられる作りは、無理のない落としどころだと感じます。会員向けの案内やクーポンを届けたい店舗にとっても、購入のハードルを上げずに接点を作れる余地が広がります。一方で、注文とアカウントを結び付ける処理はメールアドレスの確認を挟むとはいえ個人情報に触れる部分なので、公開前に自分の店舗の設定で挙動を一度確かめておきたいところです。11.0はデータベースの更新を伴うため、控えを取ったうえで検証環境から順に試すのが安全です。

WordPressの次の版が8月19日に公開される予定で、いまは公開直前の候補版が配布され、検証が進んでいる段階です。新機能の紹介はあちこちで出そろってきましたが、制作の現場で先に気になるのは、いま動いているサイトのどこが変わるかのほうではないでしょうか。

公式の開発者向けまとめを読むと、機能追加とは別に、既存のテーマやプラグインが前提にしていた作りが静かに変わる箇所がいくつかあります。派手な話ではありませんが、当たっていると管理画面の見た目や動きに出ます。更新前に目を通しておきたいものを並べてみます。

投稿の編集画面が常に枠の中で動く

これまでは、テーマの種類やブロックの版によって、投稿編集画面がiframeの中に入るかどうかが切り替わっていました。次の版では条件によらず常に枠の中で動きます。どちらになるか読めない状態が解消されるのは扱いやすくなる方向の変更です。

ただし、編集画面に独自の見た目を足している場合は挙動が変わる可能性があります。enqueue_block_editor_assetsのような正規の入口から読み込んでいれば影響は小さいはずですが、管理画面全体のCSSに紛れ込ませていたり、親の画面を直接触るスクリプトを書いている場合は、実際に開いて確かめておくのが早いです。

一覧画面の表の作りが変わる

投稿一覧などの表で、行の見出しとして扱われるセルが、チェックボックスの列からタイトルの列へ移ります。読み上げたときの筋道としては素直になる変更ですが、列の位置を決め打ちしたセレクタに頼っている拡張は影響を受けることがあります。

一覧に独自の列を足すプラグインは、中小企業のサイトでもよく入っています。受注状況や公開予定日を一覧に出すような作り込みをしている場合は、更新前に検証用の環境で開いてみる価値があります。

管理画面の入力部品の大きさがそろう

管理画面の部品群では、大きさを指定していたプロパティが役目を終え、フォーム部品は一律で40ピクセルの高さで描かれるようになります。小さめの指定は渡しても効かなくなり、非推奨の扱いになります。

独自の設定画面を持つプラグインを作っている場合、詰めて並べていた入力欄の高さが変わり、レイアウトが縦に少し伸びることがあります。壊れる類の変更ではありませんが、二列に並べていた部分の折り返しなど、見た目の調整が必要になるかもしれません。

ナビゲーションの文字サイズの効き方が変わる

ナビゲーションのブロックが、子の項目に自分の文字サイズを押し付けなくなります。入れ子のドロップダウンで文字サイズが掛け算のように効いてしまい、階層が深いほど不自然に大きくなる、あるいは小さくなるという問題への対処です。

回り道の指定でごまかしていた部分が本体側で正されるのはありがたい変更ですが、裏を返せば、更新後にメニューまわりの見た目が変わるサイトはあるということです。納品済みのサイトが複数ある制作者は、階層メニューを持つものだけでも一度目視しておきたいところです。

実験段階だった機能が正式に使えるようになる

タブとプレイリストのブロックが実験扱いから外れ、標準の部品として使えるようになります。加えて、背景にグラデーションと画像を重ねられる指定や、ブロックの最小幅を指定できる仕組みも増えました。管理画面に説明の吹き出しを出すための関数も用意され、読み上げに配慮した形で組み込めるようになっています。

これまで小さなプラグインや自作のブロックで賄っていた部分が、本体側だけで足りるようになるかもしれません。プラグインの数を減らせれば更新の手間も脆弱性の窓口も減るので、棚卸しのきっかけにはなりそうです。

公開までは一週間ほどです。候補版は検証用に配布されているので、複雑なテーマや作り込んだ管理画面を抱えているサイトは、本番の更新を待つ前に複製した環境で一度開いておくと、当日は落ち着いて臨めます。

サイトにアイコンを一つ足すだけの作業が、案外ややこしい。テーマのフォルダにSVGを直接置く方法、プラグインが独自に読み込む方法、外部のアイコンフォントを呼ぶ方法が、同じサイトの中に混在していることは珍しくない。担当者が代わったあとで「この矢印はどこから来ているのか」を追いかけた経験のある人は多いはずだ。

8月19日に公開が予定されている次期WordPressで、この部分に手が入る。アイコンを本体側に登録しておき、編集画面からもテンプレートのPHPからも、さらにREST API経由でも同じ名前で取り出せる仕組みが、正式な関数として公開される。

これまでは各自で抱え込むしかなかった

アイコンを置くためのブロックは、ひとつ前のバージョンで本体に入っている。ただし、そこへ自社のロゴマークや業種特有の記号を足したい場合に、公開された入り口が用意されていなかった。開発者向けの告知によると、内部向けのクラスを無理に呼び出すか、プラグイン側で独自の一覧を持ち回るか、どちらかを選ぶしかない状態だったとされている。

結果として、ひとつのサイトの中に似たような管理方法がいくつも並ぶ。テーマの中にはあるのに編集画面の一覧には出てこない、といったずれも起きる。小さな話に見えて、更新や引き継ぎのたびに時間を取られるのはこういうところだ。

アイコンを足したい場面自体は、規模の小さいサイトほどよくある。問い合わせ先に添える電話やメールの記号、事業内容を並べたときの業種ごとのピクトグラム、外部の会員サイトへ誘導するボタンの矢印。どれも凝ったものではないが、既定の一覧に入っていなければ自前で持ち込むしかなかった。

登録は一か所、呼び出しは三通り

新しく加わるのは、アイコンのまとまりを作る関数と、そこへ個々のアイコンを加える関数だ。wp_register_icon_collection() でグループを作り、wp_register_icon() でSVGの中身かファイルの場所を渡す。名前は「グループ名/アイコン名」の形で付ける決まりで、使えるのは小文字と数字、ハイフン、アンダースコアに限られる。不要になったものを外す関数も対で用意されている。

登録したアイコンは三つの場所から使える。編集画面のアイコン選択欄ではグループごとのタブに分かれて並び、名前やラベルでの絞り込みも効く。テンプレート側では wp_get_icon() で書き出せて、大きさやクラス名、読み上げ用のラベルを添えられる。加えて /wp/v2/icon-collections や /wp/v2/icons といった読み取り専用のエンドポイントが用意され、記事を編集できる権限を持つユーザーであれば一覧を取得できる。

地味だが大きいのは、登録する場所がひとつに決まったことだと思う。テーマが持っていてもプラグインが持っていても、同じ棚に並ぶ。そのサイトで今どのアイコンが使えるのかを一覧で確認できる状態は、これまで意外と手に入らなかった。

読み込めるSVGはかなり絞られている

登録したSVGはそのまま出力されるわけではなく、本体のタグ整形処理を通る。許されるのは svg、path、polygon の三種類の要素と限られた属性だけで、それ以外の要素やインラインの装飾指定、スクリプト、イベント属性は落とされる。現時点では線の太さを指定する属性や、外側の要素に付けた塗りの指定も対象外とされている。

SVGは以前から、アップロードを許すと侵入の入り口になりやすい形式として扱われてきた。管理画面から自由に置けるようにしないほうがよい、という判断はここでも変わっていない。線で描いたアイコンを使いたい場合は、あらかじめ塗りの形に変換してから登録するといった準備が必要になる。窮屈ではあるが、安全側に倒した設計だと考えるとつじつまは合う。

効いてくるのは引き継ぎの場面

この変更は派手ではない。既存のサイトが速くなるわけでも、見た目が変わるわけでもない。効いてくるのは、作った人と日々更新する人が違うときだ。アイコンの出どころが一か所にまとまっていれば、あとから触る人はまずそこを見ればよい。制作会社が納品したあと社内で運用していく中小企業のサイトほど、この差は効いてくる。

もっとも、現時点での使いどころはアイコンを置くブロックとナビゲーション周りが中心で、既存のサイトを慌てて作り替えるような話ではない。新しくテーマやプラグインを組む段になって、アイコンをどこに持たせるか決めるときに、この方法があることを思い出せれば十分だろう。仕様の詳細は開発チームの告知にまとまっている。

WordPress本体のセキュリティ更新が公開されました。8月6日に出た臨時リリースで、修正された不具合は12件です。機能追加を伴わない、修正だけを目的とした更新になります。

この種の更新は定期的に出てきますが、今回は未ログインの状態から届く経路が含まれていた点で、優先度が一段高いものになっています。管理画面に入れる人だけが対象、という前提が成り立たない種類の不具合だからです。

ログイン画面から届く経路がふさがれた

今回いちばん重く扱われているのは、ログイン画面で見つかった反射型のクロスサイトスクリプティングです。CVE-2026-64638として登録され、深刻度は9に近い数値がつきました。公式のリリース情報によると、条件がそろうとPHPのコード実行につながる可能性があるとされています。

反射型というのは、送り込まれた内容がそのまま画面に跳ね返って動いてしまう型のことです。データベースに残らないぶん痕跡が追いにくく、あとから気づきにくい種類でもあります。今回変更されたファイルにはログイン画面の本体や出力の無害化を担う処理が含まれており、画面に出す直前のエスケープを補う形の修正が中心になっています。特殊な仕組みを足したわけではなく、基本の処理の抜けを埋めた、という内容です。

ただし、放っておけば勝手に乗っ取られるという話ではありません。攻撃者が用意したリンクを管理者が踏む、といった手順が要ります。とはいえ、細工したURLを開かせるだけで足がかりができるのは、アカウントを持たない相手にも入口があるということです。問い合わせフォーム経由で管理者宛にURLが送られてくる現場を思うと、まったくの他人事にはしにくいところです。

権限の低いユーザーがいるサイトほど確認したい

残りの修正も、後回しにしてよいものではありません。投稿者や寄稿者の権限で保存できてしまうスクリプトの混入、パスワード保護した記事のコメントが一覧に漏れる問題、マルチサイトで登録を開放している場合の権限昇格、URLの検証をすり抜けて内部向けのアドレスへ通信させられる不具合などが並びます。

WordPressの権限は、寄稿者は記事を書けても公開はできない、といった段階で線が引かれています。その前提のもとで運用を組んでいる現場からすると、寄稿者の権限でスクリプトを保存できてしまう状態は、引いていたはずの線が一段ゆるむことを意味します。外部に原稿を頼んでいる場合、相手を疑うかどうかという話ではなく、そのアカウントが乗っ取られたときの被害範囲が変わってくる、と考えたほうが実態に近いはずです。

共通しているのは、外部のライターや複数の担当者が出入りするサイトほど影響を受けやすい、という点です。編集部制で運用しているメディアや、支店ごとに更新担当を置いているサイトは、この機会に権限の割り当てもあわせて見直しておくと落ち着きます。使っていない寄稿者アカウントが残っているケースは、実際にかなり多いはずです。

古い版にもさかのぼって修正が配られた

今回目を引くのは、修正が現行版だけでなく、4.7系まで戻ってそれぞれの系統に配られたことです。7.0系は12件すべて、6系はおおむね8件から11件、5系や4系は7件から8件が該当し、系統ごとに対応版が出ています。4.6以前はすでに対象外です。

本体を大きく上げるのが難しい案件でも、同じ系統の中で当てられる修正が用意されている、という意味になります。古いから手の打ちようがない、ということはありません。ただし、正式にサポートされているのは最新版だけ、という原則自体は変わっていません。古い系統への配布はあくまで好意によるものだと明記されています。制作を引き継いだまま長く動いているサイトを抱えているなら、いまどの系統で止まっているのかを一度洗い出しておく価値があります。

自動更新が生きているかを見ておく

マイナー更新の自動適用が有効なら、公開から数時間のうちに当たっているはずです。問題になりやすいのは、過去の検証や不具合の切り分けで自動更新を止めたまま元に戻していない環境で、こうしたサイトは静かに取り残されます。契約しているサーバー会社の管理画面側で更新をまとめて制御している場合もあるので、どこで止まっているのかを切り分けておくと話が早くなります。

管理画面の更新ページでバージョンを確かめ、必要なら手動で当てる。あわせて、wp-config.phpやサーバー側の設定で自動更新を無効にしていないかも見ておくと、次の臨時リリースのときに慌てずに済みます。更新後にログイン画面と投稿の編集画面がふだんどおり開くかを確認しておけば、ひとまず十分でしょう。

修正が公開されてから実際に狙われはじめるまでの間隔は、年々短くなっているという報告が続いています。次の定例作業のときにまとめて、という進め方は、少なくとも本体のセキュリティリリースに関しては取りにくくなってきました。

WordPressの管理画面、とくにブロックエディタの中身は、Reactというメニューや画面部品を組み立てるためのJavaScriptライブラリで動いています。そのReactを新しい世代に入れ替える作業がしばらく進められていたのですが、8月に予定されている次のWordPressには入らないことになりました。開発チームが7月下旬にMake WordPress Coreで経緯を公開しています。

いったんはGutenbergプラグインの側で新しい世代に切り替えてみたものの、想定していなかった不具合が続けて報告され、数日で元に戻されたとのことです。原因として挙げられているのは大きく二つ。ひとつは、プラグインがReactの部品をWordPress本体から借りずに自前で同梱していたケースで、この場合は古い世代と新しい世代が同じ画面の中で同時に動いてしまい、内部のデータの持ち方が食い違って壊れます。もうひとつは、新しい世代で廃止された古い書き方が、プラグイン側にそのまま残っていたケースです。文字列で書くref、関数コンポーネントへのdefaultProps、旧来のcontextの定義などが具体例として挙がっています。

本体は当面そのまま、試したい人には実験用のスイッチ

そのため、次のWordPressは従来どおりのReactを載せたまま出ます。切り替えを先に試しておきたい開発者向けには、Gutenbergプラグインの23.4以降に実験用のスイッチが用意されました。設定画面から有効にすると、本体が配っている部品だけが新しい世代に差し替わり、公開済みのプラグインが将来直面する状況をそのまま再現して確かめられます。あわせて、公式のPlugin Checkプラグインには、問題になりやすい書き方を自動で見つける検査を追加する作業が進められています。手作業で全部を洗い出さなくてよくなったのは、地味ですが助かる変更です。

サイトを運用している立場からすると、今回のニュースは特に何かをする話ではありません。ただ、独自のブロックや管理画面の拡張を自作している、あるいは制作会社に作ってもらっている場合は、事情が少し変わります。いずれ切り替えは来るので、その前に一度実験用のスイッチで動作を確かめ、ブラウザのコンソールにエラーが出ていないかを見ておくと、あとで慌てずに済みます。ブロックエディタまわりのカスタマイズは、こうした土台の入れ替えの影響をまっすぐ受ける場所です。

互換性の問題が見つかった時点で無理に押し通さず、二日で元に戻して検証期間を取り直したという判断は、更新のたびに現場が振り回されないという意味ではありがたい話でもあります。管理画面が急に開かなくなったときに困る度合いは、社内に専任の担当を置きにくい中小企業のサイトほど大きくなります。派手さのない先送りですが、その裏側を眺めておくと、次に来る更新への構え方も少し変わってきます。

WordPressで写真をアップロードしたとき、裏側では何が起きているか。サーバー上のPHPが元画像を読み込み、縮小版を何種類か書き出し、必要なら形式を変換している。撮ったままの大きな写真を何十枚もまとめて投げ込むと、この処理が重くて途中で止まる。更新担当が自分で写真を載せている中小企業のサイトでは、よくある詰まりどころだ。

今月中旬に公開が予定されているWordPressの次の版では、この画像処理の担当がサーバーからブラウザに移る。開発チームの解説によると、圧縮、リサイズ、形式変換、回転、サムネイル生成までを、操作している人の手元のブラウザで済ませる仕組みだという。

画像処理のエンジンがブラウザの中で動く

使われているのはwasm-vipsと呼ばれるもので、画像処理ライブラリのlibvipsをWebAssemblyに変換し、ブラウザ上で動かせるようにしたものだ。処理はWeb Workerに逃がしてあるため、変換の最中でも編集画面の操作が固まりにくい。

副次的な効果として、書き出される画像そのものも変わる。libvipsが生成するJPEGは、これまで使われてきたGDやImagickによるものよりおよそ15パーセント小さくなるとされている。サーバーに入っている画像ライブラリの違いで書き出し結果が微妙に変わっていたのが、どの環境でも同じ出力に揃う点も見逃せない。共用サーバーを使う案件が多いほど、この均一さはありがたい。サーバーごとの環境差を吸収するために、書き出し品質の設定を案件別に調整していた人には、手間が一つ減る話でもある。

iPhoneの写真やアニメーションGIFの扱いも変わる

分かりやすいのはHEICへの対応だろう。iPhoneの標準的な写真形式だが、これまではサーバー側の対応状況次第でアップロードできないことがあった。新しい仕組みではブラウザ内でデコードしてJPEGに変換し、元のファイルは別途保持される。

AVIFは10ビットや12ビットといった高階調の元データまで通り、UltraHDRのJPEGはゲインマップを保ったまま各サイズが書き出される。透過のないアニメーションGIFはMP4やWebMの動画に変換され、エディタ側では自動再生とループが効く動画ブロックの派生として挿入される。見た目は元のGIFのままで、ファイルだけが軽くなる形だ。

条件を満たさない環境では今までどおりになる

気になるのは、対応していない環境で何が起きるかという点だが、ここは素直な作りになっている。条件を満たさない場合は従来どおりサーバー側で処理され、切り替えは自動で、画面上の見え方も変わらず、エラーも出ない。判定には端末のメモリ量やCPUのコア数、通信速度、CSPでblobが許可されているかどうかが使われる。

ブラウザ側の条件はやや厳しめだ。SharedArrayBufferを使う都合でDocument-Isolation-Policyに対応したChromium系のブラウザが必要で、FirefoxとSafariは当面サーバー側処理に回る。ただしHEICのデコードだけはSafariでも動く。サイト側で機能ごと止めたい場合はwp_client_side_media_processing_enabledフィルターをfalseにすればよく、big_image_size_thresholdやjpeg_qualityといった既存のフィルターもそのまま効くとされている。

制作の現場から見て効いてくるところ

実務でありがたいのは、PHPのメモリ上限に起因するアップロード失敗が減ることだ。画像処理はメモリを食う工程で、共用サーバーの上限に当たって管理画面が真っ白になる相談は今でも珍しくない。その負荷がブラウザ側に移るなら、サーバーの構成を触らずに回避できる場面が増える。手元のパソコンは近年それなりに性能が上がっているので、重い工程を任せる先としては悪くない。

アップロードの粘り強さも上がっている。サイズ違いの書き出しごとにリクエストが分かれ、失敗すれば間隔を空けて自動で再試行する。回線が切れれば一時停止し、つながれば再開する。進捗も画面に出て、読み上げソフトにも伝わる作りだ。出先からスマートフォンで写真を上げる担当者がいるサイトほど、この差は体感しやすいだろう。

正式な公開は今月中旬の予定になっている。普段どおりの写真の投げ方を検証環境でひととおり試し、いつも使っている画像形式が想定どおりに変換されるかを見ておくと、切り替わったあとに慌てずに済む。

WordPressの次のバージョンにあたる7.1のベータ3が7月22日に公開された。71件を超える修正が入った通常のベータ更新だが、告知の中に少し珍しい一文が混ざっていた。いったんコアに取り込まれていた、アルファベット以外の文字を含むメールアドレスへの対応が、7.1には入らないことになったという内容だ。

対象になっていたのは、@より前のローカル部分に日本語や各国の文字が入ったアドレスである。ドメイン側はPunycodeという変換の仕組みで以前から扱えていたが、ローカル部分は長く対象外で、WordPressの検証関数が不正なアドレスとして弾いていた。今回の変更では、データベースの文字コードがutf8mb4であればis_email()やsanitize_email()が非ASCIIのアドレスを受け付けるようになり、アドレスをローカル部とドメイン部に分けて扱えるWP_Email_Addressというクラスも加わっていた。元になったチケットが立てられたのは2015年で、11年越しで前に進んだ案件でもある。

取り込んだあとで外すという判断

その機能が、コアにマージされてから6週間ほどで外された。挙げられている理由は、Unicodeを受け入れることで確認しなければならない範囲が一気に広がることと、それに伴うセキュリティ面の影響だ。Unicodeには見た目がほとんど区別できない別の文字が数多くあり、ログイン用のアカウントや通知メールの宛先が絡む場所では、取り違えやなりすましの入口になりうる。公式の告知では、開発はコミュニティプラグインとして続け、互換性やセキュリティ、データの扱いをより広くテストしていくとされている。

日本の制作現場への直接の影響は、いまのところ小さい。国内で非ASCIIのメールアドレスを実際に運用している取引先はほとんど見かけないし、7.1に入らないのであれば当面の挙動も変わらない。気に留めておきたいのは、問い合わせフォームや会員登録の入力チェックを自前の正規表現で書いているサイトのほうだ。将来コア側が受け入れる文字の範囲が広がったとき、フォーム側だけが古い基準で弾き続ける、という食い違いが起きうる。プラグインとして先に試せる形になるのであれば、その前に手元で挙動を確かめておける。

もうひとつ、この話が示しているのは、メールアドレスの扱いがWordPress単体で完結しないことだ。仮にコア側が受け付けても、その先の送信サーバーやメール配信サービス、受け取る側のメールソフトがそろって対応していなければ、通知が届かないという形で問題が出る。ウェブ側だけを新しい仕様に合わせても意味がない領域で、慎重に進める判断そのものは理解しやすい。

11年動かなかった機能が入り、6週間で外れる。読んでいて印象に残るのはむしろ判断の速さのほうで、世界中のサイトが乗っている土台に何を入れるかという線引きが、機能の完成度とは別の基準で引かれていることがよく分かる。7.1そのものは8月19日の公開予定で、こちらは通常どおりの日程で進んでいる。

ボタンにマウスを載せたら色が変わる、リンクにキーボードのフォーカスが当たったら枠線が出る。ウェブサイトではごく当たり前の動きですが、WordPressのブロックエディタでこれを整えようとすると、これまでは追加CSSの欄にセレクタを書き足すか、テーマのスタイルシートを直接触るしかありませんでした。次のバージョンで、ここに標準の指定方法が入ります。

7月15日に公開された7.1のベータ1の告知では、ブロックが操作にどう反応するかを、サイト全体の設定と個々のブロックの両方で共通のコントロールから指定できるようになる、と説明されています。派手さはありませんが、制作側と運用側の分担にじわじわ効いてくる種類の変更です。正式リリースは8月19日、WordCamp USに合わせた日程が示されています。

これまでは追加CSS頼みだった領域

ホバーやフォーカスといった状態ごとの見た目は、CSSでは擬似クラス(:hover、:focus、:active)で書く領域です。ブロックエディタのサイドバーには色やタイポグラフィの入り口はあっても、状態別の入り口はありませんでした。結果として、テーマが用意した見た目をそのまま受け入れるか、追加CSSで上書きするかの二択になります。

後者はセレクタの書き分けが面倒でした。サイト全体のボタンをまとめて変えるのは比較的簡単でも、あるページの一つのボタンだけ挙動を変えたいとなると、そのブロックに固有のクラスを振り、そのクラス向けの記述を足すことになります。運用担当の方が触れる範囲ではなく、結局は制作会社への小さな依頼として積み上がっていく部分でした。

この標準化はGutenbergのリポジトリで数年前から要望が出ていたもので、ようやく本体に入る形になります。

全体にも一つのブロックにも当てられる

今回の仕組みで押さえておきたいのは、適用範囲が二段構えになっている点です。グローバルスタイル側で指定すればサイト全体のボタンの反応が揃い、個別のブロック側で指定すればその一つだけが別の反応になります。テーマの土台は崩さないまま、例外だけを局所的に作れるということです。

もう一つ、フォーカス時の見た目を編集画面から扱えるようになる意味は小さくありません。キーボードだけでサイトを操作する人にとって、今どこにいるかを示す枠線は迷子にならないための唯一の手がかりです。装飾を優先してこの表示を消してしまう実装は今も見かけますが、逆に言えば、消すのではなく背景色に対して見やすい色に調整するという判断を、コードを触らない担当者でもできるようになります。

対応するブロックはまず限られる

期待しすぎないほうがよい部分もあります。ベータの段階で状態指定に対応しているのはボタンとナビゲーションリンクなど、対象はまだ絞られています。すべてのブロックに広がるのはこの先の版で、本体側でも段階的に範囲を広げていく方針が示されています。

また、テーマ開発の側ではtheme.jsonから擬似要素を扱えるようにする整備も並行して進んでいます。編集画面のコントロールとテーマの定義ファイル、両方から状態のスタイルを扱えるようにしていく流れの一部と見ておくと、位置づけを取り違えずに済みます。開発者向けの月次まとめでも、この周辺は7.1の柱の一つとして扱われています。

更新前に確認しておきたいところ

実務で気をつけたいのは、既存サイトで追加CSSを使ってホバーの見た目を上書きしている場合です。新しいコントロールから指定した内容と、これまで書いてきた記述が重なると、どちらが勝つかは書き方次第になります。更新のタイミングで、追加CSSにどんな状態指定が残っているかを一度洗い出しておくと、後から原因を探す手間が減ります。

本番にいきなり当てるのではなく、複製した検証環境で主要なページを一通り見てから、というのはこの種の更新では毎回変わらない手順です。ボタンとナビゲーションが対象である以上、影響が出るとしたら問い合わせ導線やグローバルメニューという、サイトの中でも動いてほしくない場所になります。

小さな見た目の調整を運用側で完結できる範囲が広がるのは、更新を続けていくサイトにとっては地味に効きます。制作時に決めた見た目を固定するのではなく、運用しながら少しずつ手を入れられる状態にしておく。ブロックエディタが年々進んでいる方向は、おおむねそこに向いているように見えます。