タグアーカイブ ECサイト

ECサイトリニューアルで住所自動入力を入れるタイミングと、郵便番号で埋まる範囲

ECサイトリニューアルで住所自動入力を入れるタイミングと、郵便番号で埋まる範囲

ECサイトをリニューアルするとき、住所自動入力を組み込むなら、フォームの画面を作る前がタイミングとしてよい。

郵便番号を入れると都道府県から町名までが自動で埋まる仕組みは、後から付け足すよりも、リニューアルに合わせて入れるほうが入力の手間と表記のゆれをまとめて減らせる。

入力欄で手が止まって離脱する人を減らすには、住所を打つ文字数をどこまで減らせるかが分かれ目になる。

リニューアルの前に、自動で入る範囲と更新の進め方を決めておくと、あとから画面を作り直さずに済む。

ECサイトリニューアルで住所自動入力を考えるタイミング

ECサイトリニューアルで住所自動入力を考えるタイミング

フォームの入力項目を整理する段階が、住所自動入力を検討するのに向いている。

すでに動いているフォームに後から組み込むと、画面の作りを変える手間が増える。

リニューアルでフォームの構成を見直すときなら、入力の負担と住所の表記を同時に整えられる。

フォームの画面を作り始める前に組み込む

入力項目をどう並べるかを決める前に、郵便番号でどこまで自動に入るかを知っておくと、フォームの設計が一度で済む。

自動で都道府県から町名までが入るようにしておけば、利用者が打つのは番地と建物名だけになる。

この形を先に決めておくと、スマートフォンでの入力中に離脱するきっかけを減らせる。

リニューアルの目的に合わせて項目を減らす

会員登録や問い合わせフォームにも同じ仕組みを入れられる。

リニューアルでフォーム全体を触るなら、注文だけではなく登録と問い合わせの住所欄もまとめて整えると、入力の負担が揃う。

利用者がどこから来ても、住所を打つ手間が同じ水準になる。

郵便番号で自動に入る範囲と、残る入力

郵便番号で自動に入る範囲と、残る入力

郵便番号からの住所自動入力は、都道府県から町名までを自動で埋める。

番地と建物名は手入力のまま残る。

この範囲をあらかじめ知っておくと、リニューアル後に「全部自動で入ると思っていた」というずれを防げる。

自動で入るのは町名まで

郵便番号を入れると、都道府県、市区郡、町名までが住所欄に映る。

アパート名や部屋番号まで自動で入るわけではない。

番地と建物名だけを打ってもらう形にすると、入力する文字数を減らしつつ、誤った住所が入る余地を小さくできる。

数字の全角やハイフンの差は自動で整える

利用者が全角で数字を入れたり、ハイフンを付けたり付けなかったりしても、郵便番号は7桁の形式に整う。

この処理があると、フォームのエラーで先へ進めないという場面を減らせる。

入力の揺れをフォーム側で吸収するため、利用者に書き直しを求めなくて済む。

リニューアルのときに決めておく更新のしくみ

リニューアルのときに決めておく更新のしくみ

郵便番号と住所の対応は、市区町村の変更などで変わっていく。

そのため住所自動入力を入れるときは、更新のやり方を導入の時点で決めておく。

リニューアル後も住所が正しく入り続けるには、この段取りが欠かせない。

郵便番号と住所の対応は変わり続ける

新しい町名ができたり、郵便番号の割り当てが変わったりすると、自動で入る住所が古いままになることがある。

導入時に更新の方法を決めておけば、リニューアル後も最新の住所を引ける。

この更新の仕組みを後回しにすると、住所が古いまま放置されて配送の不備につながる。

定期更新を含めるかは、導入前に私たちと決める

更新を自動で行う仕組みにするか、定期的に新しい郵便番号データを反映する作業を含めるかは、リニューアルの前に私たちと決める。

更新作業を定期的に含める場合は、その範囲を導入時に合わせておく。

郵便番号の変化に対応し続けると、リニューアル後も住所入力の信頼を保てる。

住所自動入力を入れると変わること

住所自動入力を入れると変わること

入力の手間が減ると、注文や登録を最後まで終える人が増え、住所の表記もそろう。

訪問者の数が変わらなくても、フォームの離脱と配送の不備が減れば、広告費を足さずに売上の取りこぼしを減らせる。

途中離脱を減らし、注文を最後まで終える人を増やす

住所をすべて手で打つフォームは、スマートフォンだと特に入力に時間がかかる。

郵便番号だけですぐに町名まで入ると、打つ文字数が減り、入力の途中でやめるきっかけを減らせる。

カートまで進んでも住所欄で離脱する人を、次の画面へ進めやすくする。

住所の表記がそろい、配送の不備や返送が減る

自動で入った住所は表記が一定になるため、配送先の不備や返送を減らせる。

また、自動で入った内容を本人が書き換えられる形にしておくと、細かな言い回しの違いにも対応できる。

該当する住所がない郵便番号が入力された場合は、その場で本人に伝えて往復を減らせる。

私たちは、郵便番号から住所が自動で入る入力欄を、いまあるフォームに組み込んでいる。

注文や会員登録、問い合わせのどれにも同じ作りで入れられる。

よくある質問

住所自動入力は郵便番号だけで番地まで入るのか

自動で入るのは都道府県から町名までだ。

番地と建物名は利用者に入力してもらう。

番地まで自動で入れる仕組みではないので、入る範囲を事前に知っておくとよい。

既存のフォームに後から組み込めるか

組み込める。

私たちは、いま動いている注文フォームや会員登録フォームにも、画面の作りを大きく変えずに住所自動入力を入れられる。

リニューアルのタイミングでなくても可能だ。

郵便番号データの更新はどうすればよいか

郵便番号と住所の対応が変わったときの更新のやり方は、導入時に私たちと決める。

定期的な更新作業を含めるかどうかも、そのときに合わせて決める。

自動で入った住所を利用者が直せるか

直せる。

自動で入った住所は編集できる状態にしている。

実際の表記と違う場合、利用者が番地や建物名を書き換えられる。

この記事のポイント

  • ECサイトのリニューアルでは、フォーム設計の前に住所自動入力を検討する
  • 郵便番号から自動で入るのは都道府県から町名まで
  • 番地と建物名は手入力のまま
  • 郵便番号と住所の対応は変わるため、更新のやり方を導入時に決める
  • 入力の手間と表記のゆれを減らし、離脱と返送を減らせる
郵便番号からの住所自動入力郵便番号を入れると都道府県から町名までが自動で入る仕組みをフォームに組み込むサービスの詳細を見る
ECサイトの購入者紹介の仕組みを自社で動かす設計の考え方

ECサイトの購入者紹介の仕組みを自社で動かす設計の考え方

購入者紹介の仕組みは、あなたのECサイトで買った人が知人に商品を紹介し、その紹介から新しい注文が生まれたときに、紹介者へ報酬を渡す一連の流れだ。

広告費をかけずに新規の顧客を増やせるが、誰の紹介がどれだけ売上につながったのかを記録しないと、お礼も報酬も渡せない。

紹介リンクの発行から注文の追跡、報酬の集計まで、購入者紹介の仕組みを自社で動かすために必要な要素を、設計の順にまとめる。

購入者紹介の仕組みが注文を増やす理由

購入者紹介の仕組みが注文を増やす理由

購入者紹介の仕組みは、広告を出さずに新しい顧客を増やせるのが利点だ。

知人の紹介は、広告よりも信頼されやすい。

そのため、紹介から来た注文は成約しやすい。

購入者紹介の全体像は次の通り。

購入が完了した人に専用の紹介URLを発行し、そのURLを知人へ共有してもらう。

知人がそのURLから購入すると、誰の紹介かが記録され、紹介者へ報酬が渡る。

この一連の流れが自動で回ると、購入者は自然に紹介者へ変わる。

信頼の紹介が注文につながる

購入者が商品を勧めるとき、そこには実際に使った体験が伴う。

広告には無い具体的な感想が、相手の購入を後押しする。

紹介者が報酬を受け取れれば、その動機も継続しやすくなる。

購入者紹介の仕組みを作る方法はどれか

購入者紹介の仕組みを作る方法はどれか

購入者紹介の仕組みを作る方法は、手動、外部サービス、自社組み込みの3つに分かれる。

それぞれ、紹介者のデータが自社に残るか、日々の手間がどの程度かが違う。

項目手動管理外部サービス自社組み込み
紹介者のデータ自社にある自社に残らない自社に残る
日々の手間集計が必要少ない集計は自動
柔軟な変更しやすいサービス次第しやすい

手動で管理する

手動管理は、紹介者と注文をExcelなどで突き合わせる。

費用はかからないが、件数が増えると手に負えなくなる。

外部のアフィリエイトサービスを使う

外部のアフィリエイトサービスは、紹介URLの発行や報酬管理を代行してくれる。

ただし、その分の手数料がかかり、紹介者のデータが自社に残らない。

自社のサイトに組み込む

自社のサイトに組み込むと、紹介者の情報と成果のデータがすべて自社の手元に残る。

初期の手間はかかるが、紹介の記録を自分たちで管理できる。

購入者紹介の仕組みに必要な機能

購入者紹介の仕組みに必要な機能

自社で購入者紹介の仕組みを動かす場合、必要な機能は大きく3つある。

紹介URLの発行、注文と紹介者の紐付け、報酬の集計と確認ページだ。

  • 購入完了時にその人専用の紹介URLを自動で発行する
  • 紹介URLを経由した注文を検知し、どの紹介者からの注文かを記録する
  • 紹介者ごとの成約件数と報酬額を集計し、本人がログインして確認できるページを用意する
  • 報酬の確定と支払い状況を管理する
  • 返品やキャンセル時に報酬を取り消す仕組みを持つ

紹介URLの自動発行

紹介URLは、購入者が申し込む手間をなくすため、購入完了時に自動で発行されるのが理想だ。

購入完了ページやマイページに、本人専用のURLがすぐ表示されると、紹介へのハードルが下がる。

