Shows "Can't Be Canceled"–And Cancels Anyway

Support › Shows "Can't Be Canceled"–And Cancels Anyway
0 Vote Up Vote Down
aksuska Staff asked 3 years ago
It seems to be a cookie issue. To reproduce, make an appointment, purge cookies, then use the cancel link from the confirmation email. It always happens when using an iOS mobile device, but haven't tested Android. Since the cancel happens anyway, it seems like there is some higher level error being triggered and then propagated through successful completion, and erroneously reports an error to the front end, as clearly, it i not the case that the appointment can't be canceled. Any workaround until the bug is fixed?
aksuska Staff replied 3 years ago

To be clear, on iOS you don’t have to purge cookies–it simply fails every time regardless.

2 Answers
0 Vote Up Vote Down
aksuska Staff answered 3 years ago
As it turns out, this isn't a mobile device issue--that was simply coincidental. The issue is that appointment dates are stored according to the local time zone, but date comparisons are done against PHP's time zone, which in our case is not the same. So if the appointment start is close enough, EA thinks the appointment has already started and so gives the "can't be canceled" message. This would have been easier to debug if EA used descriptive error messages. Anyway, I think it is still a bug, though I imagine a tricky one to solve.
0 Vote Up Vote Down
Nikola Loncar Staff answered 3 years ago
Hi, that depends on your settings inside WordPress and hosting timezone settings. Can you please check what are time zone settings on your hosting and inside wordpress settings? Best regards, Nikola
aksuska Staff replied 3 years ago

The WordPress TZ is correct, but it is pretty clear to me that the server timezone for PHP is different. I can’t say what it is because we have a managed account and don’t have access to that info. The server TZ should be changed on Monday, and I will post if that doesn’t fix our issue.

aksuska Staff replied 3 years ago

For whatever reason, changing the PHP timezone didn’t help. At any rate, the code is making a poor assumption about time zone settings, and can easily be fixed. In mail.php, line 251, if you add an explicit time zone, the problem goes away:

if (new DateTime(‘now’, wp_timezone()) > new DateTime($app_data[‘date’] . ‘ ‘ . $app_data[‘start’], wp_timezone())) {

aksuska Staff replied 3 years ago

BTW, your get_wp_timezone() function in the same file looks to just mimic the bult-in WP function, and it will probably be better going forward to simply call the built in function instead.