We updated to Amelia v3.2 this morning and since then the recurring bookings seems to no longer work properly.
A customer can book a single appointment with no issues, but if they try to book a recurring appointment, they can get as far as selecting the times and dates for their recurring appointments, enter in their name, email address, phone number, but then they just get a never-ending spinning wheel and the page never loads.
I can see in the browser network console that the request at this point throws a 500 error:
POST /wp-admin/admin-ajax.php?action=wpamelia_api&call=/payment/wc
... and the returned response from the server at this point is:
Slim Application Error
The application could not run because of the following error: Details Type: Error Message: Call to a member function getValue() on null File: /www/php/wp-content/plugins/ameliabooking/src/Application/Services/Reservation/AppointmentReservationService.php Line: 548 Trace
#0 /www/php/wp-content/plugins/ameliabooking/src/Application/Commands/PaymentGateway/WooCommercePaymentCommandHandler.php(92): AmeliaBookingApplicationServicesReservationAppointmentReservationService->getWooCommerceData() #1 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/Handler/CommandHandlerMiddleware.php(71): AmeliaBookingApplicationCommandsPaymentGatewayWooCommercePaymentCommandHandler->handle() #2 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/CommandBus.php(62): LeagueTacticianHandlerCommandHandlerMiddleware->execute() #3 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/Plugins/LockingMiddleware.php(36): LeagueTacticianCommandBus->LeagueTactician{closure}() #4 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/Plugins/LockingMiddleware.php(66): LeagueTacticianPluginsLockingMiddleware->LeagueTacticianPlugins{closure}() #5 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/Plugins/LockingMiddleware.php(45): LeagueTacticianPluginsLockingMiddleware->executeQueuedJobs() #6 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/CommandBus.php(62): LeagueTacticianPluginsLockingMiddleware->execute() #7 /www/php/wp-content/plugins/ameliabooking/vendor/league/tactician/src/CommandBus.php(42): LeagueTacticianCommandBus->LeagueTactician{closure}() #8 /www/php/wp-content/plugins/ameliabooking/src/Application/Controller/Controller.php(107): LeagueTacticianCommandBus->handle() #9 [internal function]: AmeliaBookingApplicationControllerController->__invoke() #10 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/Handlers/Strategies/RequestResponse.php(40): call_user_func() #11 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/Route.php(281): SlimHandlersStrategiesRequestResponse->__invoke() #12 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/MiddlewareAwareTrait.php(117): SlimRoute->__invoke() #13 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/Route.php(268): SlimRoute->callMiddlewareStack() #14 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/App.php(503): SlimRoute->run() #15 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/MiddlewareAwareTrait.php(117): SlimApp->__invoke() #16 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/App.php(392): SlimApp->callMiddlewareStack() #17 /www/php/wp-content/plugins/ameliabooking/vendor/slim/slim/Slim/App.php(297): SlimApp->process() #18 /www/php/wp-content/plugins/ameliabooking/ameliabooking.php(160): SlimApp->run() #19 /www/php/wp-includes/class-wp-hook.php(292): AmeliaBookingPlugin::wpAmeliaApiCall() #20 /www/php/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters() #21 /www/php/wp-includes/plugin.php(484): WP_Hook->do_action() #22 /www/php/wp-admin/admin-ajax.php(202): do_action() #23 {main}
No other site changes have been made so this appear to be a new bug as a result of 3.2; I have read the changelog and there is a small reference to a change involving recurring bookings but no other info.
A speedy resolution would be greatly appreciated as this is significantly impacting our clients, many of whom use recurring booking all the time.
We haven't had any similar reports since the update went life, and we cannot replicate the issue locally, or on our development and staging environments.
Did you try purging cache from your server? Please try that, and if it doesn't work, please provide me a temporary WP-admin (administrator) user for your website where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue.
We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties.
Also, please provide me FTP and database access credentials, so we can check our files and data in the database.
You can write credentials here, just make sure to enable the PRIVATE response, since this is a public ticket.
Does Amelia have a purge cache option somewhere - I haven't found one?
Not quite sure what you mean if not; we don't use any other WordPress caching modules.
If possible I'd rather debug this without providing access for privacy/security reasons (related: would you be willing to sign a basic NDA so we can more comfortably provide you with access to our system?).
I had a bit more of a look; the error in question is occurring on this line in AppointmentReservationService.php
Looking elsewhere in the code, I can see at least one other location where the utcOffset field is set to null (e.g. line 596 of the same file).
I am guessing that there are some instances where it is getting set to null and this line is throwing the Fatal Error because it doesn't have a null check before the getValue().
One other possibly related fact: our WordPress timezone is set to UTC+0 - wondering if something is reading this value as 0 and accidentally converting it into a null somewhere. I sadly don't have a development environment available for this site yet to see if changing the timezone fixes the problem but I'll try and spin one up in the next day or two, but maybe this is something you can test more easily than me.
I was able to reproduce this bug on a fresh Amelia install:
1) Install a new WordPress instance
2) Install Amelia
3) Add a basic test employee/location/service
4) Add a simple bookings page at /bookings with the [ameliasearch] shortcode
5) In Amelia Settings -> Payments, enable the WooCommerce service (note: I did not install the WooCommerce plugin, first time, but tried again with it installed and it still failed).
6) Visit the /bookings page
7) Attempt to make a recurring booking
This triggers the same 500 error on the backend.
I tried changing the site timezone to see if it was related but that didn't fix it - again, it looks like the getUtcOffset() call is returning NULL when it shouldn't be (or there should be some NULL check that isn't occurring).
I have had a quick look for other timezone settings in Amelia that might be relevant here but couldn't see any.
There's a bug when WooCommerce is enabled, and when "Show time slots in client's time zone" is disabled in Amelia's General settings.
Please download the attached file, and replace the file AppointmentReservationService.php in ../wp-content/plugins/ameliabooking/src/Application/Services/Reservation/ folder with the content of that attached file. Delete cache from your website, and test again - it should resolve the issue.
Aleksandar - thanks, that fixes it in my test site. I might wait to see if you're releasing a new patch to correct this before deploying to our Production site - any idea when that might be released?
Hi,
We updated to Amelia v3.2 this morning and since then the recurring bookings seems to no longer work properly.
A customer can book a single appointment with no issues, but if they try to book a recurring appointment, they can get as far as selecting the times and dates for their recurring appointments, enter in their name, email address, phone number, but then they just get a never-ending spinning wheel and the page never loads.
I can see in the browser network console that the request at this point throws a 500 error:
POST /wp-admin/admin-ajax.php?action=wpamelia_api&call=/payment/wc
... and the returned response from the server at this point is:
No other site changes have been made so this appear to be a new bug as a result of 3.2; I have read the changelog and there is a small reference to a change involving recurring bookings but no other info.A speedy resolution would be greatly appreciated as this is significantly impacting our clients, many of whom use recurring booking all the time.
Thanks!
Hello David
We haven't had any similar reports since the update went life, and we cannot replicate the issue locally, or on our development and staging environments.
Did you try purging cache from your server? Please try that, and if it doesn't work, please provide me a temporary WP-admin (administrator) user for your website where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue.
We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties.
Also, please provide me FTP and database access credentials, so we can check our files and data in the database.
You can write credentials here, just make sure to enable the PRIVATE response, since this is a public ticket.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Aleksander,
Does Amelia have a purge cache option somewhere - I haven't found one?
Not quite sure what you mean if not; we don't use any other WordPress caching modules.
If possible I'd rather debug this without providing access for privacy/security reasons (related: would you be willing to sign a basic NDA so we can more comfortably provide you with access to our system?).
I had a bit more of a look; the error in question is occurring on this line in AppointmentReservationService.php
Looking elsewhere in the code, I can see at least one other location where the utcOffset field is set to null (e.g. line 596 of the same file).
I am guessing that there are some instances where it is getting set to null and this line is throwing the Fatal Error because it doesn't have a null check before the getValue().
One other possibly related fact: our WordPress timezone is set to UTC+0 - wondering if something is reading this value as 0 and accidentally converting it into a null somewhere. I sadly don't have a development environment available for this site yet to see if changing the timezone fixes the problem but I'll try and spin one up in the next day or two, but maybe this is something you can test more easily than me.
Aleksander,
I was able to reproduce this bug on a fresh Amelia install:
1) Install a new WordPress instance
2) Install Amelia
3) Add a basic test employee/location/service
4) Add a simple bookings page at /bookings with the [ameliasearch] shortcode
5) In Amelia Settings -> Payments, enable the WooCommerce service (note: I did not install the WooCommerce plugin, first time, but tried again with it installed and it still failed).
6) Visit the /bookings page
7) Attempt to make a recurring booking
This triggers the same 500 error on the backend.
I tried changing the site timezone to see if it was related but that didn't fix it - again, it looks like the getUtcOffset() call is returning NULL when it shouldn't be (or there should be some NULL check that isn't occurring).
I have had a quick look for other timezone settings in Amelia that might be relevant here but couldn't see any.
Hello again David
I forwarded the ticket to one of our developers since I cannot replicate the issue locally. As soon as I hear from him, I will let you know.
If we do need to access your website to further test this, we have nothing against signing an NDA, but let's wait for our developer to get back to me.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Hello again David.
There's a bug when WooCommerce is enabled, and when "Show time slots in client's time zone" is disabled in Amelia's General settings.
Please download the attached file, and replace the file AppointmentReservationService.php in ../wp-content/plugins/ameliabooking/src/Application/Services/Reservation/ folder with the content of that attached file. Delete cache from your website, and test again - it should resolve the issue.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Aleksandar - thanks, that fixes it in my test site. I might wait to see if you're releasing a new patch to correct this before deploying to our Production site - any idea when that might be released?
Thanks
Hello again David
This will be included in our next update, but that won't be released before May 10th. I hope there will be no delays, so it will be implemented soon.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
OK, ta. I assume the update overwrite the local changes I've made so I won't need to manually do anything else?
Exactly, David.
When a new update is installed, it will overwrite all code in the plugin.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables