タグ: Wordpress

WordPressの公式ドキュメントであるCode Referenceで、掲載されているコード例をその場で実行できるようになった。9月上旬にMake WordPress Coreで告知されたもので、WordPress 7.1で最初の2件が公開され、7.2でさらに増える予定とされている。

対象になっているのは、たとえば WP_HTML_Processor::class_list() の解説ページだ。コードブロックに付いた実行ボタンを押すと、そのページの中で結果が表示される。ローカル環境を立ち上げたり、どこかにコピーして貼り付けたりする手間がいらない。ドキュメントを読みながら挙動を確かめられる、という形になった。

実行できるコード例は本体のコメントから作られる

興味深いのは、この実行できるコード例が、ドキュメント用に別途手作りされているわけではないところだ。WordPress本体のソースコードにあるDocBlock、つまり関数やメソッドの上に書かれているコメントの中に、そのまま書かれている。

通常のコード例との違いは、コードフェンスの言語指定を php interactive と書くことだけだという。書き方の詳細をまとめたハンドブックのページも、追って公開されるとされている。

ドキュメントとコードが離れた場所で管理されていると、更新のタイミングがずれて片方だけが古くなる。本体のコメントに書いておけば、コードを直した人が同じ場所で例も直せる。地味な話に見えるが、説明を長く正しい状態に保つうえでは効いてくる作りだ。

ブラウザの中でPHPを動かす仕組みが土台にある

実行を支えているのはWordPress Playgroundだ。もともとはブラウザの中でWordPress一式を動かすための仕組みで、WebAssemblyに移植したPHPが土台になっている。

この春に公開されたPlayground側の解説によると、<php-snippet> というカスタム要素が追加され、スクリプトタグをひとつ読み込むだけで、任意のウェブページに実行できるPHPの例を置けるようになったという。読者が実行ボタンを初めて押したときに、隠しiframeの中でPHPが読み込まれて動く仕組みで、ページを開いただけでは重い処理は走らない。

同じページに例が複数あるときは、条件が一致していれば同じ実行環境を使い回す。チュートリアルにサンプルをいくつも並べても、そのたびにPHP環境を立ち上げ直すことにはならないわけだ。既定のPHPバージョンは8.4、WordPressは最新版で、属性で指定すれば例ごとに変えられる。WordPressを読み込まず、PHPの言語機能だけを試す指定も用意されている。

自分たちのドキュメントに埋め込むこともできる

この仕組みはWordPress公式サイト専用の機能ではなく、外部のページでも使える。スクリプトを読み込み、要素の中にPHPを置くだけだ。実行前に想定される出力を先に表示しておく指定や、コードを別ファイルから読み込む指定、実行させずに色付け表示だけにする指定などもある。

Blueprintという設定用のJSONを併用すれば、実行前にmu-pluginを置いたり、オプションを設定したり、サンプルの投稿を用意したりといった下準備もできる。複数の例で同じBlueprintを共有すれば、環境を一度だけ用意して順に実行させられる。

導入時の注意点も挙げられている。Content Security Policyを厳しく設定しているサイトでは、Playground側から配信されるスクリプトと隠しiframe、そこから読み込まれる各種ファイルを許可する必要がある。それが難しい環境では、スクリプトを自前で配信して参照先を切り替える方法も案内されている。うまく動かないときは、開発者ツールで失敗している通信を確認するのが早い。

手元に環境がない相手に説明するときに効く

制作会社の立場で考えると、使いどころは社外向けの説明だろう。クライアントや外部の協力者に「この関数はこう動く」と伝えたいとき、手順書を書いてローカル環境の構築から始めてもらうのは相手の負担が大きい。動くものをページに置いておけば、読む側は押して確かめるだけで済む。

自社の技術メモや、配布しているプラグインの説明ページに、短いサンプルを実際に動かせる形で残しておくのも現実的だ。文章で説明した挙動と実際の出力が食い違っていないか、書いた側が自分で確かめられる点も含めて、書く手間に見合うものはありそうに思える。

サイトの引っ越しやバックアップで広く使われているプラグイン、All-in-One WP Migration and Backup に深刻な脆弱性が見つかり、開発元の ServMask がバージョン 7.110 で修正した。識別番号は CVE-2026-19949、影響を受けるのは 7.109 までのバージョンで、深刻度の指標は 8.8 とされている。有効インストール数が 500 万件を超える定番だけに、預かっているサイトのどれかに入っている、という制作者は少なくないはずだ。

見つけたのはセキュリティ研究者の Jack Taylor 氏で、Wordfence を通じて 8 月半ばに開発元へ伝えられ、8 月 20 日に修正版が公開された。報じられている Wordfence の説明によると、原因はアーカイブを復元する際にデータベースの中身を書き換える処理にあり、エスケープされたバックスラッシュや引用符の解釈が正しくなかったという。

仕込みと発動がずれているところが厄介

この脆弱性が少し変わっているのは、攻撃が二段構えになっている点だ。ログインしていない第三者でも、トラックバックを使って細工したデータを投稿に紐づけて置いておける。置かれた時点では何も起きない。管理者がサイトを書き出し、別の環境に取り込んだその瞬間に、保存されていた文字列が SQL として動き出す。