注文と紹介者の紐付け

紹介URLを経由した注文を検知し、どの紹介者からの注文かを記録する機能が無いと、成果を追えない。

この記録が、後で報酬を正しく集計する土台になる。

報酬の集計と確認ページ

紹介者ごとの成約件数と報酬額を集計し、本人がログインして確認できるページを用意する。

紹介者が自分の成果を確認できると、次の紹介への意欲が続きやすい。

購入者紹介の報酬設計で先に決めること

購入者紹介の報酬設計で先に決めること

報酬の設計では、先に決めておくことが3つある。

報酬を固定額にするか割合にするか、確定のタイミング、返品やキャンセル時の扱いだ。

報酬を固定額にするか、割合にするか

1件あたりの報酬が変わらない場合は固定額、単価が高い商品では売上の割合が合うことが多い。

扱う商品の価格帯と、紹介者に伝えたいメッセージで選ぶ。

報酬を確定させるタイミング

注文の時点で確定させる方法と、返品期間が過ぎるまで待つ方法がある。

返品期間を過ぎてから確定させる方が、運営側のリスクは小さい。

返品やキャンセル時の扱い

成果が取り消された場合は、報酬も一緒に取り消す仕組みが必要になる。

ここを後回しにすると、払い過ぎが起きて収支がずれる。

購入者紹介の仕組みを続けるために必要な運用

購入者紹介の仕組みを続けるために必要な運用

購入者紹介の仕組みは、作って終わりではなく、運用が続けやすい形にしておく必要がある。

紹介者に自分の成績を見せること、支払い申請の受け口を作ること、二重計上を防ぐ監視がその柱だ。

紹介者に見せるページの内容

紹介者には、自分の紹介で何件の注文があり、報酬が積み上がったかが見えるページを用意する。

これがあると、紹介のモチベーションが続きやすい。

支払い申請の受け口

報酬の支払い申請を受け付ける窓口も必要だ。

紹介者がいちいちメールで問い合わせる手間を減らせる。

二重計上を防ぐ監視の考え方

報酬が二重に支払われたり、不自然に多い報酬が発生した場合に気づける監視の仕組みも入れておく。

私たちも、自社で紹介の仕組みを設計するときには、この監視を後付けではなく最初から組み込むようにしている。

運用のミスが後に大きくなるのを防げる。

よくある質問

購入者紹介の仕組みは小規模なECサイトでも役立つか

役立つ。

紹介を通じて新規客を増やす仕組みは、規模に関係なく使える。

小規模なサイトでは、信頼してくれる顧客の紹介が既存顧客の満足度を高めることもある。

自社で作るのと外部サービス、どちらが向いているか

紹介者のデータを自社に残したいなら自社組み込み、手間を減らしたいなら外部サービスが向いている。

外部サービスは手数料がかかるため、紹介が増えるほど費用も増える。

報酬はどのタイミングで確定させればよいか

返品期間を過ぎてから確定させるのが安全だ。

ただし返品が少なければ、注文時に確定させて紹介者へ早く伝える方が意欲につながる。

紹介者が不正をした場合の対策は必要か

必要だ。

極端に多い注文や重複した支払いを検知する仕組みを入れ、定期的に不自然なところがないか確認する。

後から手作業で調べるのは時間がかかる。

購入者紹介の仕組みを動かすのに必要な人員はどれくらいか

仕組みを自社で組み込んだ後は、専任の人員は必要ない。

月末の報酬確定と支払い申請の確認を、日々の業務に組み込めるなら対応できる。

外部のASPを使わずにアフィリエイト機能を構築できるか

外部のアフィリエイトサービスを使わずに、独自の紹介機能をサイトへ構築できる。

専用URLの発行や注文の検知、報酬の自動集計までを実装すれば、紹介者のデータを手元に残して運用できる。

外部サービスの手数料を抑えたい場合にも適している。

この記事のポイント

  • 購入者紹介の仕組みは、紹介URLから成約までを記録して初めて機能する
  • 自社で組み込むと、紹介者の情報と成果のデータが手元に残る
  • 報酬は固定額か売上割合か、確定のタイミングを先に決める
  • 返品やキャンセル時には、報酬も取り消す仕組みを入れておく
  • 紹介者が自分の成績を見られるページを用意すると、紹介が続きやすい
独自アフィリエイト機能の実装購入者やご登録者が自然に紹介者へ変わり、紹介から生まれた成果と報酬を自動で積み上げる機能を自社サイトに組み込むサービスサービスの詳細を見る
アフィリエイト成果を自動集計するシステムに必要な機能と、導入前に決める分担

アフィリエイト成果を自動集計するシステムに必要な機能と、導入前に決める分担

アフィリエイト成果を自動集計するシステムは、紹介URLの発行から報酬の確定までを一続きで処理する仕組みだ。

口コミが注文につながったかを追えない状態を、紹介者ごとの成約件数と報酬額が見える状態に変える。

あなたのサイトに独自の紹介制度を持つときには、紹介URLの発行、成約の記録、報酬の集計、返品時の取り消しまでを自動でつなぐ必要がある。

機能の全体像を知っておくと、後から作り直す手間を減らせる。

アフィリエイト成果を自動集計するシステムに必要な機能とは

アフィリエイト成果を自動集計するシステムに必要な機能とは

自動集計の要は、紹介URLを発行する、成果を記録する、報酬を確定するの3つが一続きで動くことである。

手作業が入る場所が1つでもあると、集計が月末に止まり、紹介者への支払いが遅れる。

紹介URLの自動発行

商品の購入やサービスへの登録が完了した瞬間に、本人専用の紹介URLを自動で作る。

紹介者はこのURLを自分のブログやSNS、メールで共有する。

URLには紹介者を識別する情報が含まれており、どのリンクから注文が来たかをデータで残す。

成約と報酬の自動集計

紹介URLを経由した注文を検知し、誰からの紹介かを記録する。

紹介者ごとの成約件数と報酬額は自動で合計され、本人がログインして確認できる専用ページを用意する。

報酬は固定額と割合のどちらでも設定でき、確定するタイミングも運営側で調整できる。

紹介者専用ページ

紹介者が自分の成績を確認できるページを持つと、次の紹介への意欲が続きやすい。

専用ページには成約件数と報酬額が表示される。

本人だけがログインして見られる形にすることで、紹介者も安心して共有できる。

紹介URLはどうやって成果を結びつけるのか

紹介URLはどうやって成果を結びつけるのか

紹介URLが無いと、知人からの口コミが注文につながったかを確かめる手段が無い。

URLに紹介者を識別する情報を埋め込み、注文のたびに記録することで、成果を紹介者ごとに分解できる。

注文に紹介者を紐付ける

紹介URLを踏んで商品を購入すると、注文データに紹介者の識別情報が付く。

誰からの紹介かを残すことで、後から成果を集計できる。

クッキーを使わず、URLのパラメータと注文完了時の記録を突き合わせる方法が確実である。

返品やキャンセル時の取り消し

商品が返品・キャンセルされた場合は、その分の報酬を自動で取り消す。

ここを手作業にすると、支払い済みの報酬を後から回収する事態になる。

自動で取り消す仕組みを持たせておけば、報酬は常に確定した注文だけに紐付く。

報酬の重複や払い過ぎはどう防ぐのか

報酬の重複や払い過ぎはどう防ぐのか

報酬の集計は、二重計上と払い過ぎをいかに防ぐかが肝になる。

同じ注文に報酬が2回付いたり、返品後も報酬が残っていたりすると、紹介者への信頼を失う。

二重計上を防ぐ設計

私たちは、プログラムとデータベースの二段構えで二重計上を防いでいる。

同じ注文に対して報酬が1件しか作られないようデータベース側で制約をかけ、プログラム側でも重複を検知する。

これにより、手作業で照合する必要が無くなる。

不自然な報酬を検知する監視

不自然に多い報酬や重複した支払いを定期的に検知する監視も組み込む。

紹介制度は長く動かすほど、予期しないパターンが出てくる。

監視があると、異常を早期に見つけて止められる。

依頼する前に整理しておくこと

依頼する前に整理しておくこと

独自の紹介制度を外注するときには、どこまでを任せて、どこからを自分たちで行うかを先に分けておくと進めやすい。

私たちは技術面を担当し、紹介者への実際の報酬支払いや紹介者とのやり取りは運営者自身が行う。

報酬支払いと法律面の分担

紹介者への実際の報酬支払い、振込手続き、問い合わせ対応は運営者自身が行う。

報酬設計に関わる法律面の確認は専門家に依頼し、私たちは技術面を担当する。

法律の解釈や税務の判断は、私たちのような開発会社ではなく専門家の領域である。

私たちが担当する範囲

私たちは、紹介URLの発行から報酬の確定までをあなたのサイトに組み込む。

仕組みの提供までが範囲で、紹介者とのやり取りや実際の支払いは含まれない。

設計だけで終えるのではなく、私たちが運営している多言語SaaSで動かしている仕組みをもとに、二重計上を防ぐ監視まで実装する。

よくある質問

紹介者への報酬支払いは誰が行うのか

報酬の支払いは、サイトやサービスの運営者自身が行う。

私たちが提供するのは、誰にいくら支払うべきかを自動で集計する仕組みまでである。

既存の販売サイトに後から組み込めるのか

組み込める。

現在動いている販売の仕組みに合わせて、紹介URLの発行と成果の記録を追加する。

まずは現在の構成を教えてほしい。

月額課金の商品でも紹介報酬を毎月発生させられるのか

対応できる。

月額サービスの支払いが続く限り、紹介者へ報酬が毎月発生する形にできる。

一度きりの購入にしか対応しない仕組みとは異なる。

報酬の法律的な確認はどこに頼むのか

報酬設計に関わる法律面の確認は、弁護士や税理士などの専門家に依頼する。

私たちは技術面を担当し、法律の解釈や税務の判断は行わない。

