When a recurring cart's shipping method choices match those of the global (initial) cart, shipping method radio buttons aren't shown for a recurring cart.
These recurring carts are supposed to inherit the method the customer chooses for the initial order, however, this wasn't the case because of a quirk in how the hidden recurring shipping method elements worked.
When the page would load the recurring cart shipping method be given the same chosen method (eg free shipping) via a hidden input field. If the customer changed the chosen method, the form would submit and that hidden recurring shipping method element that still stored free shipping would be submitted. This code, would then set the recurring cart's chosen method to what was the previously chosen method. The cart html elements would be updated via ajax, but because this recurring cart is supposed to inherit the global cart's chosen method, it would display the correct name, but the shipping method cost used in recurring cart calculations would have been the old chosen method.
This process would then repeat, and each time the user changed the chosen method, the recurring totals would lag by 1 change. eg the total would reflect the last chosen method.
This PR addresses the issue by ensuring that when a recurring cart shipping method is expected to adopt the chosen method from the global cart, our hidden shipping method elements are appropriately updated to reflect that, ensuring that the data submitted in the form is correct.
How to test this PR
Add at least 3 shipping methods. eg
Free shipping
Flat rate: $10
Flat rate: $50
Place a subscription in the cart.
On the cart page change back and forth the shipping method.
On trunk you'll notice the recurring total is incorrect between changes and the correct total lags between each change.
On this branch it should update correctly.
Repeat on the checkout page
trunk
This branch
Additional Testing
Above I've outlined a simple test to replicate and observe the fix. Additional steps should be taken to test more complicate shipping arrangements like, free shipping only being offered to totals reaching a minimum. Free trials, sign up fees, free shipping coupons etc.
Comments
The Block cart and checkouts don't appear to be impacted by this because they always give the customer the option to select a shipping method for each recurring cart. There isn't a situation where it inherits the choice from the initial cart.
Product impact
[x] Added changelog entry (or does not apply)
[ ] Will this PR affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
[ ] Will this PR affect WooCommerce Payments? yes/no/tbc, add issue ref
[ ] Added deprecated functions, hooks or classes to the spreadsheet
Fixes https://github.com/woocommerce/woocommerce-subscriptions/issues/4335
Description
When a recurring cart's shipping method choices match those of the global (initial) cart, shipping method radio buttons aren't shown for a recurring cart.
These recurring carts are supposed to inherit the method the customer chooses for the initial order, however, this wasn't the case because of a quirk in how the hidden recurring shipping method elements worked.
When the page would load the recurring cart shipping method be given the same chosen method (eg free shipping) via a hidden input field. If the customer changed the chosen method, the form would submit and that hidden recurring shipping method element that still stored free shipping would be submitted. This code, would then set the recurring cart's chosen method to what was the previously chosen method. The cart html elements would be updated via ajax, but because this recurring cart is supposed to inherit the global cart's chosen method, it would display the correct name, but the shipping method cost used in recurring cart calculations would have been the old chosen method.
This process would then repeat, and each time the user changed the chosen method, the recurring totals would lag by 1 change. eg the total would reflect the last chosen method.
This PR addresses the issue by ensuring that when a recurring cart shipping method is expected to adopt the chosen method from the global cart, our hidden shipping method elements are appropriately updated to reflect that, ensuring that the data submitted in the form is correct.
How to test this PR
trunkyou'll notice the recurring total is incorrect between changes and the correct total lags between each change.trunkAdditional Testing
Above I've outlined a simple test to replicate and observe the fix. Additional steps should be taken to test more complicate shipping arrangements like, free shipping only being offered to totals reaching a minimum. Free trials, sign up fees, free shipping coupons etc.
Comments
The Block cart and checkouts don't appear to be impacted by this because they always give the customer the option to select a shipping method for each recurring cart. There isn't a situation where it inherits the choice from the initial cart.
Product impact