@cantbutron no, that code isn’t wrong as there is additional logic and conditions around that being used. I have a 1.3.9 release that should get released within the next day or soe which will adjust some issues with the delay and intervals.
As for using the date picker is gets really complicated as the times you can choose depends on the days which would require some significant rewriting of the entire date/time selection and what is stored. I can put it on the enhancements request list and when there is time do some more investigation into the best course for something like this. Thanks!
Maybe you have changed the code, but in the current version that code is wrong. You are using the time interval to calculate the time delay. There is no additional logic or condition to modify the variable $delay_minutes.
For that reason if I have selected a 2h interval and a 12h delay, only the next two hours are blocked instead of the 12 hours that it should be block.
But also thanks for the clarification.
@cantbutron OK, so it I believe I found the error you are talking about:
// Adjust for time delay.
if ( $current_datetime->diff( $pickup_datetime )->i < $delay_minutes ) {
$pickup_datetime->modify( “+$minutes_interval minute” );
}
Thanks for pointing this out, I’ll make the change and hopefully verify and have it in the 1.3.9 release. I’ve opened up the issue on GitHub if you want to track it.
@cantbutron please update to the latest version of the plugin released today. This should resolve this issue.
Hi guy,
I’m overwriting your plugin to display a calendar for date and a select list for hours. I have done that and use the built-in wordpress datepicker. At the moment doesn’t use those values instead of your selection list values, because I’m doing it in my spare time.
Another change that I plan to do is add text fields to customize the text that is displayed (labels, descriptions, etc), basically because in my case I’ll use it for delivery and not for pickup.
If you are interested tell me, give me your email and I contact you privately.
Regards
@cantbutron you fo know that you don’t have to overwrite the plugin to change the labels. The plugin is fully translation ready and you can simply drop in your own English, or whatever translation file to essentially change the labels.
As for implementing the date picker and time dropdown you are more then welcome to fork the plugin and submit a pull request with the changes.
Can you confirm that the delay issue is resolved now? Thanks!
It’s true, I can use translation.
The delay issue is resolved but now you have a new issue/s. This delay is used for all days and not for the next day only and the Open Days Ahead skips all holidays or closed days (Maybe this is intentional, but I think it would be advisable to give the option to skip the holidays or not).
Example:
Settings: Delay 24h, Open Days Ahead 10 days, Start and end time for all days 9:00 to 22:00 and closed weekends.
If I make an order on April 8, 2019 at 11:05, the select list must shows from 12:00 to 23:00 for tomorrow and from 9:00 to 23:00 for the rest of days. Instead it shows every day from 12:00 to 23:00.
In relation to the days shown, in my case it should end on day 17 (without skipping weekends) instead of day 19 (skipping weekends).
I hope this help you.
@cantbutron I’ll test through your example, however the label for days ahead now clearly labels this setting as Open Days. I made this label, and logic, change intentionally because it wasn’t clear an people were reporting different expectations. It makes way more sense for people to set their days ahead and then see that is how many days are presented, regardless of which days are closed. Thanks!
@cantbutron I was also going to caution you about using this plugin for delivery since it was never designed, or intended, to be used that way. There is absolutely no provision for reserving time slots per order. I’d be interested in knowing how you would be in 2 places at once should multiple customer pick the same delivery date/ time. Thanks!
That’s what the client asked me and it’s not my problem :). I suppose they will have several delivery people or something similar. All he wants is to have a record of the approximate delivery time (+- 1h)
@cantbutron I just tested your last example where the following days are all starting at 12:00 instead of 09:00 and I can’t reproduce that. If you are hacking on the code and using your flavor of the plugin then I suggest you recheck what you’ve changed.
In order to troubleshoot this anomaly further I’ll need:
PHP Version
WordPress Version
WooCommerce Version
WordPress Timezone Setting
WordPress Date Format Setting
WordPress Time Format Setting
All Plugin Start/End Pickup Time Settings
Plugin Pickup Time Interval Setting
Plugin Pickup Time Delay Setting (assuming 24 hours)
Plugin Pickup Time Open Days Ahead Setting (assuming 10)
obviously to test the plugin I deleted my code and made a clean install.
It is important to place the order after the opening time, for example, at 10:05. In this case and with the configuration below, all days show from 11:00 to 22:00, instead of showing the first from 11:00 to 22:00 and the rest from 9:00 to 22:00
These are my settings:
PHP Version – 5.6.36
WordPress Version – 5.1.1
WooCommerce Version – 3.5.7
WordPress Timezone Setting – UTC+2 Madrid
WordPress Date Format Setting – j F, Y
WordPress Time Format Setting – H:i
All Plugin Start/End Pickup Time Settings – Monday-Friday | 9:00 to 22:00, Weekends | –:– Unselected
Plugin Pickup Time Interval Setting – 1 hour
Plugin Pickup Time Delay Setting – 24 hours
Plugin Pickup Time Open Days Ahead Setting – 10 days
I’ve been looking at the code and I think the error is in the file class-local-pickup-time.php, on line 505. Here you should check if the variable $first_interval exists or not.
This is your code:
$pickup_dateperiod = ( $pickup_start_datetime->getTimestamp() >= $pickup_open_datetime->getTimestamp() )
? new DatePeriod( $pickup_start_datetime, ( new DateInterval( 'PT' . $minutes_interval . 'M' ) ), $pickup_end_datetime )
: new DatePeriod( $pickup_open_datetime, ( new DateInterval( 'PT' . $minutes_interval . 'M' ) ), $pickup_end_datetime );
And this is the correct code:
$pickup_dateperiod = ( $pickup_start_datetime->getTimestamp() >= $pickup_open_datetime->getTimestamp() && $first_interval )
? new DatePeriod( $pickup_start_datetime, ( new DateInterval( 'PT' . $minutes_interval . 'M' ) ), $pickup_end_datetime )
: new DatePeriod( $pickup_open_datetime, ( new DateInterval( 'PT' . $minutes_interval . 'M' ) ), $pickup_end_datetime );
@cantbutron actually, seeing that you are using an old version of PHP may actually be the issue, because when I ran through that plugin setup on my local PHP 7.3 setup it works as it should. I have a fix that does an explicit check to account for the fact that PHP prior to 7.1 doesn’t support milliseconds for setTime. I’ll confirm on one of my test sites using PHP 5.6. I have the code change ready to go just need to perform some more testing before pushing the release. Thanks!
@cantbutron I’m going to test again in the morning at the time you indicated. As it is right now, running all the same versions you indicated and with the settings you indicated I’m not seeing the time delay issue on my test site.
