WC 11.0の注文アイテム削除アクションタイミング変更と開発者対応
WooCommerce 11.0.0のリリースに伴い、注文アイテム削除時のアクションフック woocommerce_removed_order_items の発火タイミングが大きく変わった。これまでは削除メソッド内で即座にデータベースからアイテムを消した直後にフックが走っていたが、今後は save() が呼ばれるタイミングまで遅延される。
この変更の本質は、注文復元フローで発生し得る「行アイテム消失」バグの修正だ。決済中断後の再開処理で、意図せず注文明細が空になる問題がこれで解消される。ただし、従来のタイミングを前提にした拡張機能やカスタムコードは、コールバックの変更が必要になる可能性がある。
この記事では、変更の背景、具体的な動作の差、そして開発者が取るべき対応策を整理する。内部的で動作確認用のフックに依存している開発者は特に注意が必要だ。
WooCommerce 11.0の注文アイテム削除フックに何が起きたのか
WooCommerceのコアクラス WC_Abstract_Order には、注文アイテムをまとめて削除する remove_order_items() メソッドがある。このメソッドは、チェックアウト時に注文内容を再構築する場面などで内部的に呼ばれる。
10.9系以前では、remove_order_items() が呼ばれるとすぐにデータベースから該当のアイテム行が削除され、その直後に woocommerce_removed_order_items アクションが発火していた。いわば「削除してからお知らせ」の流れだ。
11.0.0からは、アイテムのデータベース削除そのものは save() が呼ばれるまで引き延ばされる。そして woocommerce_removed_order_items アクションは、実際に削除がコミットされた直後の save_items() 内で発火するようになった。すぐに消さず、「保存のタイミングで消して知らせる」形へと変更されたわけだ。
この図のように、preフック（woocommerce_remove_order_items）の位置は変わっていない。変更されたのはpostフックのほうだけで、発火の場所が remove_order_items() の中から save_items() へと移動した。
なぜ削除の遅延が必要だったのか
変更の直接のきっかけは、チェックアウト時の注文再開フローで発生していたバグだ。WooCommerceの内部では、決済途中で何らかのエラーや中断が起きた場合、同じ注文データを使って再開を試みる仕組みがある。
10.9以前の処理は次のような流れだった。まず remove_order_items() で既存のアイテムをデータベースから削除し、その後に新しい内容を再構築して save() で保存する。ところが、削除と再構築の間に何らかの例外が発生したり、決済ゲートウェイが二重チェックアウトをトリガーしたりすると、新しいアイテムが書き込まれないまま保存処理に進んでしまうケースがあった。
その結果、合計金額は正しいのに注文明細が空になるという不整合が発生していた。管理者や店舗スタッフから見ると「注文はあるのに何を買ったのかわからない」状態で、商売上の大きな問題だ。
そこで11.0.0では、データベースからの削除を save() のタイミングまで遅延させる設計に変更された。これにより、再構築の途中で何か問題が起きても、直前の正しい注文内容がデータベース上に残っている。中断したら元のまま、成功したら新しい内容で上書きされる。再開フロー全体が原子的になるわけだ。
preフックの woocommerce_remove_order_items は引き続き remove_order_items() の先頭で同期的に発火する。postフックだけが「保存時に遅延」される形になる。両方のフックを組み合わせて使っているコードだけが影響を受ける可能性がある。
開発者が影響を受ける具体的なパターン
今回の変更は、あらゆる拡張機能に一律で影響するわけではない。影響を受けるかどうかは、フックの使い方によって明確に切り分けられる。
影響を受けるケース
次のようなコードが該当する。
woocommerce_removed_order_itemsにコールバックを追加し、その中で「アイテムはもうデータベースに存在しない」という前提で処理を行っているwoocommerce_remove_order_items（pre）とwoocommerce_removed_order_items（post）のペアで一連の操作を挟み込んでいるremove_order_items()が戻った直後に「データベースからアイテム行が消えている」と期待している
要するに、postフックが「同じコールスタック内ですぐ実行される」という暗黙の前提に依存しているコードは、動作が変わる可能性が高い。
影響を受けないケース
一方、次のような使い方をしている場合は問題ない。
- 最終的な保存済みの注文状態だけを監視する目的でpostフックを使っている
- コールバック内で、DB削除がコミットされた後の最終状態だけを参照している
- WooCommerceコア自体にはこのフックの利用箇所はないため、標準機能への影響はゼロ
postフックは変わらず「データベース削除の完了後」に発火するため、単純に「削除が終わったことを検知したい」だけのコードはそのまま動く。
開発者が今すぐ取るべき具体的な対応
コールバックの動作確認と修正
影響を受ける可能性のあるコードを発見したら、まず次の3点を確認してほしい。
remove_order_items()が戻った直後にデータベースのアイテム削除を前提にしている場合は、削除を期待する処理の前に明示的に$order->save()を呼ぶ- preフックとpostフックをペアで使っている場合は、postフックのロジックを注文の保存後に実行するように再構成する
- 動作確認はWooCommerce 11.0.0以降の環境で必ず実施する
コールバックが単に「削除後の状態を見たい」だけなら、特に対応は不要だ。postフックは依然としてDB削除のコミット後に発火するため、観測できる最終状態に違いはない。
save() を明示的に呼ぶことの意味
11.0.0以降のバージョンでは、remove_order_items() を呼んだだけではデータベースへの変更は一切発生しない。あくまでオブジェクトの内部状態が変わるだけだ。データベースへの反映は後続の save() でまとめて行われる。
つまり、「アイテムが消えた状態の注文をデータベース上で確定させたい」のであれば、プログラムの流れの中で明示的に $order->save() を実行する必要がある。これは今回の変更を正しく扱う上で最も重要なポイントだ。
この変更がもたらす開発者体験への影響
一見すると「動いていたコードが壊れるのか」と不安に思うかもしれないが、この変更の根底にはコードの安全性を高めるという明確な意図がある。削除と保存を分離することで、中途半端な状態に陥る可能性を根本から断ち切っている。
WooCommerceの内部設計に詳しい開発者であれば、データベース操作の遅延実行はむしろ現代的なパターンだと感じるだろう。トランザクション的な一貫性を重視する設計は、拡張機能の品質向上にもつながる。
影響範囲が限定的であることも安心材料だ。WooCommerceコア自身はこのフックを消費しておらず、実質的にはサードパーティ製のプラグインやテーマだけが該当する。大半のショップ運営者は特に意識することなくアップデートできる。
この記事のポイント
- WooCommerce 11.0.0で
woocommerce_removed_order_itemsフックの発火タイミングがsave()実行時へ変更された - preフックの
woocommerce_remove_order_itemsは変わらず同期的に動作する - 変更の目的は注文再開時の行アイテム消失バグの修正で、削除処理を遅延させることで安全なフローを実現
- postフックが「削除直後に走る」ことを前提にしたコードのみが影響を受ける可能性がある
remove_order_items()の直後にDB反映を期待するなら明示的にsave()を呼ぶこと
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験