mc12345678 / order-delivery-date Goto Github PK

As a result of the order_delivery_date field being of type date instead of datetime, retrieval of the information results in only the date being returned that if not entered (though still needs a default as described in issue #1), may result in 0000-00-00 or null populating the database or if properly handled for newer mysql servers 0001-01-01. Regardless, when this information is fed to the zen cart functions of zen_date_long, zen_date_short, etc.. will result in the date being provided back as these functions expect a fully formed date (to include a time of 00:00:00 or no value to be returned (null by loose comparison).

By updating the field to a datetime field (and an appropriate default date as expected by #1), retrieval of the stored information will align with the expectations of those functions at least until they are updated to potentially reflect a date of 0001-01-01.

If jQuery is not loaded before attempting to load the javascript of this plugin, then a console error is logged that jQuery is not defined. In trying to make the date selector compatible with more recent versions of Zen Cart, a jQuery.noConflict() command was added to the javascript. The expectation was that the plugin would be loaded to a system that was up-to-date with the latest Zen Cart template arrangement; however, as discovered in the forum thread for this plugin when the template files were not updated to load jQuery, the plugin failed on page load.

To resolve the issue, need to check if jQuery is defined. If it is, then issue the noConflict() command, if not, then carry on as normal.

The sql (deliverydate.sql) that installs the additional field to the orders table does not include a default date which is suggested to support strict processing/reporting.

This should follow the ZC standard of 0001-01-01 for the default.

The forum I believe has the removal sql for this plugin, but there is not any provided as just a stand-a-lone file. Further it should be recognized that removal of the data from the orders table does remove historical data about orders. The continued presence of the field(s) serves as bloat but does not cause processing issues.

Because the changes are so minimal to this plugin, it is not seen as one that requires an auto-installer.

As identified in the forum at: https://www.zen-cart.com/showthread.php?92762-Order-Delivery-Date-Support-Thread&p=1364258#post1364258
if when first landing on the page that displays the order delivery date and a date is selected, if the next action is not to submit the page, then the date is not retained. For example, after selecting a date if navigation occurs to go back to the shopping cart or to enter a new/different address, then when returning to the page displaying the date entry field, the date must be re-entered.

A potential solution to this is to store the date in the session at the point of selecting the date as it may not be (is not) possible to capture the field data with each/every subsequent selection. While this perhaps could be made as a configuration option, it does not seem like it would be of significant value. Comment is welcome here or in the forum about that aspect. In absence of good reason to make it configurable, it will not be setup as a configurable option.