ゲスト購入した注文をあとから会員に紐づけられるように

つくば市のホームページ制作会社

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

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

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

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

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

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

ChromeとFirefoxの更新間隔が秋から短くなる

つくば市のホームページ制作会社

ブラウザの新しい版が届く間隔が、この秋から短くなる。GoogleはChromeの安定版を4週間ごとに出してきたが、9月から2週間ごとに切り替える。ほぼ同じ時期に、MozillaもFirefoxで同じ方向の変更を試す。新機能が増えるという話とは少し性格が違って、これはサイトを作って納品したあとの面倒の見方、つまり段取りのほうに関わる変更だと思う。

Chromeは九月から二週間ごとに

Chrome for Developersの告知によると、新しい間隔での最初の安定版はChrome 153で、公開は2026年9月8日。ベータ版は各安定版の3週間前に出る。対象はデスクトップに限らずAndroidとiOSも含まれ、すべてのプラットフォームで同じ間隔になる。

変わらない部分もある。企業の管理者や、Chromiumを自社製品に組み込んで使う側に向けたExtended Stableは、これまでどおり8週間ごとのまま。DevとCanaryにも変更はない。更新の回数が増える代わりに、1回あたりに入る変更の幅は小さくなる。Googleはその点を、利用者への影響を抑えられて、公開後に問題を追いかけるときも切り分けがしやすくなる理由として挙げている。

切り替えの前後では、開発の締め切りにあたるブランチの日程も前倒しになる。告知には移行期の日程表が添えられていて、どの版がいつ枝分かれしていつ公開されるかが並べてある。個別の機能がどの版に入る予定かを追いたい場合は、Chromiumのダッシュボードや Chrome Status のロードマップで日付を確認できる。

Firefoxも同じ時期に間隔を詰める

Mozillaの開発者向けメーリングリストでは、Sylvestre Ledru氏が、Firefoxのデスクトップ版とAndroid版を9月から4週間間隔ではなく2週間間隔にすると告知している。最初の対象はFirefox 155で、公開予定は9月1日。これまでの日程なら出せなかったタイミングだ。

ただしMozillaはこれを実験と位置づけている。恒久的な変更と決め打ちせず、実際に走らせてみた結果を見ながら必要に応じて調整するという書き方をしている。開発者に倍の速さで働くことを求めるものではなく、準備できていない仕事を急がせるつもりもない、機能は必要なだけ時間をかけてよい、という説明も添えられている。頻度を上げる狙いは、出せる状態になったものが利用者に届くまでの待ち時間を減らすところにある。

四週間ごとで出る最後のChrome 152

現行の間隔で出る最後の版がChrome 152になる。ベータの告知を見ると、CSS側では音声や動画の状態に応じて見た目を変えられる擬似クラスが増えている。再生中や一時停止中、読み込み待ち、消音といった状態を :playing:paused のような形で書き分けられる。自前の再生ボタンを作るときに、状態の受け渡しをJavaScriptで持たずに済む場面がありそうだ。

ほかにも、既存の色を参照して透明度だけを変えられる相対的な指定や、入力欄の自動修正の効き方を制御する autocorrect 属性が入る。どれも派手な機能ではないが、実務でよく書いていた小さな回り道を減らす種類の変更が並んでいる。こうした細かい追加が、これからは半分の間隔で積み上がっていくことになる。

保守の段取りをどこで区切るか

頻度が上がって困るのは、たいてい機能そのものではなく、こちら側の段取りのほうだ。よくあるのが、保守の説明や見積書に「最新版のChromeとFirefoxで表示確認」と書いてあるだけで、いつ確認するかは決めていないというケース。間隔が半分になると、確認の回数を増やすのか、こちらで区切りを決めてまとめて棚卸しするのかを先に決めておかないと、追いつけていない感覚だけが残ってしまう。

