When an extension registers a callback function with woocommerce_store_api_register_update_callback, the billingAddress.state value of the cart data is changed to match the default country set for the WooCommerce store, when the client side State/County is empty. For example, when selecting Portugal or Germany as the country on the Checkout page, the "State" input is hidden (and set as an empty string in the cart state).
When a call is made to /wc/store/v1/cart/extensions from the client (usually via the extensionCartUpdate() function) and the "State" input is empty, the response will change the billingAddress.state to a country code (which I think is the default country code the store is set up with in Woocommerce settings.
I've tested this with two separate plugins newsletter-test and woocommerce-eu-vat-number and empty callback functions to make sure it's nothing to do with the extension.
This is causing a bug in woocommerce-eu-vat-number where we are generating two batch requests per update. The first comes back with a different state, so the client updates it's state and persists to the server with another update-customer request. The buck stops here with this plugin, but I can see this getting into an infinite loop pretty easily so we should probably fix this sooner rather than later
Describe the bug
When an extension registers a callback function with
woocommerce_store_api_register_update_callback
, thebillingAddress.state
value of the cart data is changed to match the default country set for the WooCommerce store, when the client side State/County is empty. For example, when selecting Portugal or Germany as the country on the Checkout page, the "State" input is hidden (and set as an empty string in the cart state).When a call is made to
/wc/store/v1/cart/extensions
from the client (usually via theextensionCartUpdate()
function) and the "State" input is empty, the response will change thebillingAddress.state
to a country code (which I think is the default country code the store is set up with in Woocommerce settings.Ok that's a mouthful, here's a video:
https://user-images.githubusercontent.com/3966773/168869098-402dfd72-bea4-42fe-b5cb-220d2a575c6b.mov
I've tested this with two separate plugins
newsletter-test
andwoocommerce-eu-vat-number
and empty callback functions to make sure it's nothing to do with the extension.This is causing a bug in
woocommerce-eu-vat-number
where we are generating two batch requests per update. The first comes back with a different state, so the client updates it's state and persists to the server with anotherupdate-customer
request. The buck stops here with this plugin, but I can see this getting into an infinite loop pretty easily so we should probably fix this sooner rather than laterTo reproduce
Steps to reproduce the behavior:
try/replicate-store-api-bug
branchcomposer install && nvm use 12 && npm i && npm start
billing_address.state: "DE-BE"
Expected behaviour
I would expect the
billing_address.state
not to change on the serverEnvironment
WordPress (please complete the following information):