その結果、プラグインが内部で使う取り込み用の秘密キーが公開コメントとして表に出てしまう可能性がある。キーを手に入れた側は、実行可能なコードを含んだ .wpress ファイルを取り込ませることができ、最終的にサイトを掌握される恐れがあると説明されている。バックアップと復元はこのプラグイン本来の用途そのものなので、いつかは引かれる引き金だと考えておいたほうがいい。

BleepingComputer の集計では、修正版が出てしばらく経った時点でも更新を済ませたのは利用者のおよそ 3 割で、残る 325 万件ほどが古いまま動いていた。バックアップ系のプラグインは普段の運用で触らないぶん、入れたまま忘れられやすい。停止していれば危険度は下がるものの、一時的に有効化すれば同じ経路が開くとも指摘されている。移行の予定がなくても、管理画面を開いてバージョンを確かめる価値はある。自動更新を切っている運用では、ここが抜けたままになりやすい。

実務でもうひとつ気をつけたいのが、手元に残っている古いアーカイブの扱いだ。細工されたデータは投稿に紐づく形でデータベースに入るため、すでに書き出した .wpress の中に紛れ込んでいる可能性がある。修正版に上げてから取り込めば処理する側は安全になるが、まずテスト環境に流して様子を見るくらいの慎重さはあってよいと思う。複数のサイトを預かっている制作会社であれば、このプラグインが入っている案件を洗い出すところから始めるのが早い。移行や復旧のために入れて、そのまま残っているケースも案外あるはずだ。

WordPressのブロック開発まわりの月次まとめが公開されていて、9月分にはテーマを書く側や制作会社の実務に効きそうな変更がいくつか入っていた。派手な新機能というより、納品したあとのサイトをどう保つかに関わる調整が多い。

背景として、8月に出たWordPress 7.1では、ホバーやフォーカスといった状態のスタイルと、画面幅ごとのスタイルを管理画面から指定できるようになった。CSSを書かずに見た目を触れる範囲が広がったわけだが、これは同時に、制作側が整えたデザインを運用側が意図せず崩せる範囲も広がったということでもある。

状態スタイルの編集をテーマ側で閉じられる

Gutenberg 23.8で、ブロックの状態スタイル編集と、画面幅ごとの編集のそれぞれにオプトアウトの設定が追加された。blockStatesEditingEnabledとresponsiveEditingEnabledの2つで、どちらも既定は有効、block_editor_settings_allフィルターからfalseにできる。

使えると感じたのは、無効にしても表示が壊れない点だ。theme.jsonやグローバルスタイル、ブロックのstyle属性ですでに定義してあるスタイルは、どちらの設定でもそのまま出力される。編集画面から触れなくなるだけなので、作り込んだデザインを保ったまま運用担当者に渡せる。サイトを納品して、その後の更新はお客様側で、という進め方をしている案件では出番がありそうだ。

運用者が見る画面まわりでは、投稿の編集画面とウィジェット編集画面が、管理画面で選んだ配色を引き継ぐようになった。あわせてgetAdminThemeColors()が公開の関数として使えるようになっていて、管理画面の本文クラスから配色を読み取り、主要色と背景色を返す。独自の管理画面を追加しているプラグインでも、同じ二行の囲みを入れておけば利用者が選んだ配色に合う。細かい話ではあるが、追加した画面だけ色が違うという座りの悪さは減らせる。

グローバルスタイルで扱える要素が広がった

Gutenberg 23.9では、theme.jsonの要素スタイルにlabelが加わった。styles.elements.labelで指定でき、label要素を出力するマークアップ全般に効く。コアでは検索、フォーム入力、コメントフォーム、アーカイブ、カテゴリーの各ブロックが対象で、サードパーティ製のブロックにも適用される。

引用元表示のcite、テキスト入力、セレクトの3つは、以前からtheme.jsonでは指定できたものの、エディター上のスタイル画面からは触れなかった。これがタイポグラフィと色のパネルから編集できるようになっている。グループブロックはブロック間隔の対応を縦横それぞれに宣言するようになり、theme.json側では文字列だけでなくtopとleftを持つオブジェクトも受け取る。リストブロックの幅広と全幅、クエリーループのブロック間隔といった細かい対応追加も入った。

theme.jsonが無効扱いされる場面が減る

7.1で入った状態スタイルは、記述を検証するスキーマのほうが追いついていなかった。Gutenberg 23.8では、スタイルバリエーション向けの状態、状態が要素ではなくブロックに固有である点、擬似クラス指定の誤りといった箇所に修正が入っている。コードエディターでtheme.jsonを開いたときに、正しい記述が無効として警告される場面が減るという話だ。地味な変更だが、テーマを書いている時間にはそのまま効いてくる。

公式ドキュメントの例をその場で動かせる

