月: 2026年8月

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

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

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