Wrong Attributes on Order

[kuroi]

I doubt that this is about the speed of your server or the volume your processing. At Kuroi we have who clients whose sites peak at over 100 orders an hour and we've never seen the problem you're describing, let alone with a 10% error rate.

Each customer's order details should be held in a separate php "session" and if the server were overloaded all that should happen is that everything slows down and grinds to a halt, not that information from one visitor's session becomes available to another.

This sounds to me like a candidate for problems with how php has been configured on your server, rather than the Zen Cart application code.

But you'd need somebody with more expertise in that area than me, to comment further. It might help though if you could post some information about your server, php version, and how php is configured to run on the server.

[BlindSide]

Seconding Kuroi's observations, we definitely need more info...

1. Tell us about your server setup. Is it shared hosting, VPS, or dedicated? What OS?
   
2. Did you install Zen Cart yourself -- downloaded source directly from this website -- or did you use some installation service provided by your host?
   
3. Ditto your PHP/Apache setup: any idea where/how those were installed & configured?

[sdelaney]

Our web site is provided by a hosting service - Total Choice Hosting. We downloaded Zen Cart from their cPanel. I set it up myself.

Server OS: Linux 2.6.18 - 194.26.1.el5

MySQL: 5.0.91 - community

PHP: 5.2.14 (Zend: 2.2.0)

Zen 1.3.8a

With respect to upgrading to 1.3.9h, I am quite willing to do so. I was waiting for a quiet time in usage to do so, and I should probably look after it shortly. I am a little worried, however, since this would be my first major upgrade. I hope I have done my customizations correctly, so they are not lost. I also am worried about any issues that I might have to deal with in an upgrade. Should I expect it to just be a smooth process without any difficult steps?

I have to say, I no longer think it is a volume issue. The most recent round of registration that showed this problem was for a fun run by our club. We had about 30 or so registrations.

Here's how one string of problems showed.

One of the items I have defined is Volunteer and Social, and it is no charge. It has two attributes - "Name", and "Shirt Selection".

One member "ordered" this item to register for the social. Then another member tried to order the same item 7 minutes later. The name and shirt size of the first member was displayed in the attributes when the item was displayed, and could not be changed. The 2nd member went through with the registration anyway.

Then 10 minutes later, a 3rd member tried to order the item and the 1st persons information was displayed again. And then again, 12 minutes later, a 4th member got the same situation. (We know this because I have all the orders).

In the past, when this happened, I often got an email from the person before the order was completed. The work-around was to delete the item from the cart and start again from scratch.

It seems that on occasion a set of attribute values "persists" and continues to be picked up by subsequent attempts to order the item. Just crazy!

[wilt]

How is Zen Cart configured to store sessions, database or file ?

[sdelaney]

This is what is in the Sessions item in the administration section:



Session Directory /home/anwuttb/public_html/cart/cache
Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true

[wilt]

Hi,

Should have made my question a bit clearer.

What I was after was what setting you have in your configure.php for

define('STORE_SESSIONS',

[sdelaney]

It is set as "db"

[DrByte]

One of the items I have defined is Volunteer and Social, and it is no charge. It has two attributes - "Name", and "Shirt Selection".

One member "ordered" this item to register for the social. Then another member tried to order the same item 7 minutes later. The name and shirt size of the first member was displayed in the attributes when the item was displayed, and could not be changed.

"Could not be changed"???? That's very odd.
Got a link for that page URL?

[sdelaney]

Well, here is the selection for the three items that people were "ordering" in order to register for our event.

https://athleticsnortheast.com/cart/...=index&cPath=5

The problem of not being able to change the value of the attributes only happens when this bug shows itself. If the person selects the item, and it already has the values filled in (from someone else's order), then those values remain. I think the person can change them on the screen, but when they add them to their cart and go to checkout, the initial values reappear. This is why the 2nd person actually has to delete the item from their cart and start their order over from the beginning to get it to work okay.

I admit, this is crazy. I have worked a lot in IT in former years, and this sort of behaviour has me stumped. I can't imagine the chain of events that might cause something like this. And of course, it is extremely hard to duplicate the problem because you basically have to wait for someone to report that it is happening, seemingly at random.

Steve

[DrByte]

You aren't by any chance advertising to people to come to your site to do sign-ups, but the link you're giving them includes a zenid=xxxxxx parameter are you?

Publishing links containing zenids can cause an ugly phenomenon called session-hijacking, in which case subsequent visitors to that same link will see the information entered by previous visitors. Zen Cart attempts to protect against this in several ways, but if you're out publishing such links, you're directly inviting such problems.

Not sure if you're doing that or not, but it's something to keep in mind.

Also, are you always publishing "https" addresses, instead of just "http"?