Activating causes cURL timeout error

Hello again. I’m wondering if anybody has looked at this yet?

I spoke with my hosting company and they’re pretty sure the TransDirect plugin is “superceding the expected cURL output”. They wrote:

“Upon investigation we were not seeing any error logging server-side which would denote a configuration error (such as a timeout or a bad request that can be addressed by us), nor are we seeing any logging in mod_security that mentions a block of any particular API requests for your website.”

Again, if you don’t service Mackay, then just say so and I’ll mark the issue as resolved.

Thank you for your response @tdreece.

I will definitely implement a longer timeout as I can clearly understand how this might occur if a visitor is completing an order at the front end, however this is happening at the back end as soon as the plugin is activated. The only API request being made at that point (I believe) is authentication, is that correct?

To test some theories, I used Apiary to write my own API plugin to see how quickly authentication executes – the response is almost instant.

As the shop is not live yet we don’t have any bookings, so API requests for bookings returns an empty array – again almost instantly. I fully expect booking responses to slow down somewhat once we have some to return.

I haven’t dug around your plugin code, but I’m just wondering if it’s interacting with the built-in Rest API. It seems to me that by by-passing the Rest API, my test plugin is the fastest loading page in admin to date.

Is it possible the built-in Rest API is slowing things down?

Also, while I’m on the topic of the Transdirect Public API… Since I have gone to the effort of creating a plugin, I figure I might as well use it to generate an overview such as that shown on your dashboard page.

The Bookings section says the list of all possible Statuses are: quoted, booked, paid, pending, confirmed, cancelled, picked_up, in_transit, delivered, error. I have a few questions regarding these statuses.

1) Assuming the list of statuses provided is in the exact order that events occur, is it safe to also assume:

• Awaiting Pickup is anything that has reached a status of “confirmed” (excluding “quoted”) and
• In Transit is anything that has been “picked_up” or is “in_transit”
• And “delivered” means the customer has received the shipment

2) Given that much is correct so far, and presuming everything booked via the storefront, is “booked_by” and “paid” by the receiver, is it also safe to assume that any outstanding payments/invoices (that we need to pay) are those where the “booked_by” value is “sender” and the status has progressed beyond “booked” but has not yet reached a status of “confirmed”?

I realise this is a heck-of-a-lot of assuming and we all know what they say about ASS-U-ME, so I would appreciate confirmation and/or correction 🙂

@tdreece

While not an optimal solution since I serve this particular website as an add-on domain – increasing cURL timeout to 20 secs server wide did not resolve the issue (also tried 30 secs just for the purpose of the exercise).
Error: [] cURL error 28: Operation timed out after 30001 milliseconds with 0 bytes received

An optimal solution for my situation is to hook into the WordPress filter “http_request_args” in the subdomain’s MU plugin:

function oz_debug_url_request_args($r, $url){
        $r["timeout"] = 30;
        return $r;
}

However, this did not resolve the issue either
Error: [] cURL error 28: Operation timed out after 30001 milliseconds with 0 bytes received

If the Transdirect plugin were using PHP for HTTP requests, I could add:
curl_setopt($curl, CURL_TIMEOUT, 20000);
.. since it’s only the Transdirect plugin that needs it. As my own test plugin uses PHP, this works as expected although I’m beginning to suspect it would not resolve the particular issue in question.

Without having written the Transdirect plugin, I’m at a loss as to how I could be of more assistance in isolating the cause. But please feel free to hit me with suggestions if you have any. Happy to help 🙂

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

@tdreece Thank you for confirmation and clarification regarding the public API.

I decided to place an order to see if the cURL timeout is impacting the front end at all – it responded perfectly and without mishap as I typed an address. I can see the resulting order in the members dashboard on your website and all the details are correct.

However, my API call for all bookings is still returning an empty array. And Apiary is still producing demo data, not the booking, even when I provide the booking ID. The only call that is returning the expected data is getting the currently authenticated member.

And, while great at the front end, the Transdirect plugin doesn’t do much at the back end. I can see the booking ID and user-selected courier in custom fields and that’s it. How do customers track their orders if not status updates via Woo Commerce?

Would I be correct in assuming: if I want more functionality I’ll have to use the public API?

@tdreece Just discovered this cURL timeout issue is impacting the front-end, but only on Firefox for mobile (so far).

Went through the entire process of disabling all other plugins again and it’s only happening with Trandirect plugin enabled. FF doesn’t report it as a JS error or anything, it simply fails to load any CSS at all so it looks to be happening quite early in the load sequence.

We went live the very day it was discovered, might have jumped the gun a bit 😮