タグ: Wordpress

WordPress 7.1 が8月19日に公開され、投稿の編集画面まわりに地味ながら影響範囲の広い変更が入った。投稿エディタが、条件にかかわらず常に iframe の中で動くようになったことだ。画面の見た目はほとんど変わらないので気づきにくいが、ブロックを拡張するプラグインや自作ブロックを抱えているサイトでは挙動が変わる可能性がある。

これまでは記事の中身しだいで切り替わっていた

WordPress はここ数年、編集画面を少しずつ iframe の中へ移してきた。最初に移ったのはテンプレートエディタで、5.8 のときだった。その後サイトエディタや端末別のプレビューも常時 iframe 化され、最後まで残っていたのが投稿の編集画面だった。

7.0 の時点では、投稿に挿入されているブロックのブロック API のバージョンを見て判断していた。挿入済みのブロックがすべて API バージョン3以上なら iframe 化し、それより古いブロックがひとつでも混ざっていれば互換性を優先して iframe をやめる、という仕組みだ。つまり同じサイトの中でも、記事の中身によって編集画面の作りが変わっていたことになる。

7.1 からはこの条件分岐がなくなった。テーマの種類にも、登録されているブロックの API バージョンにも、本文に入っているブロックにも関係なく、投稿の編集画面は常に iframe になる。従来ながらのメタボックスを登録しているサイトも対象に含まれる。

切り離すことで何が変わるのか

iframe は別の HTML 文書を画面の中に読み込む仕組みで、中と外でスタイルの適用範囲が分かれる。編集画面を iframe に入れると、管理画面側の CSS が本文の表示に混ざり込まなくなる。ビューポート単位やメディアクエリも、ブラウザのウィンドウ幅ではなく編集領域そのものの幅を基準に効くようになる。

編集画面の見た目と公開後の見た目をそろえるという点では、筋のいい方向だと思う。7.1 ではタブレットとモバイルの表示を theme.json 側から指定できる仕組みも入っており、幅の判定基準をはっきりさせる必要はもともと高まっていた。条件によって iframe になったりならなかったりする状態のままでは、同じテーマでも記事ごとに確認結果が変わりかねない。

つまずくとしたら document と window のあたり

公式の開発者向け案内によると、ほとんどのブロックは手を入れなくても iframe 化された編集画面で動くとされている。問題が出る場合も、原因はだいたい同じところに行き着くという。iframe は自前の document と window を持っており、編集画面のスクリプトが動いている管理画面側とは別物だ、という点だ。

グローバルな document や window をそのまま参照して編集領域の要素を触っているコードは、意図しない側の文書を見に行ってしまう。対処としては、編集領域の中にある要素から ownerDocument とその defaultView をたどって正しい文書を取得する方法と、イベントリスナーの登録と解除を useRefEffect で行う方法が案内されている。自作ブロックやエディタ拡張を納品している制作者なら、更新前に手元の環境で開いて確かめておきたいところだ。

なお Gutenberg プラグインでは 22.6 以降、プラグインが有効な環境では投稿エディタを強制的に iframe 化する挙動が先行して入っていた。互換性の問題を早めに表面化させ、コアに入る前に報告してもらうためだという。プラグイン版を入れて運用していたサイトは、すでにこの状態を通ってきていることになる。

一覧画面の行見出しも入れ替わっている

同じ 7.1 では、投稿一覧の表の組み立ても変わった。行の見出しを担う、scope 属性が row の th 要素が、チェックボックスの列からタイトルの列へ移っている。チェックボックスのセルは td になり、タイトルのセルが th になって、投稿タイトルを aria-label として持つ形になった。

読み上げソフトが各行をチェックボックスではなく投稿名で認識できるようになるので、アクセシビリティの面では順当な改善だ。ただしこのあたりの markup は2010年ごろからほとんど動いていなかった部分で、一覧画面に独自の列を足すプラグインや、管理画面向けに書いた CSS が暗黙のうちに依存している場合がある。チェックボックス列のクラスを狙っているセレクタや、投稿タイトルが td の中にある前提で書いた JavaScript があれば、更新後に一度見ておくと安心だ。

中小企業のサイト運用では、編集画面まわりの変更は不具合として上がってくるより先に、なんとなく使いにくくなったという曖昧な形で相談が来ることが多い。更新後に自分で新規投稿を一本開いて、普段使っているブロックとプラグインがいつもどおり動くかを確かめておく。それだけで、たいていの不安は先回りして片付けられる。

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

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

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

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