Order Delivery Date Support Thread

kimono:

Thank you very much.
I am using 1.5.5 and 2.5.1.
If you set the direction to 5 and you want to allow Saturdays and Sundays for breaks to be blocked, I would like to be able to select days after Saturday and Sunday, is it possible to deal with it?
Example: today is 2017/8/10
Direction: 5
Blocked: '0 * * 0, 6'
Delivery possible date is 8/17.

It is possible to prevent delivery selection of saturday and sunday by the above blocked statement; however, Direction is a number representing how many calendar days forward of today to allow the next delivery. Basically in your case, if today is Saturday, Sunday, early Monday or late Friday then the direction is 5, otherwise 7.

mc12345678:

It is possible to prevent delivery selection of saturday and sunday by the above blocked statement; however, Direction is a number representing how many calendar days forward of today to allow the next delivery. Basically in your case, if today is Saturday, Sunday, early Monday or late Friday then the direction is 5, otherwise 7.

Thank you very much.
I am sorry that the reply was delayed.
Is there a way to judge direction is 5, otherwise 7?

kimono:

Thank you very much.
I am sorry that the reply was delayed.
Is there a way to judge direction is 5, otherwise 7?

More research is needed, but in the basic sense, additional javascript code can be used to provide a result of 5 or 7 depending on the result of the javascript method: getDay()

 todayDate = new Date();
curDay = todayDate.getDay();
Direction : (curDay == 0 || curDay == 1 || curDay == 5 || curDay == 6) ? 5 : 7);

The problem with the above is that it uses 5 for any time during Monday and Friday, not just after some cut-off time. Further, the function responds based on the date/time of the user not the store. So in the extreme case of a store being on one side of the date line, a customer on the other side may be offered a delivery time period outside of the expected/allowed time frame or may be provided a date that is sooner than possible. Additional date/time comparison would be needed to say make the comparisons on the left more "realistic" to your business if you deal with people outside of your central location. If they are local, then say where curDay == 1 && curTime < Mondays_cut_off_time would be what is needed, though would have to also identify/determine what Mondays_cut_off_time would be. The same would be needed for Friday but a little in reverse: curDay == 5 && curTime >= Fridays_cut_off_time. Oh, also would need to set/determine curTime... again more research would be needed on my side or as someone else offers up.

Also, if additional "tests" are added as described, things like curDay == 1 && curTime < Mondays_cut_off_time would need to be surrounded by parentheses. So that the two pieces would be treated as one test.

Also, it is fine if only Saturday and Sunday, but it seems to be unable to deal with holidays and other holidays.

mc12345678:

More research is needed, but in the basic sense, additional javascript code can be used to provide a result of 5 or 7 depending on the result of the javascript method: getDay()

todayDate = new Date();
curDay = todayDate.getDay();
Direction : (curDay == 0 || curDay == 1 || curDay == 5 || curDay == 6) ? 5 : 7);

> 
> The problem with the above is that it uses 5 for any time during Monday and Friday, not just after some cut-off time. Further, the function responds based on the date/time of the user not the store. So in the extreme case of a store being on one side of the date line, a customer on the other side may be offered a delivery time period outside of the expected/allowed time frame or may be provided a date that is sooner than possible. Additional date/time comparison would be needed to say make the comparisons on the left more "realistic" to your business if you deal with people outside of your central location. If they are local, then say where curDay == 1 && curTime < Mondays_cut_off_time would be what is needed, though would have to also identify/determine what Mondays_cut_off_time would be. The same would be needed for Friday but a little in reverse: curDay == 5 && curTime >= Fridays_cut_off_time. Oh, also would need to set/determine curTime... again more research would be needed on my side or as someone else offers up.
> 
> Also, if additional "tests" are added as described, things like curDay == 1 && curTime < Mondays_cut_off_time would need to be surrounded by parentheses. So that the two pieces would be treated as one test.

Thank you very much for your prompt response.
It seems that response other than holidays on Saturdays and Sundays alone seems to be difficult only with the above answers.

By the way, if it is judged by time, it may not be beautiful,
direction: <?php (strtotime(date('H:i:s')) < strtotime('10:00:00')) ? 5:7; ?>
I feel like I can cope if I do.

kimono:

Thank you very much for your prompt response.
It seems that response other than holidays on Saturdays and Sundays alone seems to be difficult only with the above answers.

Take a look at the example in: includes/modules/pages/checkout_shipping/jscript_calendar_head.php

It contains an example of two "dates" being blocked out for one entry. The first example is an actual and specific date, the second is more generic, but they are contained within square brackets with a comma between. To then factor that/those in as well to achieve the most flexibility for the customer, the holiday would have to be "considered" within the direction determination. Ie. A Monday holiday with a today date being Thursday means that the delivery has to be pushed out an additional day. If nothing else, welcome to computers and date/time keeping. :P sorry, some of the issues surrounding dates are not the easiest to resolve. There may be some additional "plugin" out there that could do this part of the calculation and provide a modified future number. Or perhaps a different date script could do it more "automatically"; however, capturing a lot of that request requires additional "work".

kimono:

By the way, if it is judged by time, it may not be beautiful,
direction: <?php (strtotime(date('H:i:s')) < strtotime('10:00:00')) ? 5:7; ?>
I feel like I can cope if I do.

Right, so, again, using php provides date/time of the server. Using javascript basically uses the date/time of the computer accessing the site... working around that is where I was indicating addition review would be necessary. Wanted to at least get you started on looking, thinking, etc...

