Order Delivery Date Support Thread

[weif]

And the noconflict flag is in place...

[mc12345678]

And the noconflict flag is in place...

Just installed this to ZC 1.5.6a, using the responsive classic template and had no issues with calendar display. Thought I would try to check the operation of the trouble site but don't see a link to it, so if provided I will check it out when at a computer that allows me to follow along with the javascript/jQuery.

[mc12345678]

@weif,

Mentioned the potential jQuery conflict. Are you seeing in the console that there are jQuery issues or is it just from review of the thread that there was a problem? Curious if the execution has been followed and/or perhaps the css is causing the calendar to not be displayed where expected, etc...?

[weif]

@weif,

Mentioned the potential jQuery conflict. Are you seeing in the console that there are jQuery issues or is it just from review of the thread that there was a problem? Curious if the execution has been followed and/or perhaps the css is causing the calendar to not be displayed where expected, etc...?

I have not found any way to determine whether there is a javascript or jquery conflict, I just got that information from re-reading this thread and from some other searches online...

[mc12345678]

I have not found any way to determine whether there is a javascript or jquery conflict, I just got that information from re-reading this thread and from some other searches online...

Ok. Good information to know as the conflict issue was expected to be corrected in this recent distribution.

[weif]

Mentioned the potential jQuery conflict. Are you seeing in the console that there are jQuery issues or is it just from review of the thread that there was a problem? Curious if the execution has been followed and/or perhaps the css is causing the calendar to not be displayed where expected, etc...?

What led me to believe it was a JavaScript issue is that, on the site that isn't working, the "button" code is not inserted into the page to create the calendar button. You can see this when viewing source on the 1.5.5b site and comparing to the view source 1.5.6a site.


The diffs on the files on the server (for the tpl_checkout_shipping_default file)
the code on the 1.5.5b file shows:

<!-- Bof Order Delivery Date -->
<fieldset class="shipping" id="order_delivery_date">
<legend><?php echo TABLE_HEADING_DELIVERY_DATE; ?></legend>

<label for="order_delivery_date">Date:</label>
<input readonly="readonly" id="date" name="order_delivery_date" type="text">
</fieldset>
<!-- Eof Order Delivery Date -->

On the 1.5.6a site, the same block is:

<!-- Bof Order Delivery Date -->
<?php if (isset($display_delivery_date) ? $display_delivery_date : true) { ?>
<fieldset class="shipping" id="order_delivery_date">
<legend><?php echo sprintf(TABLE_HEADING_DELIVERY_DATE, (defined('MIN_DISPLAY_DELIVERY_DATE') && MIN_DISPLAY_DELIVERY_DATE > 0 && (method_exists($zcObserverOrderDeliveryDateObserver, 'display_delivery_date') ? $zcObserverOrderDeliveryDateObserver->display_delivery_date($order) : true)) ? TABLE_HEADING_DELIVERY_DATE_IS_REQUIRED : TABLE_HEADING_DELIVERY_DATE_IS_OPTIONAL); ?></legend>

<label for="order_delivery_date">Date:</label>
<input id="date" name="order_delivery_date" type="text" value="<?php echo $order_delivery_date; ?>">
</fieldset>
<?php } ?>
<!-- Eof Order Delivery Date -->

[mc12345678]

What led me to believe it was a JavaScript issue is that, on the site that isn't working, the "button" code is not inserted into the page to create the calendar button. You can see this when viewing source on the 1.5.5b site and comparing to the view source 1.5.6a site.


The diffs on the files on the server (for the tpl_checkout_shipping_default file)
the code on the 1.5.5b file shows:

<!-- Bof Order Delivery Date -->
<fieldset class="shipping" id="order_delivery_date">
<legend><?php echo TABLE_HEADING_DELIVERY_DATE; ?></legend>

<label for="order_delivery_date">Date:</label>
<input readonly="readonly" id="date" name="order_delivery_date" type="text">
</fieldset>
<!-- Eof Order Delivery Date -->

On the 1.5.6a site, the same block is:

