Printable View
Bug or intended?
As we know when you first hit the Checkout Shipping page the delivery date is set to blank.
Then lets say you have multiple shipping options - and lets say it has defaulted to 'Store Pickup' and you change it to 'Delivered' and click Continue (without updating delivery date).
Quite correctly you are warned that you need to enter your delivery date. However your change of shipping option is not remembered and it remains as 'Store Pickup'.
Is this intended functionality or a bug?
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?Quote:
Originally Posted by royaldave
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...
Thanks for your reply.
Just so you understand why only now I'm coming up with this issue is that I am intending to implement the "minimum order" plugin (https://www.zen-cart.com/downloads.php?do=file&id=402) however I have amended it to allow a "small" order to checkout with Store Pickup and only block orders that are being delivered.
Unfortunately it makes my site look a little buggy if they forget to enter the date and they change the shipping method from Delivery to Store Pickup and the warnings keep coming up and the method stays at "delivery".
Or maybe I'm being too pedantic..
Ok, just about done with updating for ZC 1.5.7 and to address the above issue... Man a lot has changed in this area of the code... Although I've also found some areas of the ZC code can be filled with potential issues for those wishing to modify the email sent out by the zen_update_orders_history function and to customize emails without touching the function code... I've been able to handle most of the effort by way of the observer system though I'm trying to incorporate the information completely through that and inline with execution.
Anyways, need to test the operation out, but I believe I now have the code working such that at least in the standard ZC checkout process if there is a problem with the date information that other processing code is executed to try to take the customer to the checkout_payment page at which point the customer is redirected back to the checkout_shipping page. Probably should consider that action for one or more other pages in the checkout process though... Hmm... Hope to have something pushed to github shortly.
Nope, I don't think it is pedantic, the other night, ordered online from a "big company", every time went through almost anything on the checkout page the option to do curbside pickup changed to instore... For one reason or another had to cycle through like 4 times and updated the option each of those 4 times; however, somehow the final result was the "default" of instore...Quote:
Originally Posted by royaldave
At any rate, I get it and I do believe I was concerned about it, but was having difficulty finding an appropriate location that was "guaranteed" to work because of the internal operation when submitting for process. There's currently no redirect after collecting the information but before allowing operation to continue...
Ok, I'm kind of done playing... Not saying perfect, but I'm tired of testing this at the moment and need some input on expectations/desires for the email etc...
I added files for ZC 1.5.7 into their own folder within the distribution which is currently accessible from: mc12345678/order-delivery-date at ZCv157 (github.com). I haven't seen the real final email result, but I can't say that I like how the notes are addressed... Again, input requested...
I also did not test with any of the other modified login/order schemes, but what I did test was the functionality at/around the entry or missing entry of the order delivery date to validate that other selections were maintained... As far as one or more observers monitoring some of these notifiers, may want to consider the autoload point sequence for each to ensure a properly sequenced load and to accomplish whatever each plugin does. It may also be that some of the observer code has to be split out so that the load sequence occurs as needed, but also be careful that dependencies are not lost when doing so.
I'm using 1.5.6 so so just updated the auto.order_delivery_date_observer file.
Seems to work - it retains the chosen delivery method and I've put it live.
One minor feedback though is to update -
$html_msg['EMAIL_TEXT_DELIVERY_DATE'] = EMAIL_TEXT_DELIVERY_DATE . ' ' . zen_db_output($callingClass->info['order_delivery_date']);
to -
$html_msg['EMAIL_TEXT_DELIVERY_DATE'] = EMAIL_TEXT_DELIVERY_DATE . ' ' . zen_date_long(zen_db_output($callingClass->info['order_delivery_date']));
}
because the zen_date_long looks nicer :)
Incorporated that for both the text and html entries in that area of the code. Thank you for the input.Quote:
Originally Posted by royaldave
Hi,
I have installed the required files and do see the delivery date in the confirmation email. However I do not see the desired delivery date in the invoice when I am in the Admin area. I have checked the invoice.php file and it does include the following line:
define('ENTRY_DELIVERY_DATE', 'Desired Delivery Date:');
That define would be expected to be in the admin/includes/languages/YOUR_LANGUAGE/invoice.php file,Quote:
Originally Posted by rkhan3366
To display that constant and the associated information for the order, changes to admin/invoice.php would need to have been incorporated. While the specific Zen Cart version appears to not be indicated (item identified in the posting tips), I would expect content similar to the following to be incorporated to the applicable version of the file:
The above code was copied directly from the Zen Cart 1.5.7 version of invoice.php as provided in the distribution package at/around lines 133 through and including 136.Code:<tr>
<td class="main"><strong><?php echo ENTRY_DELIVERY_DATE; ?></strong></td>
<td class="main"><?php echo zen_date_long($order->info['order_delivery_date']); ?></td>
</tr>