この記事のポイント

  • アフィリエイト成果を自動集計するシステムは、紹介URLの発行から報酬の確定までを一続きで処理する
  • 紹介者ごとの成約件数と報酬額が自動で記録され、本人が専用ページで確認できる
  • 返品やキャンセル時は報酬を自動で取り消し、確定した注文だけに報酬を紐付ける
  • 二重計上や払い過ぎを防ぐため、プログラムとデータベースの二段構えと監視を組み込む
  • 報酬支払いと法律面は運営者と専門家が担当し、技術面を私たちが担当する
独自アフィリエイト機能の実装購入者やご登録者が自然に紹介者へ変わり、紹介から生まれた成果と報酬を自動で積み上げる機能を自社サイトに組み込むサービスサービスの詳細を見る
WooCommerce 11.2.1リリース。住所フィールドと郵便番号の不具合を修正

WooCommerce 11.2.1リリース。住所フィールドと郵便番号の不具合を修正

WooCommerce 11.2.1が2026年10月9日にリリースされた。今回のドットリリースは、11.2.0で発生した2件のチェックアウト関連バグを修正する内容だ。

住所フィールドを削除したストアで発生するエラーと、アルゼンチンなど特定の国で郵便番号が拒否される問題が対象になる。セキュリティ更新とデータベース更新は含まれない。

記事を読めば、修正された2つのバグの内容と、アップデート前に確認すべきポイントがわかる。

WooCommerce 11.2.1の概要

WooCommerce 11.2.1の概要

WooCommerceはWordPressでECサイトを構築する無料プラグインだ。今回の11.2.1は「ドットリリース」と呼ばれる、バグ修正に限定された小規模な更新になる。新機能の追加はなく、11.2.0で見つかった不具合を修正するためにリリースされた。

修正対象は2件ある。1件目はクラシックチェックアウトで住所フィールドを削除したストアに発生するブロックエラーで、2件目はチェックアウトブロックでアルゼンチンなどの郵便番号が拒否される問題だ。

WooCommerceのチェックアウトには大きく分けて2つの方式がある。1つはショートコードで表示する「クラシックチェックアウト」、もう1つはGutenbergブロックエディタで構築された「チェックアウトブロック」だ。今回の修正は両方を1つずつカバーしている。

WooCommerce 11.2.1の修正対象
修正1 クラシックチェックアウトの住所フィールド削除問題
修正2 チェックアウトブロックの郵便番号バリデーション
セキュリティ更新は含まれない。データベース更新も含まれない。

このデモは、11.2.1で修正された2つの不具合と、セキュリティ更新やデータベース更新が含まれないことを示している。

クラシックチェックアウトの住所フィールド修正

クラシックチェックアウトの住所フィールド修正

クラシックチェックアウトは、ショートコード [woocommerce_checkout] で表示される従来型のチェックアウト画面だ。WooCommerceの初期から提供されている方式で、現在も多くのストアで使われている。

住所フィールドとは、請求先住所や配送先住所の入力欄のことだ。多くのストアでは必須項目だが、デジタル商品のみを販売するストアなどでは不要な場合がある。そうしたストアは、woocommerce_billing_fields または woocommerce_default_address_fields というフィルターを使って住所フィールドを削除するカスタマイズを行う。

フィルターとは、WordPressやWooCommerceの動作をサイト独自に変更するための仕組みだ。テーマのfunctions.phpやカスタムプラグインにコードを追加して使う。住所フィールドを削除するカスタマイズは、決して珍しいものではない。

11.2.0では、注文サマリーが更新される際の住所データ送信に問題があった。住所フィールドを削除したストアで、以下のような不具合が発生する可能性があった。

  • 「続行するには住所を入力してください」というエラーでチェックアウトがブロックされる
  • 税金が正しく計算されない
  • 配送方法の選択肢が表示されなくなる

11.2.1では、11.1の動作に戻す修正が入った。注文サマリーのリフレッシュ時に、住所データが正しく送信されるようになる。住所フィールドを削除するカスタマイズを利用しているストアは、このバージョンで問題が解消される。

11.2.0(住所フィールド削除時)
⚠ チェックアウトエラーが発生
「続行するには住所を入力してください」
税金が計算されない、配送方法が消える
↓
11.2.1(住所フィールド削除時)
✓ チェックアウトが正常に進む
エラーメッセージは表示されない
税金・配送方法も正しく表示される

住所フィールドを削除したストアでは、11.2.0のエラーが11.2.1で解消される。

チェックアウトブロックの郵便番号バリデーション修正

チェックアウトブロックの郵便番号バリデーション修正

チェックアウトブロックは、ブロックエディタで構築された新しいチェックアウトフローだ。カートブロックやチェックアウトブロックなど、複数のブロックを組み合わせて柔軟にレイアウトを変更できる。

バリデーションとは、入力された値が正しい形式かどうかを検証する仕組みだ。たとえば郵便番号の入力欄に「123」など桁数の少ない値を入力するとエラーになるのは、バリデーションが働いているからだ。今回の問題は、この検証が厳しくなりすぎたことによって発生した。

11.2.0では、アルゼンチンの郵便番号で州文字なしの形式(例 1213)が拒否されるようになった。さらに、エルサルバドル、セントビンセントおよびグレナディーン諸島、イギリス領ヴァージン諸島の郵便番号フォーマットも拒否されていた。

11.2.1では、アルゼンチンの州文字なし郵便番号を再び受け入れ、上記3カ国のフォーマットにも対応する。該当する国への配送を行っているストアは、チェックアウトブロックでエラーが解消される。

11.2.0(チェックアウトブロック)
✗ アルゼンチン「1213」は拒否される
州文字なしの郵便番号はエラーになる
↓
11.2.1(チェックアウトブロック)
✓ アルゼンチン「1213」を受け入れる
州文字なしの形式を再サポート

11.2.1では、アルゼンチンの州文字なし郵便番号が再び有効になる。

アップデート前の確認ポイント

アップデート前の確認ポイント

今回の修正はバグ修正に限定されているため、更新によるリスクは比較的低い。ただし、チェックアウトは売上に直結する機能だ。更新前には以下のポイントを確認しておきたい。

  • 住所フィールドを削除するカスタマイズを使っているか
  • チェックアウトブロックを利用しており、対象国に配送しているか
  • ステージング環境で実際のチェックアウトフローをテストしたか
  • 更新前にバックアップを取得しているか

特に住所フィールドを削除するカスタマイズを使っているストアは、11.2.0をスキップして11.2.1に直接更新することをおすすめする。11.2.0に更新してしまった場合は、できるだけ早く11.2.1への更新が望ましい。

この記事のポイント

  • WooCommerce 11.2.1は2026年10月9日にリリースされたドットリリース
  • クラシックチェックアウトで住所フィールドを削除したストアのエラーを修正
  • チェックアウトブロックでアルゼンチンなどの郵便番号バリデーションを修正
  • セキュリティ更新とデータベース更新は含まれない
  • 住所フィールド削除カスタマイズ利用中のストアは更新推奨
WooCommerce 11.2が登場、商品CSVのUPC照合と決済日付入力を追加

WooCommerce 11.2が登場、商品CSVのUPC照合と決済日付入力を追加

WooCommerce 11.2が2026年10月8日にリリースされた。今回のアップデートでは商品CSVインポートの照合方法が拡張され、サプライヤーから届いたUPCだけの価格表をそのまま取り込めるようになった。ほかにもチェックアウトでの日付入力、注文撤回メールの設定、カタログ画面のパフォーマンス改善が含まれる。

ECサイトを運営する担当者にとって、日々の商品管理と受注業務に直結する変更が中心だ。特に商品コードを使った一括更新は、数千点規模の在庫を扱う店舗で作業時間を大きく短縮できる。本記事ではWooCommerce 11.2の主要な変更点と、アップデート前に確認しておきたい注意事項をまとめる。

WooCommerce 11.2の主な変更点

WooCommerce 11.2の主な変更点

WooCommerce 11.2はWordPressのECプラグインとして広く利用されているWooCommerceのマイナーアップデートだ。公式ブログでは変更点を6つの項目に分けて紹介している。いずれも店舗運営の効率化に寄与する内容で、商品管理から顧客体験の改善まで幅広い。

WooCommerce 11.2の変更点マップ
商品管理 CSVインポートがUPC・GTINなどで照合できる
チェックアウト 注文時に日付入力欄を追加できる
メール設定 注文撤回メールを管理画面で設定できる
パフォーマンス カタログ画面とレポート集計が高速化
ブロック機能 商品フィルターがスティッキー表示に対応
注意点 一部メールのCC・BCC配信が停止される

上記のほか、セキュリティ改善とデータベース更新も含まれる。更新前にバックアップを取得しておくことが推奨される。

商品CSVインポートがUPC・GTINなどのコードに対応

商品CSVインポートがUPC・GTINなどのコードに対応

商品コードとは

UPC(Universal Product Code)は主に米国で使われるバーコード規格で、商品パッケージに印刷された12桁の数字を指す。GTIN(Global Trade Item Number)は国際標準の商品識別コード、EAN(European Article Number)は欧州で広く使われるバーコード、ISBNは書籍の識別コードだ。いずれも商品を一意に特定するための番号で、サプライヤーから届く価格表にはこれらのコードだけが記載されていることが多い。

インポート時の照合の流れ

WooCommerceの商品CSVインポート機能では、これまで各行を商品IDまたはSKUで照合して既存商品を更新していた。11.2では照合の優先順位が拡張され、ID、SKU、GTIN、UPC、EAN、ISBNの順に一致する商品を探す。サプライヤーからUPCだけの価格表を受け取った場合でも、そのままCSVファイルとしてアップロードできるようになった。

CSVインポートの照合順序
STEP 1 商品IDで照合
↓
STEP 2 SKUで照合
↓
STEP 3 GTIN・UPC・EAN・ISBNで照合
照合は上から順に行われ、最初に一致したコードが使われる

利用するにはインポート画面で「既存の商品を更新」を有効にする必要がある。同一商品にSKUとUPCの両方が登録されている場合はSKUが優先される仕組みだ。

