Two related issues:
- If conditions change during an ajax submission so as to replace one set of available payment methods with another, this can produce the "An invalid option has been detected" message.
- If conditions change so as to remove ALL available payment methods, an Ajax error is generated.
The 2-part patch to follow fixes these errors.
The goal here, along with #1373236: Allow multiple modules to react on checkout Ajax events and #1518522: Update order_total when order saved is to provide a robust replacement for uc_free_order.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 1524716-payment-ajax-6.patch | 4.68 KB | longwave |
| #4 | 1524716-payment-ajax-4.patch | 10.42 KB | wodenx |
| #1 | 1524716-payment-ajax.patch | 7.81 KB | wodenx |
Comments
Comment #1
wodenx commentedComment #2
longwaveComment #3
longwaveShouldn't we set $order->payment_method always instead of using $default?
Comment #4
wodenx commentedWell, I guess my thought was not to alter the $order object in a 'view' callback, but it doesn't really make any difference, and I violated my own principle in #1525490: Pass payment method name to callback function., which is also fixed by doing it this way...
Comment #5
longwave#4: 1524716-payment-ajax-4.patch queued for re-testing.
Comment #6
longwaveThe drupal_goto() means that if you select (say) a country that has no payment methods available, navigate away, then try to navigate back to the checkout page, you are redirected away and aren't given the option to change your country again.
The attached patch reworks #4 so the checkout is always shown, just with a disabled radio button if no methods are available. It also simplifies and reworks some of the surrounding code to make it a bit easier to follow.
Comment #7
longwaveCommitted #6.