Checkout Page 3 of 3 waiting for www........

I have a slight problem that my checkout page 3 of 3 is freezing after I press the confirm order, it updates the database and the admin, but the page just keeping waiting ....

This is not a new install (1.2.7d) and has been working fine for weeks , this just started over the weekend. I have contact my web server and they suggest they have no problems?

Could I have a corrupted file in the check process ? Or is there anything else I can check myself.

One reply I got from my host is :-

I've been advised that you appear to have a lot of concurrent connections to your database. This is usually caused when you use the mysq_pconnect method (used by phpMyAdmin).

What I advise to do is to find the php code that contains the connection string and use mysql_connect instead of mysql_pconnect if phpMyAdmin is using the mysql_pconnect method by default.

---

I have removed all files to do with phpMyAdmin, but still the same problem?

Any ideas?? :frusty:

Did your host upgrade the php or MYSQL versions on the server?

I would have to check with them, but the build date from server info is:-
Build Date Feb 19 2007 16:24:37

PHP version:-
PHP Version 4.3.2

Mysql Version:-
MySQL 4.1.18-standard

Which I believe is original.

Ok spoke the host company today and we are not getting any where me thinks!!!!
There has been no up grades to the hosting, I have used the advice in the wiki to speed the site up, but this makes no difference.
It is just at this stage that the page freezes!( I can add products to the cart etc) I tried a test first thing this morning and the order went straight through, then did another one a few minutes later and again the page then froze.
Is it me or is this an hosting issue or my PHP files ?

This exact thing has started with my store as well. It appears that it started yesterday.

Every time something is submitted, the store seems to hang. It happens when a lost password request is made as well.

Multiple orders also seem to be generated that are not a result of the user re-trying.

What's going on? Everything has been fine for months and months, now this out of the blue?

Is it IXWEBHOSTING by any chance?

Randy

I forgot to mention...even though the order goes through and is listed in the users information, the shopping cart is never cleared.

Is anyone else experiencing this?

Randy

What Payment method is being used?

Sounds like it is not coming back to the correct file after checkout_confirmation ...

Also check the settings of the file:
/includes/languages/english/html_includes/your_template_dir/define_checkout_success.php

Make sure the file exists and is at least: 644

Ajeh:

What Payment method is being used?

Manually processed CC's

Sounds like it is not coming back to the correct file after checkout_confirmation ...But it also does this when a "lost password" request is made.

Also check the settings of the file:
/includes/languages/english/html_includes/your_template_dir/define_checkout_success.php

Make sure the file exists and is at least: 644I just checked it out and it's there and the permissions are set correctly.

Anything else to check? What could make it suddenly start doing this after so long without issues?

Thanks for the help.
Randy

gremlins ... :eek:

If you browse through your directories with FTP ... do you see any files that have changed dates recently that you have not touched?

Also ... anything about your email change lately on your server?

Does your Contact Us still work?

Another discovery....Emails sent through the contact page also makes the site hang as soon as the send button is clicked. It all seems to be related.

Randy

You have an email issue ...

Ask your site if anything changed concerning email on your server ...

Try switching to PHP in the Configuration ... Email Options ...

E-Mail Transport Method
Defines the method for sending mail.
PHP is the default, and uses built-in PHP wrappers for processing.
Servers running on Windows and MacOS should change this setting to SMTP.

SMTPAUTH should only be used if your server requires SMTP authorization to send messages. You must also configure your SMTPAUTH settings in the appropriate fields in this admin section.

sendmail is for linux/unix hosts using the sendmail program on the server
"sendmail-f" is only for servers which require the use of the -f parameter to send mail. This is a security setting often used to prevent spoofing. Will cause errors if your host mailserver is not configured to use it.

Qmail is used for linux/unix hosts running Qmail as sendmail wrapper at /var/qmail/bin/sendmail.

PHP
sendmail
sendmail-f
smtp
smtpauth
Qmail

It does sound that way. But PHP isn't an option in the version I am running. Sendmail is currently the method used, and I don't think SMTP works either (although I'm not sure I have it configured fully)

FWIW, the email did finally come back as "sent" through the website..after 4 minutes :sadwalk:
Is the store software just timing out before sendmail indicates success?

Thanks again,
Randy

Just verified that the emails are the hitch. I just turned off email sending and the store works fine.

I guess I need to go after the ISP now.

Thanks again for helping me figure out where to look.

Randy

You are most welcome ... thanks for the update!

Update - My problem seems to have been a hosting issue after badgering my hosting company the issue seems to have been resolved but it took some working at them as they would not accept it was a hosting issue:frusty:

I can't seem to get the attention of the ISP for some reason.

I tried changing the send method to SMTP and it did work, but still has the same problem. I'm assuming a bottleneck at the ISP between the server the store is located on and the email servers. I can use my site's SMTP servers fine from my home system, so barring this bottleneck, I am at a loss as to what the problem could be.

Is there anything that ZC does at mail time that could be taking so long? Difficulty in creating a temp file somewhere? Anything else I can look for?

Thanks,
Randy