現実的なのは、毎回は追いかけないと割り切ることだと思う。ベータ版で先に触れる期間は変わらず用意されているので、自分たちが関わるサイトで実際に使っている仕組みに関係する変更だけを拾い、それ以外は通常の保守の周期でまとめて見る。手の数が限られている小規模な制作現場ほど、この線引きを最初にしておく効果は大きい。

頻度が上がることには直接の利点もある。修正が手元に届くまでの待ち時間が短くなることだ。深刻な脆弱性の修正を定期便とは別に配る仕組みは以前からあるが、通常の不具合や表示の食い違いも、これまでより早く解消されるようになる。閲覧する側の環境が新しくなる速度が上がるという意味では、作る側にとって悪い話ではない。

もうひとつ、版番号を条件にした分岐や、対応範囲を版番号で書いた文書は、これから急速に古びていく。番号ではなく、その機能が使えるかどうかで判断する書き方に寄せておいたほうが、あとで書き換える手間は少なくて済む。ブラウザ側が速く動くようになるほど、こちら側は番号から距離を置いたほうが楽になる。

外向きの通信先をサイト側で絞れる仕組みがChromeに

つくば市のホームページ制作会社

ページの中から外へ出ていく通信の宛先を、サイト側があらかじめ決めておく。そんな仕組みがChromeのベータ版に入った。Connection Allowlistsと呼ばれる機能で、少し前の版からオリジントライアルとして試験提供されていたものが、次の安定版で正式に出荷される段階へ進んだ。出荷予告によれば、デスクトップとAndroid、WebViewを対象に、利用者側で特別な設定をしなくても有効になるとされている。

使い方はHTTPのレスポンスヘッダー1本だ。Connection-Allowlist というヘッダーに、通信を許可するURLのパターンを並べて返す。ブラウザは接続を張る前に宛先を照らし合わせ、リストに載っていない相手には接続しない。自分自身のオリジンを含めたいときは response-origin という書き方が用意されている。対象になるのはfetchによるサブリソース取得だけでなく、画面遷移やリダイレクト、prefetchやpreconnectといった先読み系の指定、さらにWebSocketやWebTransport、WebRTCまで広い。文書だけでなく、Worker類にも適用できるとされている。

考え方としてはコンテンツセキュリティポリシー(CSP)の connect-src に近いが、CSPが読み込み元を用途ごとに細かく書き分けるのに対して、こちらは許可する宛先の一覧を一箇所にまとめ、接続を確立する手前でまとめて判定する。狙いとしてわかりやすいのは、外部から読み込んでいるスクリプトが何らかの理由で書き換えられ、フォームに入力された内容を見知らぬ宛先へ送り出してしまうような事故だろう。そうした通信を、ブラウザ自身が門番となって止める位置づけになる。

いきなり遮断せずに様子を見られる

現場的にありがたいのは、記録だけを取るモードが最初から用意されている点だ。Connection-Allowlist-Report-Only というヘッダーを使うと、実際の通信は止めないまま、リストから外れた宛先をReporting API経由で受け取れる。開発者ツール側の対応も入っているとされ、稼働中のサイトにいきなり適用して決済や地図が動かなくなる、という事態を避けながら、自分のサイトがどこへ通信しているのかを棚卸しできる。

一方で、現時点で実装を表明しているのはChromiumの系列だけだ。Firefoxはヘッダーの書式をめぐって意見の相違があり議論中、Safariは公式な立場をまだ示していないとされている。守りをこれ一本に預けるのではなく、これまで通りCSPを整えたうえで、対応するブラウザでは壁がもう一枚立つ、と考えるのが現実的だろう。中小企業のサイトでも、アクセス解析のタグ、チャットの窓口、フォーム、外部サービスの埋め込みと、気づけば通信先は増えていく。まずはレポート専用のモードで一度眺めてみると、思っていたより多くの宛先が並ぶかもしれない。

メニューの現在地と画面遷移をCSSで指定する提案

つくば市のホームページ制作会社