チェックアウトで日付入力を追加できる

チェックアウトで日付入力を追加できる

日付フィールドの用途

チェックアウトブロックを使用している店舗では、注文手続き中に顧客へ日付を尋ねられるようになった。配達希望日や誕生日など、商品の性質に合わせて自由に用途を決められる。顧客はスマートフォンやブラウザ標準の日付ピッカーを使って日付を選択する。店舗側は選択できる日付の範囲も制限できる。

設定方法

この日付フィールドを追加するには、チェックアウトブロックの設定にショートコードスニペットを追加する。テーマのfunctions.phpやコード管理プラグインに数行のコードを貼り付けるだけで有効化できる。コードの詳細は公式のリリースノートに記載されている。

チェックアウト画面の変化
従来のチェックアウト(Before)
お名前
入力欄
配送先住所
入力欄
↓
改善後のチェックアウト(After)
お名前
入力欄
配送先住所
入力欄
配達希望日
日付を選択

この例では配達希望日を追加しているが、誕生日や引き取り希望日など、店舗の運用に合わせて自由にラベルを変更できる。

注文撤回メールを管理可能に

注文撤回メールを管理可能に

EU圏の顧客に販売している店舗向けの変更も入った。注文撤回(キャンセル要求)が発生したときに送信される2種類のメールを、管理画面から設定できるようになった。1つは顧客が受け取る確認メール、もう1つは店舗側に届く通知メールだ。

WooCommerceの設定画面にある「メール」セクションで、それぞれのメールに独自のメッセージを追加できる。プレビューで内容を確認し、通知を受け取る担当者を選び、必要なければメール自体を無効化することも可能だ。これまではコードでしか変更できなかった設定が、管理画面だけで完結するようになった。

パフォーマンス改善とブロックの新スタイル

パフォーマンス改善とブロックの新スタイル

カタログと管理画面の高速化

商品数が5点でも5万点でも、カタログ画面で商品を自由に並べ替えられるようになった。可変商品(サイズや色などのバリエーションを持つ商品)を含む店舗では、商品ページの読み込みとチェックアウト処理が高速化している。レポート集計ではデータベースへのクエリ数が減り、顧客数が増えてもメモリ使用量が増加しにくくなった。

レポート集計のパフォーマンス
従来(Before)
データベースクエリ数が多い
顧客数に比例してメモリ使用量が増加
↓
WooCommerce 11.2(After)
クエリ数を削減
メモリ使用量が顧客数に依存しない

大量の顧客データを持つ店舗ほど、この改善による管理画面の体感速度は大きく変わる。レポート表示が遅くて開くのを待っていた店舗は、更新後に改善を実感しやすい。

商品フィルターブロックのスティッキー表示

商品フィルターブロックにスティッキー(追従)表示のオプションが追加された。長いカテゴリーページを顧客が下へスクロールしても、フィルター条件が画面上部に表示され続ける。絞り込みのたびにページ先頭まで戻る手間がなくなる。

ほかにも数量セレクター(カート内のものを含む)は枠線、影、色、角丸を設定できる。商品画像には枠線、フィルターチップにはフォントと余白のコントロールと角丸が追加された。これらのスタイルは外観 > エディター > スタイル > ブロックの画面で店舗全体に一括設定するか、ブロック単位で個別に調整する。

アップデート前に知っておくべき注意点

アップデート前に知っておくべき注意点

既存メール設定への影響

パスワードリセット、新規アカウント作成、メール確認の各メールについて、自分自身をCCまたはBCCでコピー受信していた場合、その配信が停止される。これらのメールにはログインリンクが含まれるため、本人以外には送られないようにするセキュリティ上の変更だ。

ダウンロードリンクと権限の変更

標準のダウンロードリンクは従来どおり動作する。ただし、まれにカスタム登録やインポートで不正なデータを持つリンクは動作しなくなる可能性がある。顧客から報告があれば、注文画面からリンクを再発行すればよい。

ショップマネージャー(店舗運営者)が、フォーラム権限や会員権限など特定の追加権限を持つユーザーを編集できなくなる。そのようなユーザーの編集はWordPress管理者が行うことになる。

アップデート手順の注意

WooCommerce 11.2にはセキュリティ改善とデータベース更新が含まれるため、運営中のすべての店舗でアップデートを適用することが推奨される。データベース更新が走るので、事前のバックアップが必須だ。

この記事のポイント

  • WooCommerce 11.2は2026年10月8日にリリースされた
  • 商品CSVインポートがUPC・GTIN・EAN・ISBNでの照合に対応した
  • チェックアウトブロックに日付入力欄を追加できる
  • 注文撤回メールの管理画面設定が可能になった
  • パフォーマンス改善とセキュリティ更新を含むためバックアップしてアップデートを
WooCommerce 11.6でPHP 8.1必須化。11.3から警告表示、11.5まで利用可能

WooCommerce 11.6でPHP 8.1必須化。11.3から警告表示、11.5まで利用可能

WooCommerce 11.6が2027年2月にリリース予定で、このバージョンからPHP 8.1以上が必須要件になる。PHP 7.4または8.0で動かしているストアは、それまでに移行準備を進める必要がある。

移行期間を確保するため、WooCommerce 11.3では管理画面に警告通知が追加される。通知は現在のPHPバージョンとホスティング事業者への相談を促す内容で、閉じることもできる。11.5までは従来のPHP環境でも更新を継続できる仕組みだ。

WooCommerceが公開した利用統計によれば、追跡対象ストアの約7%がPHP 7.4、約2%がPHP 8.0で稼働している。この記事では移行の背景、通知の内容、具体的な手順、影響範囲を整理する。

PHP 8.1必須化の背景にある3つの理由

PHP 8.1必須化の背景にある3つの理由

セキュリティサポートの終了

PHP 7.4と8.0は、PHP公式のセキュリティサポートがすでに終了している。サポートが切れたバージョンでサイトを運営し続けると、新しい脆弱性が発見されても修正パッチが提供されない。WooCommerce側でパッチを出しても、PHPランタイム自体のリスクは残る。

依存関係の更新とコードパスの削減

PHP 7.4と8.0に対応し続けるには、古い依存パッケージを固定し、バージョンごとの分岐コードを維持する必要がある。PHP 8.1を最低ラインにすることで、開発者とエクステンション製作者は新しいPHP機能を使え、テスト対象の環境も減らせる。WooCommerceはすでにPHP 8以上での動作を長年サポートしてきた実績がある。

今回の変更は、最低ラインを引き上げて将来のリリースの土台を作るものだ。コミュニティからのフィードバックを受けて、対象リリースをWooCommerce 11.6に設定した。繁忙期の後に十分なテストとアップグレードの時間を確保できるよう配慮されている。

従来の最低要件(Before)
PHP 7.4 PHP 8.0
セキュリティサポートが終了したバージョンでも動作。ただし新たな脆弱性が発見されてもパッチが提供されない。
↓
WooCommerce 11.6の最低要件(After)
PHP 8.1以上 推奨はPHP 8.3以上
新しいPHP機能を利用でき、依存パッケージの更新も進めやすくなる。テスト対象の環境も削減できる。
※ PHP 8.1で最低要件を満たすが、WooCommerceの現在の推奨はPHP 8.3以上

デモで示したように、最低要件の引き上げは単なる制限強化ではなく、開発基盤を健全化するための措置だ。PHP 8.1以降には型システムの改善やJITコンパイラの成熟など、パフォーマンスと保守性の面で有利な機能が揃っている。

WooCommerce 11.3で表示される警告通知

WooCommerce 11.3で表示される警告通知

WooCommerce 11.3から追加される通知は、PHP 7.4または8.0で稼働するストアの管理画面にのみ表示される。現在のPHPバージョンを表示し、ホスティング事業者にアップグレードを相談するよう案内する。通知は閉じられる仕組みで、11.3の利用自体は従来のPHPでも継続できる。

通知の役割はあくまで予告だ。実際に最低要件が変わるのはWooCommerce 11.6がリリースされたタイミングになる。それまでは通常どおり11.3、11.4、11.5へと更新を続けられる。

WooCommerce 11.3 管理画面の警告通知イメージ
⚠️ PHPバージョンの更新が必要です
このストアはPHP 7.4で動作しています。WooCommerce 11.6からPHP 8.1以上が必須になります。ホスティング事業者にPHP 8.3以上へのアップグレードを相談してください。
閉じる ※ 閉じてもストアの動作には影響しない
■ 通知はPHP 7.4または8.0の環境のみに表示 ■ 11.5までは従来のPHPでも更新可能

通知を閉じた後でPHPバージョンを確認したい場合は、管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認すればよい。ホスティング環境が更新済みなら、WooCommerceの推奨はPHP 8.3以上だ。

通知を確認した後の移行手順

通知を確認した後の移行手順

通知が表示されたストアは、以下の手順でPHPアップグレードを進める。焦らず、ステージング検証を挟むのが安全だ。

PHPバージョンの確認

管理画面の「WooCommerce」→「ステータス」を開き、「サーバー環境」にある「PHPバージョン」を確認する。PHP 7.4または8.0が表示された場合は、移行の対象になる。WooCommerceのPHPアップデートガイドも参考になる。

ステージング環境での検証

バックアップを取得し、ステージング環境でPHP 8.3以上に切り替える。決済と支払い方法、配送計算、税計算、注文管理、スケジュールジョブ、テーマ、拡張機能、カスタムコードを一通り検証する。互換性の問題があれば、本番を変更する前に解決する。

本番環境の切り替えと確認

ステージングで問題がなければ本番を切り替え、再度「WooCommerce」→「ステータス」と重要フローを確認する。その後、WooCommerce 11.6への更新が可能になる。