もうひとつ、開発者向けリファレンスに載っているコード例が、ブラウザ上で実行できるようになった。関数のページで実行ボタンを押すと、Playgroundで動く本物のWordPressに対してスニペットが走る。例はDocBlockの中にphp interactiveという名前のコードフェンスで書かれていて、ドキュメントと関数の定義が同じファイルに並ぶ形になっている。挙動を確かめるために手元へ環境を作らなくてよくなる分、調べ物の往復は短くなるはずだ。

次のWordPress 7.2は、ベータ版が10月下旬、正式版が12月上旬の予定とされている。独自ブロックを持っている場合、内部ブロックのテンプレート指定がInnerBlocksのプロパティからブロックタイプの設定へ移り、従来の書き方は非推奨になった点は早めに手を入れておきたい。複数人が同時に編集する機能への対応が理由とされていて、今後この種の書き換えはもう少し続きそうだ。

WordPress 7.1が公開されたのは8月19日だった。それからひと月も経たないうちに、次に来る修正版である7.1.1の日程が公表されている。9月2日に出た告知には、バグを仕分ける作業日の日取りから一般公開の予定日までが一覧で並んでいる。大きな更新のニュースは目にしても、その後始末の予定まで公開されていることは意外と知られていない。

修正版の日程は前もって示される

公表された予定では、9月3日と4日、8日、9日、15日にバグの棚卸しにあたる作業日が置かれ、9月10日にリリース候補版、9月17日に7.1.1の一般公開という並びになっている。時刻はいずれも協定世界時での目安で、実際の時間は担当者の都合によって前後する可能性があるとも添えられている。

この予定が出る前、8月20日の時点では「9月1日から24日のあいだ」という幅のある見通ししか示されていなかった。報告されたバグの深刻さと数を見てから時期を決めるという方針があるためだ。公開後に寄せられた報告の量と深刻さから、修正版は習慣的に準備すべきだと判断された、という書き方になっている。幅のある見通しが具体的な日付へ絞り込まれていく過程が、そのまま外から追える状態に置かれている。

入るものと入らないものが決まっている

7.1.1はバグ修正だけの修正版だと明記されている。対象になるのは7.1の開発期間中に持ち込まれた不具合か、7.1の締め切りの時点で意図的に先送りされた項目に限られる。新しい機能はここには入らない。何が候補になっているかは、不具合の追跡システムの一覧や編集画面まわりの作業ボードから追えるようになっている。

7.1は機能の追加が多い版だった。表示まわりでは画面幅ごとの指定が入り、切り替えの基準となる幅をテーマ側で決められるようになっている。投稿の編集画面も枠内で読み込む形に一本化された。触る範囲が広い更新のあとに報告が集まりやすいのは自然なことで、修正版の枠が早めに用意されるのはその裏返しでもある。

目を引くのは、9月8日の作業日に7.1.2の枠を開き、そこで一部の項目を先送りすると最初から告知している点だ。締め切りに間に合わないものは次に回すという判断が、あらかじめ日程に組み込まれている。直すべきものを溜め込まず、期限で区切って次の枠へ送る。規模の小さい制作現場の案件管理にも、そのまま持ち込める考え方だと思う。

少人数で回っている工程

大型更新の体制と比べると、修正版のチームはかなり小さい。担当者は1人から3人程度になることが多いと説明されている。仕事の中身は、コミッターや各機能の担当と連携してバグを仕分けること、公開のお知らせを書くこと、公開当日の作業を準備して進めること、そして次回のために手順書を更新することとされている。

大型更新に関わった人がそのまま残ることが多いものの、必須ではなく、大型更新の経験がなくても志願できると書かれている。バグの棚卸しは公開された相談部屋で行われ、自分で棚卸しの場を開いてもよいとされている。翻訳が足りていない言語があるという案内も添えられていた。ふだんは使うだけの側から見ると、公開までの手順がここまで読める状態になっていること自体が珍しい。

受け取る側の準備

小さな更新は自動で当たる設定のまま運用しているサイトが多いはずだ。実際、7月17日に出た7.0.2では深刻度の高い問題が含まれていたため、影響を受けるバージョンに対して強制的な更新が実施されている。8月6日の7.0.3では、さらに十数件の修正が入った。放っておいても当たる前提で組まれている以上、現場の役目は「更新するかどうか」ではなく「当たったあとで崩れていないか」を見に行くほうへ寄る。

更新の当たり方はサイトごとに違う。保守を受けている環境では自動更新を止めている場合もあるし、逆に管理する側で一括して当てている場合もある。どちらであっても、修正版が出る日が前もって分かっていれば、確認の予定をその前後に寄せておける。

その意味で、リリース候補版が出る9月10日から一般公開までのおよそ一週間は、手元のプラグインやテーマを新しい版に当てて試せる期間でもある。7.1では、投稿一覧の表で見出しにあたるセルの位置が長年の形から変わるといった、地味ながら影響範囲の広い変更も入っていた。修正版でどこが動くのかを先に眺めておけば、公開後に原因を探して回る時間は減らせる。日々の運用を預かる立場なら、公開日の前後で表示と管理画面を一度通しで確認しておくくらいの構えでちょうどいい。

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はデータベースの更新を伴うため、控えを取ったうえで検証環境から順に試すのが安全です。