Hi,
Our shipping rules are often defined by the delivery country.
If we put the shipping panel in the normal checkout page, the appropriate choices are not displayed when the delivery country is changed. Normally, I would expect the refresh event that is triggered when changing the address country to re-run the rules establishing which shipping methods are now valid.
I can get round this for now by defining a new checkout page and then having the shipping panes on this new page - that was I know the address has already been set. However, I'd like to be able to offer a single page checkout.
Hope this makes sense!
Many thanks
Richard
Comments
Comment #1
googletorp commentedI'm not sure that we can put this logic into the shipping module itself. The address and shipping module is not related. It may or may not be on the same page, and any address field can be used to determine the shipping quote. I'm currently developing a site where the shipping address would be an address entered per line item. There isn't a shipping fee though, but it's just one example that wouldn't fit into this scenario.
It would probably be better to put this kind of customization in a custom module, that knows how this would be needed.
I'm open for adding a hook or utility function or change the form generation if needed to make this easy.
What do you think you need from the shipping module to make this happen?
Comment #2
thill_ commentedFor our use cases it needs to update on State selection as well because for example Alaska and Hawaii always have different shipping options and pricing.
Comment #3
googletorp commentedComment #4
bojanz commentedI am not sure this can be done without the shipping form being on another page.
I wrote some form&widget altering code that swaps out the #ajax callback of addressfield with our own, and made it return the whole form instead of just the addressfield. This means that when the country changes, the whole form gets rebuilt and replaced. This also means that the rule gets rerun.
However, the rule always gets only the $order object, and that object only has reference fields pointing to profiles created later on, at that point there are no customer profiles created, and the fields are empty. When the form gets rebuild, the $order hasn't changed at all, so the rule will return the same results.
#ajax is just not meant to trigger validation / submission and save the order. I don't see any good way how we can solve this, without changing how commerce_shipping works. Probably by passing in the shipping information separately and changing all rules to accomodate that? But since shipping info would just be an array, it would probably not be available to tokens, which means that people would need to write custom PHP conditions (or to be more exact, commerce_shipping would probably be expected to provide them). While not too hard to do, it would break all existing actions.
Thoughts?
Comment #5
muschpusch commentedsubscribe
Comment #6
bojanz commentedAfter talking to googletorp and us agreeing that I should try to implement it, I had a lengthy brainstorm with rszrama where we managed to sink all of the ideas that we had.
Problem is, you have X panes with Y addressfields. They are all on the order object, so the rule can take something, compare, and return valid shipping methods.
When #ajax fires on one of the Y addressfields, we have no idea if that's the one that the rule actually uses to make a decision, so it passing it might have no effect.
The only way to do it right is to resave the order object on #ajax (which I was against in #4 and still am).
However, when #ajax fires, the form might not be in a valid state (#842292: Consider altering the checkout form validation process needs to be fixed for this to actually be seen), which means that the save can't happen.
So the user triggers #ajax, the subform fails validation, no save happens, shipping methods don't change. He fixes the error, hits next, goes to the next page, the shipping methods didn't change. Hence, we failed.
Right now the only way this can work right in all cases is if the shipping selection is on the next page.
So, no progress. Leaving this "postponed" instead of marking "won't fix" since rszrama will be reworking the shipping rules soon, and he promised he'll give it another look. New ideas might pop up.
Comment #7
googletorp commentedThis should go into (or maybe already is in) 2.x
@Ryan is this working in 2.x branch?
Comment #8
rszrama commentedNot working yet, but in the meantime I did just push a change so the shipping service selection pane shows up on a separate page after shipping information has been entered.
Comment #9
summit commentedHi,
Yes please for shipping service rerun as such that if the shipping address country changes, the shipping service is triggered automatically and the right financial order information is shown!
Greetings, Martijn
Comment #10
dianikol commentedAny news on that?? I think that this needs a more generic solution. For example the shipping costs should be recalculated when any field on the checkout changes, not only the address. A typical case is when the user changes the payment method. If he chooses "cash on delivery" then an extra shipping fee should be added on the order. Then via AJAX the appropriate rules should be triggered. (or something like that)
Comment #11
summit commentedHi, Running Commerce 1.3 and Shipping latest 2.dev would love to have this working. Does anybody have a in-between method to be able to select a country, and with selecting this country another shipping method rule is fired?
Greetings, Martijn
Comment #12
helior commented#1287124: Support recalculating shipping when the address is entered is trying to solving the same issue here.