STEP 1 WooCommerceのステータス画面でPHPバージョンを確認
↓
STEP 2 バックアップを取得し、ステージング環境でPHP 8.3以上に切り替え
↓
STEP 3 決済・配送・税計算・注文管理・拡張機能を一通り検証
↓
STEP 4 本番環境を切り替え、重要フローを再確認してからWooCommerce 11.6へ更新
■ 青=確認 ■ 緑=準備 ■ 橙=検証 ■ 紫=切り替え

ステージング検証は省略しがちだが、決済や配送計算の不具合は売上に直結する。特に拡張機能やカスタムコードを多用するストアでは、本番前に必ず検証したい。

アップグレードが間に合わない場合の選択肢

アップグレードが間に合わない場合の選択肢

WooCommerce 11.5はPHP 7.4と8.0に対応する最後のリリースになる予定だ。ホスティングや拡張機能の制約で移行が遅れる場合は、11.5に留まって作業を進められる。WordPressはPHP要件を満たさないプラグインの更新を通常ブロックするため、11.6への更新はサーバー側のPHPバージョンが8.1以上になるまで制限される。

11.5に留まるのは一時的な選択肢だ。WooCommerceのセキュリティパッチサポートポリシーでは、CVSS 9以上の重大な脆弱性の修正は、直近21メジャーリリースシリーズにバックポートされる。しかしそれ以外の修正は最新版にしか提供されない。加えてPHP 7.4と8.0自体のセキュリティサポートも終了しているため、WooCommerceのパッチだけではランタイムのリスクを解消できない。

WooCommerceバージョンとPHP要件の対応
11.3〜11.5 PHP 7.4 / 8.0 でも利用可能(通知は表示される)
11.5まで PHP 7.4 / 8.0 で更新できる最後のリリース
11.6以降 PHP 8.1以上が必須。PHP 7.4 / 8.0では更新できない
⚠️ 11.5に留まる場合の注意点
CVSS 9以上の重大な脆弱性のみ直近21メジャーリリースにバックポートされる。それ以外の修正は最新版のみ。PHP 7.4 / 8.0自体のセキュリティサポートも終了しているため、リスクは残る。
■ 青=移行期間 ■ 橙=最終ライン ■ 赤=必須要件

移行が遅れる理由として、特定の拡張機能がPHP 8.1以上に対応していないケースがある。その場合は拡張機能開発者に互換性の状況を確認し、代替手段を検討するのが現実的な対応だ。

ストアと拡張機能への影響範囲

ストアと拡張機能への影響範囲

利用統計から見る影響

WooCommerceが公開した統計によると、追跡対象ストアの約7%がPHP 7.4、約2%がPHP 8.0で稼働している。直近1年間にWooCommerceを更新したストアに限ると合計約6%で、この数値は継続的に減少している。実際に要件が変わる2027年2月にはさらに低くなると見られる。使用状況の追跡はオプトイン方式のため、この数値はサンプルであり全ストアの正確なカウントではない。

拡張機能マーケットの静的解析

WooCommerceは全拡張機能マーケットプレイスを対象にPHP 8.1互換性の静的解析を実施した。購入可能な1,357個の拡張機能のうち、0.22%に潜在的な問題が見つかり、開発者と手動で確認中だ。ただしこのスクリーニングはすべての拡張機能、テーマ、カスタム統合の動作を保証するものではない。各ストアは自分の環境でテストする必要がある。

拡張機能開発者と制作会社向けには、WooCommerce 11.6が使うPHP 8.1と推奨PHPバージョンの両方でテストするよう案内がある。互換性の問題を見つけた場合は、PHPとWooCommerceのバージョン、影響する拡張機能、再現手順をGitHubのイシューかコメントで共有することが推奨されている。

拡張機能マーケットのPHP 8.1互換性スキャン結果
99.78% 問題なし 0.22% 要確認
1,357個の拡張機能を静的解析。問題が見つかったものは開発者と手動で確認中。ただしスクリーニングは動作保証ではない。
ストアのPHPバージョン分布(追跡対象サンプル)
PHP 8以上 約91% PHP 7.4 約7% PHP 8.0 約2%
直近1年間に更新したストアでは合計約6%で継続的に減少。実際の要件変更時にはさらに低くなる見込み。
■ 緑=安全 ■ 青=PHP 8以上 ■ 橙=要移行 ■ 赤=要確認・要移行

影響範囲は限定的だが、該当するストアにとっては計画的な移行が欠かせない。PHPアップグレードは早めに着手し、繁忙期に入る前に完了しておくのが安全だ。

この記事のポイント

  • WooCommerce 11.6からPHP 8.1以上が必須になり、11.3で警告通知が追加される
  • PHP 7.4と8.0は公式セキュリティサポートが終了しており、移行は不可避だ
  • 11.5までは従来のPHP環境で更新可能だが、あくまで一時的な選択肢だ
  • 移行前にはバックアップとステージング検証を必ず実施する
  • PHP 8.3以上への更新がWooCommerceの現在の推奨だ
WooCommerce 11.1.2リリース!商品ギャラリーの無限再帰とメールレビュー検証を修正

WooCommerce 11.1.2リリース!商品ギャラリーの無限再帰とメールレビュー検証を修正

WooCommerce 11.1.2が2026年9月22日にリリースされた。商品バリエーションギャラリーで発生する無限再帰の修正と、メール経由の商品レビューにおける入力検証の強化が含まれるドットリリースだ。

今回の更新はセキュリティ更新に該当する。データベースの更新は不要で、適用のハードルは低い。ECサイト運営者は早めのアップデートを検討したい。

WooCommerce 11.1.2のリリース概要

WooCommerce 11.1.2のリリース概要

WooCommerceのドットリリースとは、メジャーバージョンやマイナーバージョンの間に挟まれる小規模な修正更新のことだ。新機能の追加はなく、既知の不具合修正とセキュリティ強化に絞られる。

今回の11.1.2は、2026年9月22日に公開された。公式のリリースノートによると、セキュリティ更新に該当し、データベース更新は不要とされている。つまり、プラグインの更新ボタンを押すだけで適用が完了する。

修正内容は2つに絞られている。1つ目は商品バリエーションギャラリーにおける無限再帰の防止、2つ目はメールベースの商品レビューにおける検証の厳格化だ。どちらもECサイトの安定稼働に直結する内容である。

商品バリエーションギャラリーの無限再帰を修正

商品バリエーションギャラリーの無限再帰を修正

1つ目の修正は、テーマがテンプレートファイル内で get_available_variations 関数を呼び出した際に無限再帰が発生する問題への対処だ。GitHubのプルリクエスト番号68939で修正されている。

無限再帰とは何か

無限再帰とは、関数が終了条件なしに自分自身を呼び出し続ける状態を指す。プログラミングの世界では「スタックオーバーフロー」と呼ばれるエラーにつながる。たとえるなら、合わせ鏡の間に立ったときに像が無限に反射して見えるのに似ている。どこかで止める仕組みがなければ、コンピュータのリソースを使い果たしてしまう。

WooCommerceの商品バリエーションギャラリーでは、テーマが独自に get_available_variations を呼び出すケースが問題になった。テーマのテンプレートファイルにこの関数の呼び出しが含まれていると、内部のフックが再帰的に呼び出されてスタックが溢れ、商品ページ全体が白画面になったり応答しなくなったりする。

修正の内容と影響範囲

修正後は、テーマが get_available_variations をテンプレートファイルで呼び出しても、再帰的な呼び出しが防止される。バリエーションごとの画像ギャラリーが正常に表示され、商品ページが通常どおり動作するようになる。

影響を受けるのは、バリエーション商品を持つECサイトで、なおかつテーマがこの関数を直接呼び出している場合に限られる。標準のWooCommerceテーマや多くの人気テーマでは問題は発生しない。しかし、独自にカスタマイズしたテーマを使っている場合は注意が必要だ。

修正前(Before)
⚠ ページが応答しない
テーマが get_available_variations をテンプレート内で呼び出すと、内部フックが再帰的に実行されてスタックが溢れる。商品ページ全体が白画面になり、購入フローが停止する。
↓
修正後(After)
✅ ギャラリーが正常に表示
再帰的な呼び出しが防止され、バリエーション画像の一覧が正しく表示される。商品ページが通常どおり動作し、購入フローに支障が出ない。
■ 赤枠は修正前の問題状態 ■ 緑枠は修正後の正常状態を示す

上図のとおり、修正前は get_available_variations の再帰呼び出しにより商品ページ全体が停止する可能性があった。修正後はこの再帰が防止され、ギャラリーが正しく表示される。独自テーマを運用している場合は、この修正の適用前にステージング環境で動作確認することを推奨する。

メールレビューの検証を強化

メールレビューの検証を強化

2つ目の修正は、メール経由で投稿される商品レビューの入力検証を厳格化するものだ。GitHubのプルリクエスト番号68961で対応された。セキュリティ更新とされる理由はこの修正にある。

メールベースのレビュー機能とは

WooCommerceには、購入者からのレビューをメールで受け付ける仕組みがある。顧客が注文後に届くメール内のリンクからレビューを投稿できる機能だ。ECサイトにとってレビューは信頼構築の要であり、この導線はコンバージョン率にも影響する。

問題は、このメール経由の投稿経路において入力値の検証が十分でなかった点だ。悪意のある第三者が不正なデータを送信する余地があり、セキュリティリスクになり得た。今回の修正では、この検証処理が厳格化されている。

検証強化がもたらす効果

検証の厳格化により、不正な入力や改ざんされたデータがレビューとして投稿されるリスクが低減される。レビューの信頼性が保たれ、ECサイトの評判管理にも好影響を与える。

店舗運営者の目線では、この変更によってレビュー投稿のフローに大きな変化はない。顧客が正規のメールリンクからアクセスする限り、従来どおりの手順でレビューを投稿できる。内部のバリデーションが強化されただけなので、ユーザビリティへの影響はない。

STEP 1 顧客が注文後のメールからレビューフォームを開く
↓
STEP 2 WooCommerceがレビューデータを受信
↓
STEP 3 入力値の検証を実行(今回強化された箇所)
↓
STEP 4 検証を通過したレビューが公開される
■ オレンジ色のSTEP 3が今回の修正で強化された検証処理を指す