<!-- Bof Order Delivery Date -->
<?php if (isset($display_delivery_date) ? $display_delivery_date : true) { ?>
<fieldset class="shipping" id="order_delivery_date">
<legend><?php echo sprintf(TABLE_HEADING_DELIVERY_DATE, (defined('MIN_DISPLAY_DELIVERY_DATE') && MIN_DISPLAY_DELIVERY_DATE > 0 && (method_exists($zcObserverOrderDeliveryDateObserver, 'display_delivery_date') ? $zcObserverOrderDeliveryDateObserver->display_delivery_date($order) : true)) ? TABLE_HEADING_DELIVERY_DATE_IS_REQUIRED : TABLE_HEADING_DELIVERY_DATE_IS_OPTIONAL); ?></legend>

<label for="order_delivery_date">Date:</label>
<input id="date" name="order_delivery_date" type="text" value="<?php echo $order_delivery_date; ?>">
</fieldset>
<?php } ?>
<!-- Eof Order Delivery Date -->

So the template block of code was changed to try to offer some expanded services and for operation to occur even in the absence of some of the other files, just in case.

Having had an opportunity to look at the site, there area either of two things that were causing an issue.

the javascript jQuery was not defined, so when attempting to execute jQuery.noConflict, that causes an error. But, then without some sort of noConflict tag, then it may be possible that a conflict could still exist.

I've proposed the following change, though can't really say that it is still the best.
in [FONT=Verdana,Arial,Tahoma,Calibri,Geneva,sans-serif]/includes/modules/pages/checkout_shipping/jscript_a-mootools.js
change:

jQuery.noConflict;

to:

if (undefined !== typeof(jQuery)) {
  jQuery.noConflict;
}

[/FONT]

[weif]

It turns out that the actual conflict was caused by having not merged the 1.5.6 template files with the live template. There are several changes between 1.5.1 (when they were last merged, in this case) and 1.5.6 which are no longer completely compatible.

So, boys and girls, remember when performing an upgrade, you need to check your template files for any custom template against the changes in the template it is modeled from...

[donw]

Hi, I have recently installed this module on a site running Zencart 1.5.5e. I originally installed version 2.6.1, and everything worked correctly with 2 exceptions.

1. The calendar popup doesn't appear on checkout. A date can be entered manually, and this functions correctly.

2. If a date is not entered, then on the order details, invoice and packing slip, a date of Tuesday 30th November, 1999 is shown. Looking at the database table, a value of 0000-00-00 00:00:00 is written to the table, rather than the correct default value of NULL (0001-01-01 00:00:00).

After reading a lot of posts in this forum, I downloaded and installed version 2.6.2, but bot problems persist. I consider 2. a bug.

I would appreciate any help to resolve these issues.

[mc12345678]

Hi, I have recently installed this module on a site running Zencart 1.5.5e. I originally installed version 2.6.1, and everything worked correctly with 2 exceptions.

1. The calendar popup doesn't appear on checkout. A date can be entered manually, and this functions correctly.

2. If a date is not entered, then on the order details, invoice and packing slip, a date of Tuesday 30th November, 1999 is shown. Looking at the database table, a value of 0000-00-00 00:00:00 is written to the table, rather than the correct default value of NULL (0001-01-01 00:00:00).

After reading a lot of posts in this forum, I downloaded and installed version 2.6.2, but bot problems persist. I consider 2. a bug.

I would appreciate any help to resolve these issues.

There are two aspects to item 2, the plugin uses ZC functions that are/were expected to provide appropriate response if no data was provided. This was found to be an issue and corrected in ZC 1.5.6. The pull that corrects the function operation for the three associated functions can be found in this PR: https://github.com/zencart/zencart/pull/2067/files and https://github.com/zencart/zencart/c...4c0a668713f047 to address the display of multilingual information on windows related systems (character encoding appeared to need modification on windows servers). While the first PR was not adopted in full (sequence of the checks was reversed), ZC 1.5.6 and above carries the calculations through to more appropriately handle/correct the issue. The second aspect is the need to assign a default to the field if nothing is provided. The field in the database can be modified per the below to provide a default and ensure that it accepts a value of NULL if NULL is given (Which should also prevent the incorrect storage of '0000-00-00 00:00:00'):

ALTER TABLE orders MODIFY order_delivery_date datetime DEFAULT '0001-01-01 00:00:00' NULL;

Then the code of post #478 that includes the following SQL:

UPDATE orders SET order_delivery_date = NULL WHERE order_delivery_date < '0001-01-01' AND order_delivery_date IS NOT NULL;

in anticipation of correcting issues associated with upgrading Zen Cart such as the orders table containing date/datetime fields that have incorrect/unacceptable values.