サイトのグローバルメニューで「今いるページ」だけ色を変える。制作の現場では当たり前にやっている処理ですが、実装の中身はいまだに泥臭いままです。WordPressならテンプレート側で付与されるクラスを頼りにし、静的サイトなら手書きでクラスを足すか、JavaScriptでURLを見て付け替える。ページ遷移のアニメーションまで含めると、さらに手数が増えます。

その領域をCSSの言葉で書けるようにしよう、という提案が7月末に公開され、8月に入って各所で取り上げられています。Chromeの開発者リレーション側から出ているもので、CSS Working Groupのベルリンでの対面会議で発表される予定とされています。仕様案の名前はCSS Route and Navigation Matchingです。

URLのかたちに名前をつける

提案の土台になっているのが@routeという新しい記法です。URLのパターンに対して名前をつけておく、という発想で、たとえばトップページを表すパターンと、詳細ページを表すパターンをそれぞれ別の名前として登録します。パターンの書き方は、サーバー側のルーティングで広く使われている記法をそのまま持ち込む形になっています。

ここが効いてくるのは、URLの判定ロジックがスタイルシートの中に集約される点です。今までは「このページかどうか」の判定がテンプレート、JavaScript、CSSのクラス名の三箇所に散っていました。名前をつけて参照する形になれば、少なくとも見た目に関わる部分は一箇所に寄せられます。

サイトのURL設計そのものをスタイルシート側に書き写すことになるので、運用の途中でURLを変えたときの追従先が明確になる、という副次的な効果もありそうです。逆に言えば、パターンの登録場所が増えれば管理箇所も増えるわけで、そのあたりの落としどころは実装が出てからの評価待ちでしょう。

どこから来てどこへ行くかで演出を変える

@navigationは、遷移の出発点と到着点を条件にして、その組み合わせのときだけスタイルを効かせる仕組みです。一覧から詳細へ進むときは左へ流れ、詳細から一覧へ戻るときは右へ戻る、といった向きのある演出を、遷移の向きそのものを条件として書けます。

従来これを実現するには、遷移を横取りして遷移前と遷移後のURLを比べ、View Transitionの種類をスクリプトから動的に指定する必要がありました。ページ数が少ないうちはよくても、階層が増えるほど条件分岐が膨らみます。宣言的に書けるようになるなら、この手のコードはかなり減らせそうです。

実務の目線で言えば、遷移演出は「入れたいが手間に見合わない」と判断されがちな部類です。デザイン段階では案に上がっても、実装コストと不具合の起きやすさを考えて見送る。書き方が数行で済むなら、その判断のラインは確実に動きます。

リンクの行き先を見て装飾する

もうひとつ、:link-to()という擬似クラスが提案されています。リンクの行き先が、登録しておいたルートやURLパターンに合致するかどうかで、そのリンク自体の見た目を決められるというものです。冒頭に挙げたグローバルメニューの現在地表示は、まさにこれで書ける範囲に入ります。

あわせて、遷移のきっかけになった要素そのものを指す:nav-sourceも用意されています。押されたリンクやボタンだけを起点にした演出が組めるので、カード一覧から詳細へ移る際に押したカードだけを動かす、といった表現が素直に書けるようになります。

現時点でできること

状態としてはまだ仕様の草案段階で、Chrome Canaryで実験的機能のフラグを立てれば試せる、という位置づけです。仕様の細部は議論の最中で、GitHub上で意見を募っている段階でもあります。今日の案件に持ち込むものではありません。

ただ、方向としては注目に値します。この一年ほど、JavaScriptで組み立てていた挙動がHTMLやCSSの側へ移っていく流れが続いており、この提案もその延長線上にあります。中小企業のサイトのように、メニューが数項目で、遷移の演出も凝ったものは求められない案件ほど、この手の機能は恩恵が大きいはずです。現在地の表示のためだけにスクリプトを1本読み込む、という判断をしなくて済むからです。

