webhook

Hi Alessandro,

it is pretty strange that the plugin suddenly stopped to execute the webhooks without any updates. This bring me to think that something changed at server level, such as an update of the PHP version or something similar.

The only way to understand why the system doesn’t execute the webhooks anymore is by debugging the code step by step.

The webhooks are collected and dispatched by the VAPWebHookQueue class, which is declared by this file: /wp-contents/plugins/vikappointments/site/helpers/libraries/webhook/queue.php

The webhooks are collected through using the register method. All the registered webhooks are dispatched by the destructor of the class, which is automatically invoked when the garbage collector is up to destroy the resources stored within the server memory.

You could edit the __destructor method and insert at the beginning a line of code to check whether the latter is ever invoked. Something like:

file_put_contents(dirname(__FILE__) . '/log.txt', print_r($this->queue, true), FILE_APPEND);

Afterwards, you can try to trigger the webhook with the related action (don’t know what kind of webhook you are using).

At this point, near to the queue.php file you should now be able to see a log.txt file. You can try to open it to check whether any webhooks have been properly registered.

If you don’t have enough PHP knowledge to debug this issue, I strongly recommend you to get in touch with us from the technical support of our website.

Hi,
thank you for your help.
I modified the __deconstruct and I got the log.txt file.
But, the content didn’t say a lot.
For each status change I got:

Array
(
)

Today I got 3 reservation, but only 1 called the webhook.
It seems a random behavior. Obviously NO changed was made to the site.

Have you some other tips? ??

Many thanks
Alessandro

• This reply was modified 2 years, 5 months ago by Alex.

Hi Alessandro,

we tested the webhooks on our development environment and every time we received a reservation, or the status changed, the system delivered the payload to the URL specified within the configuration of the webhook. We used a webhook with the following configuration:

• Action = Appointments – Status Change (onStatusChangeReservation);
• Statuses = none (in order to observe any status);
• Loading Mode = basic.

In case you configured a webhook with the same action (appointment status change), you can easily switch status from the back-end to immediately see whether the webhook is triggered or not.

Unfortunately I haven’t other hints for you. If you are not able to sort out the issue, I can only suggest you to provide us with a login to the back-end of your WordPress, so that we can debug the code on your website. If you wish to follow this path, please contact us from the technical support area on our website.

Hi,
thank you for your great support.
Unfortunately there are no other evidence about the problem.
It could be, but it’s just my guess, an overload on the shared infrastructure.
I’m convinced to change provider asap, because too many time I noticed random malfunctioning.

Many thanks and 5 star.