上図のとおり、メール経由のレビュー投稿は4段階で処理される。今回の修正はSTEP 3の検証処理に焦点を当てており、不正なデータの流入を防ぐ役割を担う。顧客側の操作フローに変更はない。

ECサイト運営者が取るべき対応

ECサイト運営者が取るべき対応

この更新はセキュリティ更新のため、基本的には即時適用が望ましい。ただし、独自テーマやカスタムコードを使っているサイトでは、事前の動作確認を怠らないことが重要だ。

更新前の準備

更新の前に、サイト全体のバックアップを取得する。WooCommerceを運用するECサイトでは、商品データ、注文履歴、顧客情報が失われると事業に直結する。更新作業の前には必ずデータベースとファイルの両方をバックアップしておく。

また、ステージング環境が利用できるのであれば、本番環境に適用する前に更新後の動作を確認する。特にバリエーション商品を持つ場合は、商品ページでギャラリーが正しく表示されるかをチェックしたい。

更新手順の目安

WooCommerceの更新はWordPressの管理画面から行える。プラグイン一覧からWooCommerceを選択し、更新を実行するだけだ。データベース更新が不要なため、更新後のマイグレーション処理も発生しない。

更新後は、商品ページ、カート、チェックアウト、レビュー投稿の各フローが正常に動作するかを確認する。特にメールレビュー機能を有効にしている場合は、テスト用のレビューを1件投稿して検証すると安心だ。

この記事のポイント

  • WooCommerce 11.1.2は2026年9月22日に公開されたセキュリティ更新で、データベース更新は不要
  • 商品バリエーションギャラリーの無限再帰を修正し、独自テーマ利用時の白画面リスクを解消
  • メール経由の商品レビューにおける入力検証を強化し、不正データの投稿リスクを低減
  • 独自テーマやカスタムコードを運用中のサイトは、ステージング環境での事前確認を推奨
WooCommerce公式ブロックテーマPurpleがベータテスト開始。テスト方法と注目機能

WooCommerce公式ブロックテーマPurpleがベータテスト開始。テスト方法と注目機能

WooCommerce初の公式ブロックテーマ「Purple」がベータテストを開始した。GitHubからダウンロードできる状態で、正式版はWordPressテーマディレクトリとWooCommerceマーケットプレイスで配布される予定だ。

PurpleはECサイト向けに作られたスターターテーマで、テンプレート一式、10種類のカラーパレット、10種類のフォント組み合わせ、EC向けパターンライブラリを備える。ブロックテーマのため、従来のクラシックテーマより軽量で柔軟なカスタマイズが可能だ。

この記事ではPurpleの特徴、WooCommerceコアに加わったブロック改善、テスト手順を解説する。ストア運営者や制作会社がベータテストに参加する際の参考にしてほしい。

Purpleテーマとは何か

Purpleテーマとは何か

PurpleはWooCommerceチームが開発したオープンソースのスターターテーマだ。ブロック対応のWooCommerceページ用テンプレートをほぼ網羅しており、WooCommerceとWordPressコアブロックのカスタムスタイルも含む。ストアを立ち上げる事業者が、モダンで高速な土台として使える設計になっている。

ブロックテーマとは、WordPressのブロックエディタだけでサイトの見た目やレイアウトを編集できるテーマ形式のことだ。従来のテーマはPHPテンプレートとCSSが中心だったが、ブロックテーマはブロックの組み合わせでページを構成する。エディタ上で完結するため、コードを書かずにデザインを変更できるのが特徴だ。

Purpleには商品グリッド、フィルター、コレクション、CTA、商品詳細ページなどを含むEC特化のパターンライブラリも同梱されている。パターンとは、あらかじめ組み立てられたブロックのセットで、ワンクリックでページに挿入できる部品のことだ。

Purpleテーマに含まれる主な要素
テンプレートブロック対応のWooCommerceページ用テンプレート一式
カラーパレット10種類の配色プリセット
フォント10種類のフォント組み合わせ
パターン商品グリッド、フィルター、コレクション、CTA、商品詳細ページなど

このデモはPurpleテーマの中核となる4つの要素を示している。開発者や制作会社はこれらのテンプレートとスタイルを拡張し、独自のストアデザインの出発点として使える。

Storefrontとの違い

WooCommerceの従来の代表テーマであるStorefrontと比較すると、Purpleの違いが分かりやすい。Storefrontはクラシックテーマで、商品ヒーローデザイン、カスタムホームページ、商品ギャラリー、ミニカート、高度なヘッダーやフッターを実現するには拡張機能が必要だった。

一方、ブロックテーマではWooCommerceのブロックライブラリとブロックエディタだけで、これらのカスタマイズを実現できる。拡張機能に依存せず、テーマとコア機能だけでストアを構築できるのがPurpleの大きな利点だ。

WooCommerceコアに加わったブロック改善

WooCommerceコアに加わったブロック改善

Purpleプロジェクトの価値はテーマそのものだけではない。開発の過程で、WooCommerceコアに多数のブロック改善が加わった。この改善はPurpleに限らず、影響を受けるブロックやAPIを使うすべてのブロックテーマで利用できる。

バージョン11.0の基盤整備

WooCommerce 11.0では、ブロックテーマを軽量かつ一貫性のあるものにするための基盤が整えられた。まず、パターンコンテンツの読み込みが必要になった時だけ行われるようになった。これにより、パターンを必要としないリクエストでの無駄な処理が減る。

商品画像まわりも改善された。Product Imageブロックはより大きなサムネイルを使い、トリミングされた画像でも正しいアスペクト比を保持する。商品カタログの見た目がテーマ設定と調和しやすくなった。

そのほか、Product CollectionブロックがQuery Loopの内側にネストされた際に正しいコンテキストを保持するようになり、複合テンプレートやパターン内で商品ブロックが正しく描画されるようになった。Breadcrumbsブロックはtheme.jsonによるスタイリングに対応し、Product Filtersブロックはフィルタードロワーを無効化するオプションを追加した。カートテーブルのヘッダーにはARIAロールが付与され、支援技術でのアクセシビリティも向上している。

バージョン11.1のレスポンシブ対応

WordPress 7.1がブロックエディタにレスポンシブデザインコントロールを導入したことを受け、WooCommerce 11.1では主要なブロックがこのコントロールに対応した。Product Priceはタイポグラフィ、色、パディング、マージンのレスポンシブスタイリングに対応し、Product Reviewsも画面幅ごとのスタイルを反映できるようになった。

Product Detailsはパディング、マージン、背景、ボーダーをブロックとグローバルスタイルの両方から設定できる。Product Galleryはカスタムアスペクト比に対応し、大きな画像エリアとサムネイルレールの同期も改善された。

パフォーマンス面では、ブロック登録の改善が大きい。ブロックを描画できないリクエストではブロックとパターンの登録をスキップする仕組みが入り、公開された測定値ではStore APIとRESTリクエストが30〜42%高速化した。統合ブロックエディタアセットの実験的サポートも導入され、サイト編集中のネットワーク転送サイズは48.3%削減された。

従来のブロック登録(Before)
すべてのリクエストでブロックとパターンを登録
不要な処理が発生
↓
WooCommerce 11.1の改善後(After)
ブロックを描画できないリクエストでは登録をスキップ
Store APIとRESTリクエストが30〜42%高速化

このデモはブロック登録の最適化前後の違いを示している。不要な登録処理を省くことで、APIリクエストの応答時間が大幅に短縮された。

バージョン11.2の注目機能

WooCommerce 11.2は現在開発中だが、テーマ作業の成果が最も目に見える形で現れているバージョンだ。Product Filtersブロックはレスポンシブオーバーレイとスティッキー配置のコントロールを獲得した。インライン表示のままにするか、モバイルやタブレットでオーバーレイに切り替えるか、全画面幅でオーバーレイを使うかを選べる。WordPress 7.1の設定可能なレスポンシブブレークポイントにも対応する。

Product Quantityブロックはテキスト色、背景色、ボーダー半径、ボーダー、シャドウをブロックスタイルから設定できるようになった。グループ商品の数量コントロールも同じスタイリングモデルを使う。Product Imageブロックはテーマ定義のボーダーに対応し、商品グリッドやコレクションパターンにストアのビジュアルシステムを反映しやすくなった。

Chipsブロックもテーマ化が進んだ。商品フィルターや「カートに追加+オプション」で使われるChipsブロックにタイポグラフィとボーダー半径のコントロールが追加され、ストア全体と一貫したスタイルを適用できる。パターンのインサーターカテゴリ名は「WooCommerce」から「Shop」に変更され、パターンを探しやすくなった。

Purpleのテスト方法

Purpleのテスト方法

Purpleはベータ版のため、必ずステージング環境またはローカルサイトでテストしてほしい。本番環境でのテストは推奨されない。最新のWordPressとWooCommerceを使うことで、前述のレスポンシブコントロールを実際に試せる。

Purpleテーマのテスト手順
STEP 1ステージング環境またはローカルサイトを準備する
↓
STEP 2最新のWordPressとWooCommerceをインストールする
↓
STEP 3GitHubからPurpleをダウンロードしてテーマとしてインストールする
↓
STEP 4テーマを有効化して外観→エディタを開く
↓
STEP 5各テンプレートとブロックをテストする

この手順でテーマをインストールした後、フロントページ、ショップまたは商品カタログ、商品詳細、カート、チェックアウト、マイアカウント、検索の各テンプレートを確認する。特にProduct Filtersブロックはデスクトップ、タブレット、モバイルの3つの画面幅でテストし、インラインモードとオーバーレイモードの両方を試す。

商品ブロックについては、Product Price、Product Details、Product Reviews、Product Gallery、Product Quantity、Catalog Sorting、Mini-Cartを、シンプル商品、バリエーション商品、グループ商品の3種類でテストする。通常使っている拡張機能や子テーマのカスタマイズを追加して、エディタとフロントエンドの両方で再テストするのが望ましい。なお、GitHubから直接ダウンロードした場合、自動更新は受けられない。

