Page 1 of 1

variables being held in memory?

Posted: Tue Aug 26, 2003 2:06 pm
by Unipus
Well, this'll be my first post here, and hopefully it's not a total disaster. Sorry, but I'm not exactly sure how to quickly describe this problem.

I'm building a shopping cart app. All items in your shopping cart are stored as an associative array (Item number => quantity). There's a nice big fat REMOVE button next to any item in your shopping cart... if you click it POSTS back to the same page with a hidden field where $Remove = the ItemNo to be removed. The page switches to detect if Remove is set, and if it is, it unsets that variable from the array. Works just fine.

But here's the problem. Apparently somewhere, somehow, the most recently posted variables are being cached, because when you reload the page, it sends it all again and will increment the quantity of whatever item you last posted. This is not desireable from a page refresh. Likewise, if you Remove an item and then Remove a different item, the first item you removed shows right back up again! You can play a fun little see-saw game by clicking the Remove button all day and watching the items switch back and forth! So what I imagine is happening is that somehow the most recent POST variables are being stored and applied again whenever you make a page change. But why, and how do I stop it?

So. Does anyone know why this problem is happening? I figure this is probably a pretty simple theoretical question, and so I'd rather not post excessive amounts of code just yet. Any ideas?

Posted: Tue Aug 26, 2003 3:26 pm
by Unipus
Hrm. No one seems to know what the hell I'm talking about, anywhere. Does my post even make sense? What can I do to make it more clear?

Posted: Tue Aug 26, 2003 4:24 pm
by mcsleazycrisps
The "Re-POSTing" on a refresh is typical browser behavior, this is why IE prompts you with this when you try to reload a page that you have just submitted:
The page cannot refresh without resending the information. Click retry to send the information again, or click cancel to return to the page that you were trying to view.
One way around it is to redirect the page (to itself) once it's done its thing with the shopping cart. So once it's added to the cart, do a header("location: file.php") or maybe use a query string like header("location: file.php?feedback=Updated")

Posted: Tue Aug 26, 2003 4:33 pm
by Unipus
Yes, okay, that's the problem I'm dealing with. Can you elaborate a bit on your explanation? I sort of follow, but not enough to know what I'd do with it.

Posted: Wed Aug 27, 2003 12:24 pm
by Unipus
Hrm. Anyone?

Posted: Wed Aug 27, 2003 12:30 pm
by JAM
Pressing (IE example) F5 refreshes the page, and with it, the sendt information.
If you submit the form, and then redirects the user a second time using header(), you are with that not posting anything the second time, hence it wont complain.

Helped?

Code: Select all

header("Cache-control: private");
might also help somewhat, due to the fact that there is a bug in IE6. (This bug is about the form being wiped clean if you press the back key after submitting the form, but it's nice to know.)

Posted: Wed Aug 27, 2003 12:54 pm
by Unipus
Sorry, but I'm still a bit confused. I don't understand how redirecting the page solves the problem... shouldn't it just be reposting the variables each time anyway? Clearly, it doesn't, but I don't see why.

Where in the control structure does this redirection happen?

Posted: Wed Aug 27, 2003 1:53 pm
by JAM
Using header() as redirection is not the same as redirect a user using form method="post". As the method=post is not used when you send the header()-redirection, the input is not submitted yet again.

1. User adds something to the cart.
2. Your script adds it to sessions, db, etc...
3. header() to the same page.
4. User press F5/Refresh. As you did a header() on 3. the previous _POST is lost, so the item in the cart isn't added once more.

You need to use header() before any output to the browser, so it would preferably fit well right after the session-works.

I dont know other ways to describe this.

Posted: Wed Aug 27, 2003 7:08 pm
by Unipus
Got it.