Status Change Of A Order Taking Long Time

We have recently seen a delay in the status change operation for any order, its taking more than 30 sec to change the status. Any ideas what could be the issue. Earlier this was working fine.

We have recently seen a delay in the status change operation for any order, its taking more than 30 sec to change the status. Any ideas what could be the issue. Earlier this was working fine.

Are there any 3rd party modules which have actions on order status change? Try to temporary disable them

We have recently seen a delay in the status change operation for any order, its taking more than 30 sec to change the status. Any ideas what could be the issue. Earlier this was working fine.

Try to clear the Notify customer and Notify orders department check boxes when changing the order status and check the results.

Try to clear the Notify customer and Notify orders department check boxes when changing the order status and check the results.

Yes that resolved the issue. How do we fix this now since emails are mandatory to be sent to customers and orders department ?

Yes that resolved the issue. How do we fix this now since emails are mandatory to be sent to customers and orders department ?

Check/fix your email settings. The sending of mail is timing out.

Unable to find what to fix. The settings are same only. How do we really confirm its the email timing issue since we are able to send and receive the emails through outlook for same SMTP and it works fine.

Go to your site and send yourself something via the contact-us form. If there is a long delay then email is your culprit.

If not, then you would have to debug/diagnose which takes time and experience.

Go to your site and send yourself something via the contact-us form. If there is a long delay then email is your culprit.

If not, then you would have to debug/diagnose which takes time and experience.

The mail went quickly through the form , but if we go through the admin panel and change status of order with email notifications off it goes quickly but if its ON then it takes almost 2 minutes. Not sure whats the reason.

Could be any number of things ranging from https to firewall issues at your SMTP host.

Assuming you are using SMTP for mail versus sendmail or php mail. Your hosting will be the most effecient at helping to track this down.

It could also be that you have a bad address in your admin notifications versus the single email address for contact-us on the customer side.

And it could be a hook (or other interception) that only runs in the Admin context.

Finally found that changing 'C' to 'A' in last line of app\functions\fn.cart.php sends the email immediately.. Dont know what the repercussions are for this ?

            Mailer::sendMail(array(
                'to' => $order_info['email'],
                'from' => 'default_company_orders_department',
                'data' => array(
                    'order_info' => $order_info,
                    'shipments' => $shipments,
                    'use_shipments' => $use_shipments,
                    'order_status' => $order_status,
                    'payment_method' => $payment_method,
                    'profile_fields' => $profile_fields,
                    'secondary_currency' => $secondary_currency,
                    'take_surcharge_from_vendor' => $take_surcharge_from_vendor
                ),
                'tpl' => 'orders/order_notification.tpl',
                'company_id' => $order_info['company_id'],
            ), 'C', $order_info['lang_code']);

to

            Mailer::sendMail(array(
                'to' => $order_info['email'],
                'from' => 'default_company_orders_department',
                'data' => array(
                    'order_info' => $order_info,
                    'shipments' => $shipments,
                    'use_shipments' => $use_shipments,
                    'order_status' => $order_status,
                    'payment_method' => $payment_method,
                    'profile_fields' => $profile_fields,
                    'secondary_currency' => $secondary_currency,
                    'take_surcharge_from_vendor' => $take_surcharge_from_vendor
                ),
                'tpl' => 'orders/order_notification.tpl',
                'company_id' => $order_info['company_id'],
            ), 'A', $order_info['lang_code']);

The 'C' and 'A' determine what AREA to look for the template (Customer (frontend) or Admin (backend)).

I'm going to guess that you have some third party addon that massages/manages customer invoices (I'm basing this on the statements that Admin templates work as well as customer contact-us, but customer order invoices/notifications are slow). What you've done with your change is to send the Admin version of an invoice/shipment notification to the Customer. I'm not sure you really want to do that since it could contain information that should only be seen by the Admin/Vendor.

Thanks for the detail found the culprit .tpl file. :grin:

Thanks for the detail found the culprit .tpl file. :grin:

And it was...?

it was one of our custom code change .tpl file

I had this issue where cs cart status changes and checkout were taking 120 seconds. Yet other email sent with mail() was working fine, so the issue was not mail(), but actually something else.

I debugged this in the cs cart php internals, and eventually found that cs cart embeds the images directly in the notification emails. It was failing to be able to make an http connection to the site to download and embed those images and reaching the 60 second timeout 2 times before returning to the user.

The reason for the failure was my firewall / virtual machine configuration doesn't allow connecting to the IP in the public DNS because I have some of it behind NAT and I'm using port forwarding.

I added the domain to the system's hosts file with 127.0.0.1 in front of them and it was able to connect to the site again and go very fast. You also have to bind the web server virtualhost to all ips for this to work since it would need to be able to listen on both the local ip and the public ip.

I spent hours trying to figure this out. Just want to help if anyone else runs into this issue. This was the only relevant post I found about this on the Internet. If you still have the problem, try making an http connection inside the server to the web site. If that fails, you could work on fixing that.

I believe the only offsite requests done like this are for PDF documents. Not sure about the new editable mail template mechanism, but the original template based email does NOT do any offsite requests for any processing/formatting. Everything is done within your site.

Can you be more specific about what email you were generating and which email (old or new) method you have your site configured to use?