Support forumCategory: BugsShows "Can't Be Canceled"–And Cancels Anyway
aksuska asked 7 months 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 replied 7 months ago

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

2 Answers
aksuska answered 7 months 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.

Nikola Loncar Staff answered 7 months 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 replied 7 months 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 replied 7 months 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 replied 7 months 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.