Ehhh, third option? Not originally/recently a consideration of concern?! It certainly was not intentional to blow away everything else just because there was an issue with the delivery date. The question becomes what to do about it in a "broader" acceptable way?
Right now, the location where the issue is detected still seems ideal; however, it is the redirect that is done right then that is the problem. That redirect occurs before the remainder of the shipping options are processed as part of the page's header load.
Unfortunately, if the redirect doesn't happen where it currently is set, then the next opportunity which allows the shipping module to be set is in the load of the checkout_payment page.
What this will do is allow the shipping module(s) to process on the delivery date with the possibility of knowing that there is a problem with that delivery date, but still storing whatever value was selected and then upon redirect to the checkout_payment page be sent back to reselect the delivery date.
Likely what I would do is that in the current location where there is the redirect because of the date, I would set a flag in the class to indicate the need to redirect on checkout_payment or something. And then when listening to checkout_payment, cause the redirect back to checkout_shipping... now I don't yet have an idea about how this might affect non-three page checkout processes.
Of course another idea is that in the "error" message add text to indicate the extent of reselection needed... but I'll prep something to take a look at for your situation and can see if what problems it creates by implementing...



Reply With Quote
