...

View Full Version : Destroying GET variables at reload



nervegas87
07-09-2007, 03:49 AM
I have the following problem on a shopping cart.
Whenever a customer finishes selecting a product, they are taken to a cart page with the specific shop id of their selected product.
Like "cart.php?id=2", "cart.php?id=5", "cart.php?id=64", and so on...
The problem is, that whenever a customer reloads the cart page, my php code is read again and the same product comes out twice in the cart.

Is there a way of fixing this without changing the $_GET process of obtaining ids?

This is the web page where the cart is:
http://www.printingcarousel.com

StupidRalph
07-09-2007, 07:19 AM
Do you mind posting the code?

ess
07-09-2007, 10:55 AM
There many ways to resolve this problem...depending on your implementation of course.

One solution is to send a redirect to the page i.e. header( "Location: somepage.php" );

Another solution....which is the best in my opinion...is to check whether an item or a product...already exists in the shopping cart. If it does, then don't add it...if it doesn't...then add it. It is a simple if..else statement block

Cheers,
Ess

Fumigator
07-09-2007, 04:16 PM
I would use "POST" and use a separate PHP file for the "add item to cart" processing. Once that processing file has run, it redirects to a "cart display" page. Refreshing the "cart display" page would do nothing more than re-draw that page-- it would never have the opportunity to add an item.

aedrin
07-09-2007, 05:47 PM
Another solution....which is the best in my opinion...is to check whether an item or a product...already exists in the shopping cart. If it does, then don't add it...if it doesn't...then add it. It is a simple if..else statement block

You are assuming that the user will never want to buy another one of a product after they already chose to buy one earlier.

Bad mistake. If you were a programmer for me, and would bring that up as a solution, I'd question your position.

In a professional situation you need a good solution that will work basically all the time. Without assuming anything.


Once that processing file has run, it redirects to a "cart display" page. Refreshing the "cart display" page would do nothing more than re-draw that page-- it would never have the opportunity to add an item.

Users will hit the Back button. This is a given. It is very frustrating to a user to hit Back and be dumped back in the page you tried to go back from, now with 2 of the item in there.


One of the solutions you could employ requires 2 parts. Every time a page loads that contains a link/form to add a product, generate a unique ID.

Take the unique ID, put it in a session variable. Next, modify the link/form to include that variable.

Now, part 2 is minor. On the page that accepts the link/form (and actually adds the product) compare the ID in the session and what you get from GET/POST. If they are equal, add the product. Otherwise ignore the request.

Then the part that makes this work, after you add the product to the cart, change the ID in the session.

Now, if they hit refresh, or somehow manage to re-activate the link, the ID in the session will no longer compare to the one in GET/POST, and it will not add another item.

nervegas87
07-09-2007, 06:16 PM
Thanks for the help.
Aedrin i really liked that idea of the user id's, but my problem is that i already use the unique session id() for recognizing a customer's shopping cart. For now, there are way too many product pages that take you to the shopping cart, so implementing the links on every one of them will take eternity. But your method is impressive regardless! I think that the best thing for now is to use ess' method, since quantity is already declared before reaching the shopping cart.

aedrin
07-09-2007, 06:38 PM
but my problem is that i already use the unique session id() for recognizing a customer's shopping cart.

You don't use the Session ID. You can generate any kind of ID.

You can just use the result of time(), or use uniqid() to generate a random string. As long as it changes per visit, it will work.


For now, there are way too many product pages that take you to the shopping cart

I was giving the minimum requirement. You could put it in an include file, as long as the include file is always after the code that adds to your shopping cart.

But from the sounds of it, I think you should reorganize how your site is set up. I actually just re-read Ess' solution, and it is worse than I thought. That would be assuming that a user never wants more than 1? I can't force you to use a certain solution, but I hope you're not getting paid for this.

ess
07-09-2007, 08:47 PM
You are assuming that the user will never want to buy another one of a product after they already chose to buy one earlier.

Bad mistake. If you were a programmer for me, and would bring that up as a solution, I'd question your position.

In a professional situation you need a good solution that will work basically all the time. Without assuming anything.


No...you are wrong...I am not assuming that a user will not be purchasing the same product again. I don't know where you got that idea from.

Paraphrasing your own words
"If you were a programmer for me, and would bring that up as a solution, I'd question your position."

Basically, an item added to a shopping cart should not be compared to an item that has already been purchased in the past.

In order words, items that exists in the orders table are items that have been sold in the past...and not about to be sold. Items that are about to be sold should be placed in a separate table (i.e. Shopping Carts table)...to minimize errors and perhaps provide extra functionality such as allowing customers to save their shopping as a bookmark of items to be purchased for a later date.

Amazon is a good example...where you can add items to your shopping cart...but that doesn't necessarily mean that you have to purchase them in that given session.

Creating session variables and what have you..may solve the problem...but it certainly isn't a good design solution in my opinion, as you have a host of variables to read from the session array etc...where you could utilize a database table and unique session id to associate a shopping cart entry with a given unique session.

Therefore, if the user refreshes the page...an if statement to check whether a given item already exists in the shopping cart table is sufficient and should bring the expected outcome. If a user wishes to purchase more than one item of the same product in the same visit...you can increase the quantity field...as opposed to adding the item again to the shopping cart table.

Orders in the shopping cart table may only be transferred to the orders table once some validation of user's credentials etc have been processed successfully, and the user has successfully paid for the products they have ordered...and so on. Only then will you need to clear the shopping carts table from these orders and add them to the orders table.

In any case, I welcome any criticism to my approach...and I am happy to discuss this further.

Ess

Fumigator
07-10-2007, 06:44 AM
Users will hit the Back button. This is a given. It is very frustrating to a user to hit Back and be dumped back in the page you tried to go back from, now with 2 of the item in there.

I must not have explained the concept very well because hitting the back button will not re-post the POST (or GET) variables. The process page never goes to the browser-- it updates the database and redirects to an updated cart view. Hitting the back button at that point would merely go back to the product display page (where the user originally clicked the "add to cart" link).



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum