Order Delivery Date Support Thread

And the noconflict flag is in place...

weif:

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.

@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...?

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...?

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...

weif:

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.

mc12345678:

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 -->

weif:

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 /includes/modules/pages/checkout_shipping/jscript_a-mootools.js
change:

jQuery.noConflict;

to:

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

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...

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.

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.

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/commit/554547597905d1914d5bfa289d4c0a668713f047 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.

Thanks. The modified file has fixed the problem. Had already carried out the post #478. Any suggestions re the calendar not showing up ?

donw:

Thanks. The modified file has fixed the problem. Had already carried out the post #478. Any suggestions re the calendar not showing up ?

This could be from a number of things, between load sequence of the mootools javascript, the presence/absence of css (button may be there, but not where it is expected), template modifications and whether the date box is tied to the correct object, as part of sequence loading whether some other javascript/jquery is prohibiting connecting/executing, a javascript failure in something else, the page not passing html validation, etc...

I (or I would think almost any forum member) could take a look at some of the above by knowing where on the Internet to look at and when that/those individuals are available to do so.

I've just had a look in the Safari javascript console and the error coming up is related to the code:

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

at the top of the jscript_a-mootools.js file. The error is "Can't find variable: jQuery

Appreciate any help in sorting this out.

donw:

I've just had a look in the Safari javascript console and the error coming up is related to the code:

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

at the top of the jscript_a-mootools.js file. The error is "Can't find variable: jQuery

Appreciate any help in sorting this out.

Basically that means that jQuery is not being loaded before the mooTools.js file. This seems to imply that the header file(s) for the page load have been modified away from standard content for the last several Zen Cart versions. Specifically includes/templates/YOUR_TEMPLATE/common/html_header.php.

Effectively, somewhere above/before the mootolls file, jQuery should be loaded. It has been verified to function with the version released with ZC 1.5.6c and with the alpha version of ZC 1.5.7. Suggest comparing your version of that file with either of the two versions available either responsive_classic or template_default...

Ok. From your suggestion I've replaced the html_header.php file with the 1.5.6c version, and that has gotten rid of the Mootools error, but I am now left with the following:

TypeError: el.addEvent is not a function. (In 'el.addEvent('focus', function(cal){ this.toggle(cal); }.pass(cal, this))', 'el.addEvent' is undefined) on line 454 of jscript_b-calendar.js

I've done a fair amount comparing of other files to try to find the problem, but have had no success.

donw:

Ok. From your suggestion I've replaced the html_header.php file with the 1.5.6c version, and that has gotten rid of the Mootools error, but I am now left with the following:

TypeError: el.addEvent is not a function. (In 'el.addEvent('focus', function(cal){ this.toggle(cal); }.pass(cal, this))', 'el.addEvent' is undefined) on line 454 of jscript_b-calendar.js

I've done a fair amount comparing of other files to try to find the problem, but have had no success.
I have this installed on what has now become a Zen Cart 1.5.7 site using responsive_classic primarily. Looking through the code as able, it seems that there may be an issue connecting with the box that is to represent/hold the date information. Again, need to be sure that the page validates against html and that the location to hold the date has the applicable html code to attach to the date block. That should be present in the provided checkout_shipping file at least in the modified code section.

Hi

Little bug that seems to have always existed with this -

If you select your delivery date then click 'Change Address' - on return to 'step 1 of 3' it doesn't remember the delivery date.

Using 1.5.6c and latest delivey date plugin - but I've had this issue forever.

royaldave:

Hi

Little bug that seems to have always existed with this -

If you select your delivery date then click 'Change Address' - on return to 'step 1 of 3' it doesn't remember the delivery date.

Using 1.5.6c and latest delivey date plugin - but I've had this issue forever.

Good point, though I wonder if it is possible to capture data from the page when selecting that or any other "button" on the page. Will take a look at the possibility of capturing the selection in the session when making the selection so that if a selection is made and navigation away from the page and subsequent return will retain the selection. May be a bit, but issue will be noted in github.

mc12345678:

Good point, though I wonder if it is possible to capture data from the page when selecting that or any other "button" on the page. Will take a look at the possibility of capturing the selection in the session when making the selection so that if a selection is made and navigation away from the page and subsequent return will retain the selection. May be a bit, but issue will be noted in github.

Submitted as an issue: https://github.com/mc12345678/order-delivery-date/issues/5

mc12345678:

I have this installed on what has now become a Zen Cart 1.5.7 site using responsive_classic primarily. Looking through the code as able, it seems that there may be an issue connecting with the box that is to represent/hold the date information. Again, need to be sure that the page validates against html and that the location to hold the date has the applicable html code to attach to the date block. That should be present in the provided checkout_shipping file at least in the modified code section.

I have another issue with this plugin and the classic responsive template.

The presence of mootools is breaking the mobile device menu on this page - you'll see its contents below the footer.

If you remove mootools from the directory it works properly.

Any ideas?