フィードバックの送り方

フィードバックの送り方

問題を発見した場合や提案がある場合は、GitHubのWoo Themesリポジトリでissueを開く。その際、WordPress、WooCommerce、PHP、Purpleの各バージョン、テストしていたテンプレートまたはブロック、問題の再現手順を含める。視覚的な問題ならスクリーンショットや録画も添付する。

フィードバックはデフォルトのWooCommerceストアフロントの改善と、すべてのブロックテーマで利用できるブロックとテンプレートの改善に直結する。ベータテストへの参加は、WooCommerceのブロックエコシステム全体を育てる貢献になる。

この記事のポイント

  • PurpleはWooCommerce初の公式ブロックテーマで、ベータテストが始まった
  • テンプレート一式、10種類のカラーパレットとフォント組み合わせ、EC向けパターンライブラリを備える
  • WooCommerce 11.0から11.2にかけて、ブロック改善とパフォーマンス最適化がコアに加わった
  • テストはステージング環境またはローカルサイトで行い、各ブロックとテンプレートを確認する
  • フィードバックはGitHubのissueで受け付けている
WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説

WooCommerce 11.5でPHP 8.1以上が必須に。移行の影響と準備を解説

WooCommerce 11.5(2027年1月目標)から、最低動作環境がPHP 8.1以上になる提案が発表された。この変更が採用されると、PHP 7.4とPHP 8.0のサポートは将来のバージョンで終了する。

WooCommerceの利用データでは、PHP 7.4が追跡対象ストアの約7%、PHP 8.0が約2%を占めている。比較的新しいWooCommerceバージョンに限ると合計約6%まで下がり、減少傾向が続いている。

ストア運営者や拡張機能開発者は、移行の影響を早めに把握して準備を進める必要がある。本記事では提案の内容、影響範囲、推奨される対応をまとめた。

WooCommerce 11.5からPHP 8.1以上が最低要件に

WooCommerce 11.5からPHP 8.1以上が最低要件に
従来のWooCommerce(Before)
PHP 7.4 または PHP 8.0 で動作
WooCommerce 11.4 以前の最低要件
↓
WooCommerce 11.5以降(After)
PHP 8.1 以上が最低要件
PHP 7.4 と 8.0 のサポート終了

上の図のように、WooCommerce 11.5を境に最低PHPバージョンが引き上げられる。PHP 7.4と8.0を使うストアは、設定変更なしでは新しいバージョンへ更新できなくなる。

PHPサポート終了の現状

PHP 7.4は2022年11月に、PHP 8.0は2023年11月に公式サポートが終了している。以降はセキュリティ修正が提供されていないため、脆弱性が見つかっても修正されない状態が続く。

WooCommerceの内部データによると、追跡対象ストア全体ではPHP 7.4が約7%、PHP 8.0が約2%を占める。一方、直近1年以内にリリースされた比較的新しいWooCommerceバージョンでは合計約6%まで縮小している。

提案の具体的内容

WooCommerceエンジニアリングチームは、WooCommerce 11.5のリリースを目標に最低要件をPHP 8.1以上へ引き上げることを提案している。採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。

この変更により、WooCommerce 11.5以降はPHP 7.4と8.0向けの互換コードを削除できる。コードベースの保守性が高まり、開発スピードの向上につながると見込まれている。

PHPバージョン引き上げのメリット

PHPバージョン引き上げのメリット
最新構文 union types
match式
名前付き引数
セキュリティ EOL回避
安全な依存パッケージ
開発効率 CIテスト高速化
互換性コード削減
性能向上 PHP 8系の
ランタイム改善
■ 最新構文 ■ セキュリティ ■ 開発効率 ■ 性能向上

PHP 8.1以上への引き上げで得られる主な利点は4つ。最新構文の活用、セキュリティ向上、開発効率の改善、そしてランタイム性能の向上だ。

最新PHP機能の活用

PHP 8.1以上では、union types(複数の型を許容する宣言)、attributes(メタデータを付与する仕組み)、null-safe operator(null判定を簡潔に書く演算子)、match式、名前付き引数などが使えるようになる。WooCommerce本体だけでなくサードパーティ製の拡張機能も、これらの機能を前提に開発できる。

union typesとは、関数の引数や戻り値に「intまたはstring」のように複数の型を指定できる記法だ。これがあると、無理な型変換や冗長な分岐を減らせる。コードが読みやすくなり、バグの発生も抑えられる。

セキュリティとパフォーマンスの向上

サポート終了済みのPHPを使い続けると、既知の脆弱性が修正されないまま残る。PHP 8.1以上へ移行することで、セキュリティ修正が提供される安心な環境に切り替えられる。

さらに、WooCommerceと拡張機能が新しいPHP専用の安全な依存パッケージを採用できるようになる。旧バージョン向けの互換レイヤーを削除でき、継続的インテグレーション(CI)でテストするPHPバージョンも減るため、テストやリリースの速度も上がる。

PHP 8系へのアップグレード自体にも性能向上の効果がある。PHPランタイムの改善により、WooCommerceストアの表示速度や処理能力が底上げされる。これはコード変更なしで得られる利点だ。

PHP 7.4・8.0を使うストアへの影響

PHP 7.4・8.0を使うストアへの影響
PHP 7.4・8.0 のストア(Before)
WooCommerce 11.5 の更新が提供されない
既存バージョンのドットリリースのみ継続
↓
PHP 8.1 以上へ移行後(After)
WooCommerce 11.5 以降を更新可能
PHPアップグレード後に更新

PHP 7.4や8.0を使っていても、WooCommerceが自動でPHPを更新したり、ストアを停止させたりすることはない。ただし、WooCommerce 11.5以降への更新だけはブロックされる。

自動更新の停止と移行手順

提案が採用された場合、WooCommerce 11.5はPHP 8.1以上を必須とする。WordPressの標準機能により、要件を満たさないストアにはWooCommerce 11.5の更新が表示されなくなる。

PHP 7.4または8.0を使うストアは、現在のWooCommerceバージョンをそのまま使い続けることになる。同じブランチのドットリリース(例 11.4.x)は引き続き提供される。新しいメジャーバージョンへ移るには、先にPHPを8.1以上へアップグレードする必要がある。

前例となったWooCommerce 8.2

今回の進め方は過去のWooCommerceのPHP要件変更と同様のアプローチを取っている。WooCommerce 8.2では最低要件をPHP 7.4以上へ引き上げ、事前通知と移行ガイダンスが提供された。

当時も、要件を満たさないストアは自動更新されず、既存バージョンの更新のみ継続する方式だった。今回のPHP 8.1引き上げでも同じ流れが想定されている。

WordPressと拡張機能開発者への影響

WordPressと拡張機能開発者への影響

WordPressのPHP要件との違い

WordPress本体は現在、PHP 7.4以上で動作し、PHP 8.3以上を推奨している。しかしWooCommerceは、WordPressより高いPHP要件を維持してきた経緯がある。

WooCommerceは決済処理や在庫管理、注文ワークフローなどを持つ複雑なECアプリケーションだ。独自の依存関係や性能要件があるため、最低PHPバージョンをWordPressと完全に一致させる必要はないとされている。

拡張機能開発者への推奨事項

WooCommerce向けの拡張機能を開発している場合、すでに新しいPHPバージョンでテストしていることが理想だ。今回の変更により、WooCommerce 11.5以降だけを対象にする拡張機能はPHP 8.1以上の機能を使えるようになる。

一方、古いWooCommerceバージョンを引き続きサポートする拡張機能は、互換レイヤーや別コードパスを維持する必要が出てくる。PHPバージョンが上がっても、すべての拡張機能やテーマ、カスタムスニペットがそのまま動く保証はない。

本番環境へ適用する前に、ステージングサイトでPHP 8.1以上への移行テストを行うことが重要だ。特に独自カスタマイズや古い拡張機能を使っている場合、互換性の問題が顕在化しやすい。

意見募集と今後のスケジュール

意見募集と今後のスケジュール

フィードバックの募集ポイント

WooCommerceエンジニアリングチームは、ストア運営者、代理店、ホスティングプロバイダー、拡張機能開発者などから幅広く意見を求めている。主な質問は以下の通りだ。

  • PHP 7.4や8.0から移行できない理由はあるか
  • 該当PHPバージョンを必要とする拡張機能やテーマは存在するか
  • WooCommerce 11.5(2027年1月目標)で準備期間は十分か
  • ホスティングプロバイダーはWooCommerceストアのPHP利用状況について追加データを持っているか
  • 対応が望まれる移行ガイダンスは何か

互換性の問題を報告する場合は、PHPバージョン、WooCommerceバージョン、影響を受ける拡張機能、エラーメッセージを添えることが推奨されている。

決定までのタイムライン

WooCommerceチームはフィードバックと利用データを確認した上で、対象リリースと最低PHPバージョンを最終決定する。決定後は事前告知を行い、開発者が新しい要件でテストできるよう準備期間を設ける方針だ。

現時点ではまだ提案段階であり、正式な決定ではない。ただし利用データの減少傾向やEOLの状況を踏まえると、PHP 8.1以上への引き上げは現実的な選択肢として有力だ。

この記事のポイント

  • WooCommerce 11.5(2027年1月目標)からPHP 8.1以上が最低要件になる提案が発表された
  • PHP 7.4と8.0はサポート終了済みで、利用は全体の約6〜9%まで縮小している
  • PHP 7.4・8.0のストアは自動更新されず、移行後にWooCommerce 11.5へ更新できる
  • 最新PHP機能の活用、セキュリティ向上、開発効率の改善が主な目的だ
  • 拡張機能開発者はステージング環境でPHP 8.1以上へのテストを推奨
WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのマジックストリング廃止へ、エナムクラス導入で拡張開発が安全に