今のうちにできるのは、自社サイトや保守案件で現在地表示や遷移演出をどう組んでいるかを把握しておくことくらいでしょう。実装が散らばっているほど、こうした仕様が実装されたときの整理の効果は大きくなります。

更新前に確かめておきたいWordPressの挙動変更

つくば市のホームページ制作会社

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある質問の飾りが消えたあとの構造化データ

つくば市のホームページ制作会社

検索結果の見た目にかかわる仕組みは、この数年でずいぶん整理されてきた。中でも設置していたサイトが多かったのが、質問と回答を検索結果の中に折りたたんで見せるFAQのリッチリザルトだ。表示そのものは今年の五月に止まり、その後もSearch Console側の対応が段階的に外されてきた。最後まで残っていたAPIのサポートが、今月で終わる。

ひとつの表示形式が消えるという話にとどまらず、構造化データを何のために書くのかという前提が静かに動いている。過去に廃止された型の顔ぶれと、逆に細かくなっている領域を並べて見ると、その動きが見えてくる。

段階的に外されてきた対応が今月で終わる

時系列を整理しておく。FAQのリッチリザルトが検索結果に出なくなったのは五月七日で、同じ日にGoogleのドキュメントへ廃止の告知が入った。六月にはSearch Consoleの検索での見え方のレポートと、リッチリザルトテストからFAQの扱いが外れた。ドキュメント側でもFAQのリッチリザルトに関する記述そのものが削除されている。そして八月、Search Console APIからのサポートが外れる。

実務上の影響は、どこまで自動化しているかで変わる。管理画面を目視で確認しているだけなら、六月の時点でレポートが消えているので今月は何も起きない。一方、APIを叩いてレポートを自社ツールやスプレッドシートへ流し込んでいる場合、FAQの項目を参照している処理は今月のどこかで結果が返らなくなる。制作会社が保守で運用レポートを自動生成しているケースでは、ここが静かに壊れる。数字が出なくなるのではなく、項目そのものが無くなるという壊れ方なので、エラーで気づけるとは限らない点に注意したい。

付け加えると、Googleは表示をやめただけで、ページに書かれたFAQの構造化データを読むこと自体はやめていないと説明している。マークアップを急いで剥がす必要はない、という整理になる。

消えていった型に共通していたもの

廃止されたのはFAQだけではない。手順を検索結果に並べて見せるHowToは、モバイルでの表示が絞られたあと、二〇二三年九月にデスクトップでも出なくなった。教育系のサイトで使われていたPractice Problemは、今年一月にSearch Consoleとそのレポート機能からサポートが外れている。

共通しているのは、表示される機会がそもそも少なく、表示されても利用者があまり触っていなかった型だという点だ。Googleの説明でも、使われる頻度が低く利用者への価値が大きくない機能を整理した、という言い方をしている。逆に言えば、検索結果の面積は有限で、そこに何を出すかは常に取捨選択の対象だということでもある。

もうひとつ見落としやすいのが、FAQのリッチリザルトが後半では大きなサイトにしか出なくなっていたことだ。同じマークアップを書いても表示されるかどうかは相手次第で、中小規模のサイトでは書いても出ないという状態が先に来ていた。今回の廃止は、その状態を正式に確定させたに近い。

この経緯は、リッチリザルトを前提にページを設計することの危うさも示している。手順を並べる形式が有利だと聞いてHowTo用にページを組み直した制作現場は当時それなりにあったはずだが、その表示は数年で消えた。表示形式は検索側の都合で入れ替わるものだと考えておくほうが、長い目で見れば手戻りが少ない。

構造化データ全体が縮んでいるわけではない

廃止の告知が続いたことで、構造化データそのものを縮小していく方針なのではという受け取り方が一部で広がった。ただ、Googleはこれを明確に否定している。整理の対象はあくまで使われていない一部の型であり、基本的な情報の伝え方をやめるわけではない、という立場だ。担当者からは、表示形式は移り変わるものだが、タイトルタグやrobotsの指定のように手放してはいけないものもある、という趣旨の説明も出ている。

