• Resolved lionit

    (@lionit)


    Hi, I’m 100% confident that is a dumb issue, but I’m being unable to resolve this problem.

    I can’t make the late-booking system work properly.
    I’m developing a website for an Italian friend from Australia, but looking at the php source it seems that uses only UTC references, so this shouldn’t cause any issue.

    Anyway my local test server is configured for Melbourne time and I’ve double checked it setting the local time both through .htaccess and php.ini files.

    The late booking doesn’t work consistently, often displaying the late booking error (currently set at 30 minutes) even when selecting a time amply after this margin.

    Also I’ve never seen the “bookings can not be made in the past” error and maybe the issue is in how the if in line 232 of booking.class is conceived.

    The test website is antenati2.tk should you wish to give a look at it.

    Thanks in advance for your help!

    https://wordpress.org/plugins/restaurant-reservations/

Viewing 15 replies - 1 through 15 (of 16 total)
  • Hi lionit,

    This is probably an issue with the timezone. If you go to your general WordPress Settings page, what is the timezone set to?

    If the timezone is set correctly but you’re still having problems, it could be that one of your plugins or themes is overriding PHP’s default timezone. You can trouble-shoot this by disabling your plugins one-by-one and testing. If you don’t find anything there, try switching to a default theme, like TwentyFifteen, to see if that fixes it.

    Thread Starter lionit

    (@lionit)

    Hi Nate,

    thanks for your answer. Correct timezone from WP double checked.
    I did a few experiments in the local test environment, disabling all plugins and reverting to Twelve Fifteen with very basic edits on index and footer templates to make everything is needed to show up.

    As you can see here the issue about “bookings can not be made in the past” is still there. https://drive.google.com/file/d/0B-zq4G1enD3uTjFoZ1Noa3ZVdDQ/view
    The current if cycle disables it entirely if a late booking limit is inserted.
    I know that this is a small detail, but it may be nice to nest another if there to send a specific message telling that a time in the past has been selected AND that the booking has to be X minutes in advance. It would offer added feedback to an user that, for whatever reason, is selecting a wrong time.

    About the late booking, it is working correctly now on the local test environment with all plugins and theme on, but the result has been unreliable before and the whole code seems to be spotless for me…I’m still puzzled.
    Will try to collect more info and offer you a detailed report should it misbehave again on the test or production server.

    Thanks for your help!
    Alessandro

    Thread Starter lionit

    (@lionit)

    Just an update,

    I’ve tested it on the online Australian server I use.
    To filter out some variables I’ve disabled the late booking option.
    I have also disabled all the other plugins and reverted to Twelve Fifteen theme with only the most basic edits to show the results.

    I’ve configured, through .htaccess file on that share, the Time Zone for php.ini and the Server Time Zone to Rome.
    Wordpress is set up to use Rome Time Zone.

    Now comes the fun, please look at the following images
    Not working case
    First working case
    It seems to compare the time to a reference 11 hours ahead (the current deviation from GMT time for Melbourne), ignoring the WordPress locale settings, any other settings or even the server time (going an hour ahead of it; changing it centrally through command line doesn’t bring any effect too).

    If the current time is 7 (Rome Time) I would have to go at least 11 hours ahead of that, or 1 hour ahead of the current Melbourne time, to 18 to make it accept the input.

    I have tried both with the old, working installation (and database) from my local test environment and with a fresh one.

    My, limited, understanding is that the used code is already based on the UTC time (as it should be to avoid this kind of troubles), so why it doesn’t work is a mystery to me to date.
    All I know is that it does ignore the WordPress settings anyway.

    I need to fix that as I’m not sure where the server that will host this website will be geographically located (or even if it will have to stay on my server), so if there is an issue with this kind of setup I need to track it down.

    I will try again with another fresh installation later.
    In the meantime, thanks for your help!
    Alessandro

    Hi Alessandro,

    You should not be setting the timezone in the .htaccess file or the php.ini file. WordPress manages the timezones itself and modifying PHP’s default timezone can disrupt WordPress’s times. The only place that you should adjust the timezone is under the main Settings page in your WordPress admin.

    The current if cycle disables it entirely if a late booking limit is inserted.
    I know that this is a small detail, but it may be nice to nest another if there to send a specific message telling that a time in the past has been selected AND that the booking has to be X minutes in advance. It would offer added feedback to an user that, for whatever reason, is selecting a wrong time.

    The plugin does provide separate error messages if a booking is invalid because of the Late Bookings option. If you’re getting a message that it’s in the past, but it’s not, then there is a timezone conflict going on. The error message for bookings in the past is only triggered by a simple check against current_time().

    Thread Starter lionit

    (@lionit)

    Hi Nate,

    the issue is still present even after removing the .htaccess and restarting the server (UTC setting confirmed again by phpinfo).
    Last try

    I have edited the .htaccess previously in the effort to remove the possible issues caused by the server based in a different timezone. But as you can see in the screenshot the result of current_time(‘timestamp’) is, and has always been, coherent with the settings on WordPress.
    I cannot understand from where this issue originates.

    Thanks,
    Alessandro

    Hi lionit,

    Since you seem comfortable working with code, here is something you can do to test exactly what times the plugin is comparing.

    Open up /wp-content/plugins/restaurant-reservations/includes/Booking.class.php and find the following line:

    'message'	=> __( 'Sorry, bookings can not be made in the past.', 'restaurant-reservations' ),

    Modify this line so that the times being compared are displayed:

    'message'	=> $request->format( 'Y-m-d H:i:s' ) . '/' . date( 'Y-m-d H:i:s', current_time( 'timestamp' ) ) . __( 'Sorry, bookings can not be made in the past.', 'restaurant-reservations' ),

    The find the following line just a bit lower:

    'message'	=> $late_bookings_message,

    Replace it with the following:

    'message'	=> $request->format( 'Y-m-d H:i:s' ) . '/' . date( 'Y-m-d H:i:s', ( current_time( 'timestamp' ) + $late_bookings_seconds ) ) . '/' . $late_booking_sections . $late_bookings_message,

    Once you do that, you’ll see the following. If the “bookings not made in past” error is triggered, it will show you the date and time that the plugin thinks your booking is at, and the current date and time the plugin thinks it is.

    If the late bookings error is triggered, it will show you the date and time that the plugin thinks your booking is at, the date and time the plugin thinks is the late bookings cutoff, and the number of seconds it thinks is your late bookings setting.

    That should at least help us pinpoint what the server is thinking, which will hopefully help us track back to the source of the problem.

    Thread Starter lionit

    (@lionit)

    This is what I was trying to do, but my ancient C++ skills required me more headbanging on this php code…
    And the result is…AH! I would have never thought at that! That small date function seemed so innocent and straightforward on its own.

    Basically the issue was on the formatting made by the date function to the timestamp. It formatted the timestamp obtained adding the full GMT offset of the server (+11).

    As a quick workaround I’ve used
    date_default_timezone_set(‘Europe/Rome’);
    on top of the file and it did the trick (also for the other output on the page footer, so it works globally on the php instance it seems).

    But it is not a pretty solution in my opinion and, while it may be made “portable” simply using a variable that extract the time zone from wordpress configuration, I think that something should be resolved elsewhere, either using a different function to format the date or fixing the root problem on the date function.

    Thanks for helping me reach the root!
    Alessandro

    Hi Alessandro,

    You should not use date_default_timezone_set(). In the context of WordPress this is extremely dangerous, and will break functionality of other plugins and even can break WordPress core.

    Deep in the bowels of WordPress, it sets the default timezone to GMT and then offsets itself everywhere based on the setting in your WordPress settings area. As a result, all other plugins and themes that are coded properly will use current_time( 'timestamp' ), which acts as a wrapper for time() to output the correct time based on WordPress settings.

    When you adjust date_default_timezone_set(), you break the output of current_time() for all plugins, themes and WordPress itself.

    This is really a problem with your server configuration. I’m afraid I’m not that familiar with how to go about resolving it, but it looks like the timezone is getting offset in a way that is undermining the normal operation of WordPress (and this plugin).

    Can you tell me exactly what the output of the error messages with the added code? Can you also go to Settings > General and tell me what the timezone is set to there? Maybe this will give me a clue to point you in the right direction.

    Thread Starter lionit

    (@lionit)

    Hi Nate,

    here are the last shots about the info you asked.
    Error displayed

    Settings>general

    Later I will try to scout on the interactions between the date function and the server settings; at least now I know from where everything starts. In the meantime any further pointer is greatly appreciated…and thanks for your passion!

    Thanks,
    Alessandro

    Hi Alessandro,

    So, it looks like the settings are showing the time around 12:25, but current_time() is outputting a time of 23:13. Something is interrupting the time.

    Now that you’re displaying the debug info, it might be interesting for you to try the plugin deactivation and theme switching thing again. See if you notice the time jumping around at all.

    Thread Starter lionit

    (@lionit)

    Hi Nate,

    Theme switching doesn’t change anything.
    Disabling your plugin (the only one left activated during all the tests) doesn’t bring any appreciable result.

    Look at the result

    It seems that date likes to add the Timezone offset for whatever reason…on my server at least.

    Note that maybe using gmdate instead of date could help resolving the problem without going to modify things on the entire php environment. Let me know what do you think about it.

    Thanks,
    Alessandro

    Hi Alessandro,

    What is the code you’re using to produce the date there? You’ll notice the timezone offset doesn’t appear in any of the code I showed before when using date().

    I don’t think that your server’s default timezone should cause a problem. I have servers in different timezones. It’s only the php.ini or modifying the datetime at runtime that I think would cause the issue. Perhaps also a .htaccess file. I’m not sure.

    Sorry, I’m running out of ideas here.

    Thread Starter lionit

    (@lionit)

    Hi Nate,

    this is the best part of our job…isn’t it? 🙂

    I only added an <?php echo get_option(‘gmt_offset’); ?> exclusively on the footer to understand if WP was taking the correct offset (and it does).

    I should remove it indeed, now that we’ve pinpointed the issue.

    php.ini is fine (set to UTC, double checked it from the central server /etc/php.ini and through a phpinfo file) and I’ve deleted the .htaccess, restarting the Apache service.

    The datetime at runtime is fine too, I’ve removed that as you instructed previously (even if that workaround did the trick for your plugin). Honestly…I cannot think of what may be causing the issue and I’m actively searching for it.
    But I know that gmdate() seems to output the correct time on a test string and that WordPress config page is able to display the correct time as you’ve seen, so the issue is confined to date().
    I think that switching all the date() to gmdate() should be fine for me here and should not cause havoc on other plugins or WP core, but I’ll wait your opinion prior to commit the change.

    Thanks,
    Alessandro

    Hi Alessandro,

    Where were you thinking of switching date() to gmdate()? I don’t actually use date() very much in the plugin. But I do make heavy use of PHP’s DateTime objects.

    Thread Starter lionit

    (@lionit)

    Hi Nate,

    ok, the issue is that my server clock was configured on AEST time (+11).
    Now I’ve forced UTC time on it and everything is solved.

    I was totally convinced that PHP functions did not care about that and would exclusively follow the php.ini, but it seems that it is not always the case.

    Actually I had another funny output on:
    echo date_default_timezone_get() . ' => ' . date('e') . ' => ' . date('T');
    as it gave me UTC => UTC => EST

    Thanks for the time you spent on this.
    I will leave to you the marking it as resolved in case you need to add further pointers for others.

    Thanks,
    Alessandro

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Late booking error’ is closed to new replies.