WooCommerceのコードベースで長年使われてきた「マジックストリング」が、人知れず問題を引き起こしていた。注文ステータス、商品タイプ、在庫状態、税金モード。これらの重要な値が、コード中で生の文字列として比較されていたのだ。タイプミス一つでバグになり、プレフィックスの有無で混乱し、コード検索でノイズが大量に混ざる。開発者にとって頭の痛い状況だった。

WooCommerceはこの問題に対処するため、Automattic\WooCommerce\Enumsという名前空間にエナムクラス群を導入した。注文ステータスや商品タイプを表す名前付き定数をパブリックAPIとして公開し、拡張機能開発者に採用を促している。本記事では、この変更の背景、利用可能なクラス、実際の導入方法を整理する。

マジックストリングがもたらす4つの問題

マジックストリングがもたらす4つの問題

WooCommerceは歴史が長い。そのため、注文ステータスや商品タイプといった重要な値が、PHPの近代的な慣習が生まれる前から存在している。コードベースの各所で、次のような生の文字列比較が行われてきた。

if ( 'completed' === $order->get_status() ) {
    // タイプミスがないことを祈るしかない
}

この書き方は一見シンプルに見えるが、WooCommerceのような大規模なコードベースでは深刻な代償を伴う。Developer WooCommerce Blogの記事では、その問題を4つの観点から説明している。

沈黙のエラー

文字列リテラルの最大のリスクは、タイプミスが静かに潜むことだ。'complete'と書くべきところを'completed'と書いても、リンターもオートローダーもテストもエラーを検出しない場合がある。コードは実行時に黙って失敗し、デバッグに時間を奪われる。

プレフィックスの有無による混乱

WordPressのデータベースでは、注文ステータスにwc-というプレフィックスが付く。データベースにはwc-completedとして保存されるが、WooCommerceの多くのAPIはプレフィックスなしのcompletedを期待する。この違いは、開発者が実際にコードを動かして初めて気づく類の落とし穴だ。

検索の非効率さとドキュメントの分散

エージェントやコード検索で'simple'という文字列を探すと、商品タイプのロジックを探しているのに無関係な箇所が大量にヒットする。一方、ProductType::SIMPLEのように名前付き定数で検索すれば、該当箇所を正確に絞り込める。さらに、on-holdのようなステータスの定義は、宣言箇所のdocblockにドキュメントとして残せるようになる。

マジックストリングの問題点(Before)
タイプミス検出困難 → 実行時まで気づけない
プレフィックス混乱 → wc-completed と completed の区別が曖昧
検索ノイズ → simple で検索すると無関係な箇所が大量ヒット
ドキュメント分散 → 値の意味がコード中に散在
↓
エナムクラス導入後(After)
名前付き定数 → タイプミスをコンパイル時に検出
意図の明確化 → OrderStatus::COMPLETED と OrderInternalStatus::COMPLETED を区別
検索精度向上 → ProductType::SIMPLE で該当箇所を正確に絞り込み
ドキュメント統合 → docblockに意味を記載

この比較で示したように、エナムクラスは文字列リテラルが抱える問題を構造的に解決する。特に、プレフィックス有無の違いを別々のクラスに分けることで、意図を明確に伝えられる点が重要だ。

ネイティブPHPエナムを採用しなかった理由

ネイティブPHPエナムを採用しなかった理由

PHPにはバージョン8.1からネイティブのエナム型が導入されている。しかしWooCommerceはこの選択肢を取らなかった。主に2つの理由がある。

PHP 7.4のサポート

WooCommerceの最低サポートPHPバージョンは7.4だ。このバージョンにはネイティブエナムが存在しない。PHP 8.1を前提にすると、多くのユーザーを切り捨てることになる。クラス定数として文字列を定義する方式なら、PHP 7.4でも問題なく動作する。

文字列互換性という設計判断

もう一つの理由はアーキテクチャ上の判断だ。注文ステータスや商品タイプの値は、すでに数百万のデータベースにプレーンな文字列として保存されている。数千の拡張機能もその形式を前提にしている。ネイティブPHPエナムを使うと値がオブジェクトに変換され、既存のコードが壊れる可能性がある。

文字列定数を使う方式なら、OrderStatus::COMPLETEDは従来の'completed'と同じ文字列を生成する。開発者はより明確な名前を使いつつ、WooCommerceの動作を変えない。既存コードが動き続け、拡張機能は準備ができた時点で新しい定数に移行できる。

final class OrderStatus {
    /**
     * 注文が完了した状態
     */
    public const COMPLETED = 'completed';
    // ...
}

このコードが示すように、エナムクラスはfinalで宣言され、public constとして定数を公開する。docblockで各定数の意味をドキュメント化できるのが利点だ。クラスを継承させないことで、APIの一貫性を保つ。

利用可能なエナムクラス

利用可能なエナムクラス

現在WooCommerceのsrc/Enumsディレクトリには、4つのカテゴリにまたがるエナムクラスが用意されている。各クラスの一覧を確認しよう。

注文と商品のエナム

  • OrderStatus(プレフィックスなしの値。例としてcompleted)
  • OrderInternalStatus(データベースに保存されるwc-プレフィックス付きの値)
  • OrderItemType(注文アイテムのタイプ)
  • ProductType(商品タイプ。例としてsimple)
  • ProductStatus(商品ステータス)
  • ProductStockStatus(在庫状態)
  • ProductTaxStatus(税金状態)
  • CatalogVisibility(カタログの表示設定)

支払いと設定値のエナム

  • PaymentGatewayFeature(ゲートウェイがsupports配列で宣言する文字列)
  • WeightUnit(重量単位)
  • DimensionUnit(寸法単位)
  • CurrencyPosition(通貨位置)
  • TaxBasedOn(課税基準)
  • TaxDisplayMode(税表示モード)
  • DefaultCustomerAddress(デフォルト顧客住所)
  • StockDisplayFormat(在庫表示形式)
  • CatalogSortOrder(カタログ並び順)

各クラスの完全な一覧は、WooCommerceのGitHubリポジトリにあるsrc/EnumsディレクトリとREADMEで確認できる。このディレクトリが権威ある情報源として公開されている。

注文関連 OrderStatus / OrderInternalStatus / OrderItemType
商品関連 ProductType / ProductStatus / ProductStockStatus 他
支払い関連 PaymentGatewayFeature
設定値関連 WeightUnit / DimensionUnit / CurrencyPosition 他

以上の4カテゴリが、現在WooCommerceで利用可能なエナムクラスの全体像だ。注文関連と商品関連が特に充実している。

拡張機能での採用方法

拡張機能での採用方法

エナムクラスは公的に発見可能なAPIとして設計されており、publicの可視性、docblock、開発者向けドキュメントを備えている。拡張機能開発者は安心して利用できる。

基本的な使い方

使い方はシンプルだ。use文で必要なクラスをインポートし、定数を参照する。例えば注文ステータスをチェックする場合、次のように書ける。

use Automattic\WooCommerce\Enums\OrderStatus;
use Automattic\WooCommerce\Enums\ProductType;

if ( OrderStatus::COMPLETED === $order->get_status() ) {
    // 注文が完了した場合の処理
}

$products = wc_get_products( array( 'type' => ProductType::SIMPLE ) );

採用前に確認すべき2つのポイント

エナムクラスを拡張機能に導入する前に、確認しておくべきことが2つある。

1. 最小サポートWooCommerceバージョン。エナムクラスは段階的に追加されてきた。OrderStatusはWooCommerce 9.5で導入され、商品関連クラスは9.7〜9.8頃、設定値クラスは10.xシリーズで追加された。古いバージョンもサポートする場合は、文字列リテラルを使い続けるか、class_exists()でガードする必要がある。

2. WooCommerceが期待する文字列。OrderStatus::COMPLETEDはcompletedを返すが、OrderInternalStatus::COMPLETEDはwc-completedを返す。ほとんどのWooCommerce関数はプレフィックスなしの形式を取るが、データベースレベルやpost_statusコンテキストではプレフィックス付きを使う必要がある。どちらの形式を使うべきかを意識するのが重要だ。

商品検索と注文検索の公式ドキュメントには、文字列リテラルとエナムクラスの両方の形式が併記されている。移行時の参考になる。

プレフィックスなし(API用)
OrderStatus::COMPLETED → completed を返す
使用場面 → wc_get_orders() などの API
↓
プレフィックスあり(DB用)
OrderInternalStatus::COMPLETED → wc-completed を返す
使用場面 → post_status やデータベース操作

このデモで示したように、2つの定数は同じ注文完了状態を表すが、使用するコンテキストが異なる。混同すると期待通りに動作しない。

今後の展開

今後の展開

Developer WooCommerce Blogの記事によれば、コアに新しい語彙(文字列値の集合)を追加する場合、エナムクラスをデフォルトで付ける方針が示されている。WooCommerceコアにはまだ名前の付いていない文字列値が多数残っており、コミュニティからの貢献も歓迎している。

この変更は拡張機能開発者にとって歓迎すべき動きだ。タイプミスのリスクが減り、コードの意図が読みやすくなり、IDEの補完機能も効きやすくなる。長期的にはWooCommerceエコシステム全体のコード品質向上につながる。

一方で、移行には段階的な対応が必要だ。既存の拡張機能は古いWooCommerceバージョンとの互換性を維持しながら、徐々にエナムクラスへ移行していくことになる。一括で全置換するのではなく、新規コードから採用していくのが現実的なアプローチだろう。

この記事のポイント

  • WooCommerceがマジックストリング(生の文字列リテラル)をエナムクラスに置き換える動きを進めている
  • エナムクラスはタイプミス防止、プレフィックス区別、検索精度向上、ドキュメント統合の4つの利点を持つ
  • ネイティブPHPエナムではなく文字列定数クラスを採用した理由は、PHP 7.4互換性と既存データベースの文字列互換性
  • 注文・商品・支払い・設定値の4カテゴリにエナムクラスが用意されている
  • 採用時は最小サポートWooCommerceバージョンと、プレフィックス有無のどちらの定数を使うかを確認する