実際、記事、パンくず、事業所情報、商品、動画といった定番の型は今も現役で、廃止の予定は出ていない。中小企業のサイトで効いてくるのは元々このあたりで、FAQの有無で検索流入が大きく動いていたサイトはそう多くないはずだ。手を入れる優先順位を決めるときは、廃止された型の話より、こうした残っている型が正しく出力できているかを見るほうが実りがある。

商品や価格まわりはむしろ細かくなっている

縮小の反対側で、記述が細かくなっている領域もある。七月には、販売者向けの商品情報にcategoryプロパティが追加された。文字列でカテゴリ名を書く方法と、コード体系で指定する方法の両方が使えるようになっている。加えて、セール期間の扱いを説明する節が新設され、開始と終了の日時を表すvalidFrom、validThrough、そして表示価格の有効期限を示すpriceValidUntilの使い分けが整理された。

この方向は分かりやすい。人間が読む文章から機械的に取り出しにくい情報ほど、構造化データで明示する価値が残るということだ。質問と回答は本文を読めば分かるが、そのセール価格がいつまで有効なのかは本文の書きぶり次第で判別できない。だからこそ価格や在庫、期間といった要素は、むしろ書式が整えられていく。

通販をやっていないサイトでも、この考え方は流用できる。営業時間、所在地、対応エリア、料金の条件といった、本文中では表現がばらつきやすい情報を構造化データ側で揃えておくと、後から自分たちで検算しやすくなる。表示のためというより、データとしての整合性を保つための作業に近い。

付随して、期間を持つ情報には失効という考え方がついて回る点も押さえておきたい。終了日を書いた以上、その日を過ぎた記述が残っていれば、それは単に古い情報になる。構造化データを入れるということは、更新の責任を一つ増やすことでもある。誰がいつ見直すのかを決めないまま項目だけ増やすと、数年後に手をつけられない塊になりやすい。

口コミの扱いに条件が足された

七月下旬には、レビュースニペットのガイドラインにも追記があった。やらせのレビューや、報酬と引き換えに書かれたレビューについての基準が加わっている。星の数を検索結果に出す仕組みは以前から人気があるが、その分だけ、出所の怪しい評価を集めて表示させようとする動きも起きやすい。基準が明文化されたのは、そこに線を引く必要があったからだろう。

地方の事業者にとっては、他人事ではない話でもある。レビューを集める施策を外部の業者に任せている場合、その集め方がガイドラインに触れていないかは一度確認しておきたい。表示が止まるだけならまだしも、サイト全体の評価に影響が及ぶ形になると、回復に時間がかかる。

制作の現場で見直しておきたいところ

まず、FAQのブロック自体は消さなくていい。検索結果に出なくなっただけで、訪問者にとって質問と回答の形式が読みやすいことは変わらない。むしろ、リッチリザルト目当てで無理に質問形式へ変形させていたページがあるなら、この機会に読み物として自然な形へ戻すほうが素直だ。表示のために作られた文章は、たいてい読みにくい。

次に、構造化データの出所を把握しておきたい。WordPressで運用しているサイトの多くは、SEO系のプラグインやテーマが自動で出力している。プラグインを乗り換えたり、テーマを入れ替えたりしたときに、古い型と新しい型が二重に出ていたり、逆にどこからも出なくなっていたりすることがある。リッチリザルトテストやスキーマの検証ツールで、主要なページを何枚か抜き取って確認するだけでも状況はつかめる。

そして、レポートの自動化をしているなら今月のうちに参照箇所を確認しておく。APIの項目が消える変更は、画面を見ているだけでは気づきにくい。数年単位で運用するサイトほど、こういう小さな失効が積み重なって、いつの間にか誰も中身を保証できない状態になりやすい。