I'm sure I overthink it, but another concern/consideration of using php time (the "exact time" instead of a timezone) is that if a page is opened either near the end of the time period or just before the start, when the javascript processes to show the available options, the information is hard-coded and not flexible to the users time. Works in their favor just before the cut-off on Friday, but hurts them if they start just before the late Monday time.

Then there is also the effect of opening another tab for the site such that the session remains active while they "investigate" or otherwise navigate the site to eventually come back to the checkout section. Again, generally want to keep that as fluid as possible. Now the php time and timezone could be hardcoded as part of the comparison such that the user's date/time is converted to the same as your server and then compared to that value... That way at least you don't have to capture their time, just "show" them "yours" and let the software complete the comparison.

Then as for the "holidays" basically need to evaluate future holidays to see if they fall within the applicable span and if they do, add that many holiday days to the result... at least that's what I just considered, though may require more consideration.

thank you for your answer.
If there are any good ideas, thank you.
If you find something here, I will contact you.

2.51/1.55 - The delivery date is showing up everywhere except on the admin confirmation email. Can you tell me which file generates this information so I can update it?

saftek:

2.51/1.55 - The delivery date is showing up everywhere except on the admin confirmation email. Can you tell me which file generates this information so I can update it?

You say the admin confirmation email doesn't have it, so does that mean the customer's version does?

The contents of the email are generated in includes/classes/orders.php in the function send_order_email.

If you are sending html style messages then the applicable /email/ template needs to be updated to present/send the added information. I'm sure there's a FAQ about it, though it's not too complicated if you look at one of the files and compare it's contents with the contents of the above function. Sugest looking at email_template_checkout.html for the order confirmation content.

The admin email generally should look just like the customer's email but have some additional information related to the customer's visit.

I've upgraded from 155d to 155e, have 2.51 installed. Now, the calendar doesn't show up, we have the input box. I've verified all files are in the right place... a couple of times. Database is up-to-date. Image files are in place. Any ideas?

Header_php.php which comes with the 251 version breaks my zc... click checkout and gets a blank screen or 500 error. The older version allows the system to continue, but no calendar etc as noted above.

Are all these "issues" occurring on a single system or are you managing like 3 different stores all of which are experiencing different levels of operation?

As far as the files provided. Unfortunately for the 1.5.5 version, the additional effort was not made to pull the changes out of the base files at the time the update was provided. Therefore, it is important to understand that the modified ZC files provided may not be completely up-to-date with the files on your system. But, the changes made to those files are relatively identified and should be made to the file(s) in your system. It could be that something else on your system made changes to the applicable header_php.php file and when replaced with the calendar version there are problems.

Now, when someone says they are having a problem, the typical next question is what is the problem and back and forth until information is provided. May I recommend book marking the following instruction related to receiving an error, blank screen, pretty much etc... http://www.zen-cart.com/content.php?124-blank-page

The information provided will help much more than "doesn't work" style reports.

If I may put it another way. I'm trying to help based on the information provided. So far there appears to be three different issues that remain unresolved or perhaps they were each individually resolved but there is no discussion about how or why. There's discussion about having upgraded without describing how that upgrade was performed, what else might have been modified, etc... make a lot of changes at once it becomes difficult to identify what the problem is and how it was introduced as compared to incremental changes or planned modifications. Anyways, hope that can sort things out. Right now, my recommendation almost is to reinstall the files from the plugin by merging/verifying present the changes needed to support operation is made/carried over.

Yeah, I reverted back to the original base files and then moved the add-in to replace. I did compare files prior to that, but they were older. I think I am going to have to revert to the base files, then compare the add-in and instead of replacing, merge the changes into the base files. I've had to do that in the past. Cheers

saftek:

Yeah, I reverted back to the original base files and then moved the add-in to replace. I did compare files prior to that, but they were older. I think I am going to have to revert to the base files, then compare the add-in and instead of replacing, merge the changes into the base files. I've had to do that in the past. Cheers

The only thing in the logs is "PHP Fatal error: Call to undefined method payment::process_form_params() in /home/saftek/public_html/shop/includes/templates/custom/templates/tpl_checkout_confirmation_default.php on line 187". I'm trying to track that error down now.

The admin email isn't using the html template and the delivery date isn't being added to that admin email.

saftek:

The admin email isn't using the html template and the delivery date isn't being added to that admin email.
That would be because in includes/classes/orders.php within the function send_order_email, the provided file has two occurrences of $email_txt (or similar variable) both having an equals sign, but only the first occurrence includes the order_delivery_date. This means that when the second occurrence is executed, that the plain text email will not include the order delivery date.

I wish I could remember why it was incorporated in that way, but haven't been able to dredge that memory. Not sure if it related to movement of code from one version to the next, that as is, there is no logic included to omit the delivery date if the site doesn't require it, or what.

That said, today I worked out an observer class to effectively remove the need for any core file edits to where information would only be needed to be incorporated into the override template files and the associated admin screens.

I have something to change regarding the necessity to enter a date and the availability of javascript to improve the customer experience and to extend the observer into the admin's operation, but would expect an update of the plugin relatively soon to be issued.

We have resolved the email problem by making all emails html. BUT: we have the following problems. We have merged all pages into existing pages.

1. calendar isn't showing up on the checkout page.
2. /yourtemplate/templates/tpl_checkout_confirmation_default.php - line 187 - this bit of code

---- . (is_array($payment_modules->modules) ? $payment_modules->process_form_params() : '') ----

breaks the final checkout page and results in error

-----Fatal error: Call to undefined method payment::process_form_params() in /home/saftek/public_html/shop/includes/templates/custom/templates/tpl_checkout_confirmation_default.php on line 187 ----

Any clues on where to go from here would be appreciated.