Connection Timeout on order submission

  • Posts: 71
  • Thank you received: 1
8 years 7 months ago #237605

-- url of the page with the problem -- : applevalleycountrystore.com/gift-shops-townsend-tn
-- HikaShop version -- : 2.6.2
-- Joomla version -- : 3.5.1
-- PHP version -- : 5.6.15
-- Browser(s) name and version -- : all
-- Error-message(debug-mod must be tuned on) -- : No error - connection timeout

This issue appeared when we updated hikashop to work with Joomla 3.5.1

- I add item(s) to my cart, and continue to checkout.
- I fill out the checkout form (with either a new or previously used email address), and click 'next'
- At the next screen I am shown confirmation of the order we're preparing.
- I click finish.
- expected behavior: order is submitted and confirmed as usual
- actual behavior: the browser times-out while attempting to make the connection.

Before updating, we saw the error message that came from the Joomla 3.5.1 update after clicking the same button. Now we see nothing :)
Any idea what would cause this?

Thanks!!!!
[checkout config attached]

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 82906
  • Thank you received: 13378
  • MODERATOR
8 years 7 months ago #237607

Hi,

A connection timeout doesn't help much.
What payment method are you using and how did you configure it ?
Could you look in the server's PHP error log for any "fatal error" message related to the issue ?

Please Log in or Create an account to join the conversation.

  • Posts: 71
  • Thank you received: 1
8 years 7 months ago #237728

There is no php fatal, as the timeout occurs before the req hits the php. I tested my logfile with an intentional fatal error: require("foo.bar");, which logged as expected.

I can't run XDebug on the prod server - unfortunate :). I did slip this piece of code into the top of several key files:

$out = fopen("/home/user/public_html/test_hika.txt", "a");
fwrite($out, __FILE__.":".__LINE__);

This, of course, is logging the application's progress. The last entry in it the file points me to /components/com_hikashop/views/checkout/tmpl/confirm.php. That file's complete content is attached. Is this correct? It's empty, except for the JEXEC check.

Our only payment method is Authorize, and its config is attached as well (two screens).

Thanks for your input!

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 71
  • Thank you received: 1
8 years 7 months ago #237729

If it means anything to you, this is the complete flow file content. It shows the tracked files that did execute.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 82906
  • Thank you received: 13378
  • MODERATOR
8 years 7 months ago #238112

Hi,

So, from what I understand, there is something doing a request somewhere when the order is created.
So it's likely to come from a plugin, either a hikashop or a system plugin or the payment plugin.

It will require working step by step to flag the source of the problem:
- try with another payment method: bank transfer and then paypal.
If there is no problem with either, it means that the problem is with the Authorize.net plugin.
Otherwise, it's something else.
- try with the default template of joomla (an override could be linked to the conflict)
- try after disabling the mass action plugins (maybe it comes from a mass action ?)
- try disabling other plugins one by one and test each time if you have the problem.
Once the source of the problem is identified, it will already be easier to understand what's going on.

Please Log in or Create an account to join the conversation.

  • Posts: 71
  • Thank you received: 1
8 years 7 months ago #238135

Got it squared away. It was an issue with the SMTP connection, and when I switch the site mailer from SMTP to PHPMail, all seems well.
The issue may be compounded by our server's csf security suite, because the workflow worked like a charm when I mirrored it to a vagrant box. step 2: I edited my hosts file to point the domain name to the IP directly, eliminating cloudflare from the equation. Running like this (on the live server - not the vagrant box - and pointing around cloudflare) I was able to let the page spin for about 5-10 minutes before it finally gave me a site-level error message with real clues.

The following user(s) said Thank You: nicolas

Please Log in or Create an account to join the conversation.

Time to create page: 0.073 seconds
Powered by Kunena Forum