構造化データは、検索結果を飾るための道具から、ページの内容を機械に正しく渡すための道具へと、役割の重心が移りつつある。飾りが減ったぶん、書いた内容が正しいかどうかだけが残る。派手さはないが、こちらのほうが手入れのしがいはある。Google検索セントラルの更新履歴は日付順に並んでいるので、こうした変更を追うときの起点として使いやすい。

アイコンの置き場所が次期WordPressで一本化される

つくば市のホームページ制作会社

サイトにアイコンを一つ足すだけの作業が、案外ややこしい。テーマのフォルダに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はそのまま出力されるわけではなく、本体のタグ整形処理を通る。許されるのは svgpathpolygon の三種類の要素と限られた属性だけで、それ以外の要素やインラインの装飾指定、スクリプト、イベント属性は落とされる。現時点では線の太さを指定する属性や、外側の要素に付けた塗りの指定も対象外とされている。

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

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

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

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

毎年恒例のCSS調査から見える現場の使い分け

つくば市のホームページ制作会社

CSSの使われ方を毎年たずねている調査「State of CSS」の最新の結果が公開された。回答を集めたのは今年の5月中旬から6月末にかけてで、世界の制作者4,902人が答えている。新機能の発表そのものではないが、現場で何が実際に使われていて、何がまだ様子見なのかが数字で並ぶので、自分たちの手札を確かめる材料になる。

使用率の上位は、条件に合う子要素を持つ親側を指定できる :has() が83.7%、縦横比を保つ aspect-ratio が81.3%、入れ子で書ける CSS Nesting が70.6%と続いた。少し前まで「便利そうだが対応状況が心配」と言われていた顔ぶれが、上から順に普通の道具として定着したことになる。逆に、この春から夏にかけて主要ブラウザに入ったばかりの指定は使用率が数%にとどまっており、ブラウザで使えるようになったことと、実案件で使われることの間には、やはり数年単位の距離があるとわかる。参考にしている情報源としては、MDN と Can I Use を挙げた人が多かった。新しい指定を試す前に対応状況を確かめる、という手順が広く共有されているということだろう。

気に入られている機能と、使われている機能

面白いのは、注目度と使用率が一致していない点だ。回答者が最も気に入った新機能として挙げたのは、要素を別の要素に紐づけて配置するアンカーポジショニング(anchor positioning)だった。ところが「対応状況が理由で使えていない機能」の筆頭にも、同じ名前が並ぶ。画面遷移をなめらかに見せる View Transition API や、条件分岐を書ける if() も似た位置にいる。触ってみたい気持ちと、納品するサイトに入れられるかどうかの線引きが、はっきり分かれている様子がうかがえる。

つまずきどころとして多く挙がったのは配置まわりで、次いで :has()、コンテナの幅で見た目を出し分ける @container が並んだ。どれも、うまくはまれば記述量がぐっと減る反面、思ったように効かないときの原因追いに時間を取られやすい種類の機能だ。それでも全体の満足度は5段階でおよそ4と、ここ数年ほぼ横ばいのままだった。書きやすくなった実感と、細かいところでの引っかかりが同居している、という受け止め方が続いていることになる。

中小企業のサイトを預かる立場からすると、この手の調査は流行を追うためというより、線引きの目安として使いやすい。使用率が高く枯れた機能は迷わず採用し、話題の新しい指定は、効かなかったときの見え方まで用意できる範囲で試す。企業サイトは公開してから何年も動き続けるものが多く、閲覧環境の幅も広い。上位に並ぶような定着した機能であれば、古い端末が混ざる相手でも心配は少ない。数字を眺めながらそのあたりの分け方を決め直すだけでも、調査に目を通す価値はある。詳しい内訳は調査結果のページで公開されている。

ログイン画面の不備を含むWordPressの臨時セキュリティ更新

つくば市のホームページ制作会社

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の入れ替えが先送りになった

つくば市のホームページ制作会社

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

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

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

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

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

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