Support » Plugin: Transdirect Shipping Plugin for Woocommerce » Activating causes cURL timeout error

  • Hey guys! Great plugin! Nice layout on the shop pages. I truly hope you service Mackay in NQLD, it will make the troubleshooting effort worth my while!

    I’m seeing connection issues and I’m not sure if it’s my server, WordPress, Jetpack, Woo Commerce or this plugin. Since TransDirect uses the Rest API, I presume Jetpack has to be connected to WordPress however, as soon as I activate TransDirect I get the following:

    Site Health > Critical Issues
    Rest API
    Error: [] cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received
    Loopback
    Error: [] cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received

    I have deactivated all other plugins (inc payment gateways), it’s only happening when TransDirect is activated.

    Should I be seeing (or have setup) any webhooks in WooCommerce? It’s difficult to work out where to go with troubleshooting from here.

    If you don’t service Mackay, then by all means please let me know and save us both a headache 🙂

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter ozcoolie

    (@ozcoolie)

    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.

    Hi Ozcoolie,

    The issue appears to be your servers timeout limit set for cURL responses.
    When you request a quote from our services we will in turn request a real time quote from our carriers.
    Unfortunately this can at times take between 10-20 seconds for a response to be returned from some of our carrier partners.
    We are currently working on a method to increase the response time of our quotes independent of our carrier partners however in the mean time I recommend having this limit increased to 20 seconds on your website.

    Thread Starter ozcoolie

    (@ozcoolie)

    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?

    Hi @ozcoolie

    A few extra features the plugin offers may be causing the issue compared to just the live quotes.
    The plugin will sync your stores inventory with your members area and also attempt to sync new customer orders.
    Potentially one of these processes is what is triggering the delay.
    I will see if we can get some options added to our plugin to disable these features in the instance that this may be occurring.

    Thread Starter ozcoolie

    (@ozcoolie)

    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 🙂

    Thread Starter ozcoolie

    (@ozcoolie)

    @tdreece Jeepers! that was a quick reply. Thanks for the feedback on the built-in Rest API… much appreciated. I will go ahead and implement your suggestion as it would be tragic if timeouts occurred at the front end.

    Thread Starter ozcoolie

    (@ozcoolie)

    @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 2 years, 2 months ago by ozcoolie.

    @ozcoolie your understanding of the various states is correct, anything that has reached the ‘confirmed’ state has been booked successfully with a courier however does not have any tracking scans to indicate collection.

    The ‘booked_by’ field is an option we provide during booking that can be manually selected so we know at a glance who is responsible for the shipment. This is not so much an issue for our customers with account numbers however as our service can be used on an ad-hoc basis without an account we need to have it specified.

    With sending items out from your store to one of your customers, the ‘booked_by’ field value should be set to sender. The value of this field does not impact the status of the booking as far as payments are concerned.
    A booking will only be prevented from reaching ‘Confirmed’ due to payments if the payment method on the account is set to a prepaid method, such as paypal/credit card, if the payment fails. If your account is set on a post-paid credit account, payment is not required immediately so the booking will progress to confirmed.

    I appreciate your quick response after increasing the cURL timeout and I have passed this on to our developers.

    Thread Starter ozcoolie

    (@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?

    Thread Starter ozcoolie

    (@ozcoolie)

    Also.. FYI: the demo data returned by Apiary generates json_decode errors in PHP. json_last_error reports “JSON_ERROR_SYNTAX” which I believe to be missing array brackets around nested arrays, for example:

    
            "quotes": {
                "toll" : {
                    "price": 47.87,
                    "insured_amount" : 0,
                    "service_type": "road",
                    "transit_time": "1-2 days" 
                },
                "allied" : {
                    "price" : 56.97,
                    "insured_amount" : 0,
                    "service_type": "road",
                    "transit_time": "1-2 days"
                },
                "couriers_please" : {
                    "price": 53.65,
                    "insured_amount" : 0,
                    "service_type": "road",
                    "transit_time": "1-2 days"
                }
            }
    

    … should contain square brackets ie "quotes" : [{...}, {...}]

    I’m not sure if this is related to the cURL hang, but thought to mention it anyway.

    Thread Starter ozcoolie

    (@ozcoolie)

    @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 😮

    Plugin Author transdirect

    (@transdirect)

    Hello @ozcoolie,

    We apologize for any inconvenience.

    Can you please provide me your email address so our support team will contact you to get more information about your website so we can look in to the issue you are facing.

    Thank you.
    Transdirect Support Team

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘Activating causes cURL timeout error’ is closed to new replies.