Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 9 of 9
  1. #1
    New Coder
    Join Date
    Mar 2007
    Posts
    61
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Question Destroying GET variables at reload

    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

  • #2
    Senior Coder
    Join Date
    Mar 2003
    Location
    Atlanta
    Posts
    1,037
    Thanks
    14
    Thanked 30 Times in 28 Posts
    Do you mind posting the code?
    Most of my questions/posts are fairly straightforward and simple. I post long verbose messages in an attempt to be thorough.

  • #3
    ess
    ess is offline
    Regular Coder
    Join Date
    Oct 2006
    Location
    United Kingdom
    Posts
    865
    Thanks
    7
    Thanked 29 Times in 28 Posts
    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

  • #4
    UE Antagonizer Fumigator's Avatar
    Join Date
    Dec 2005
    Location
    Utah, USA, Northwestern hemisphere, Earth, Solar System, Milky Way Galaxy, Alpha Quadrant
    Posts
    7,691
    Thanks
    42
    Thanked 637 Times in 625 Posts
    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.

  • #5
    Senior Coder
    Join Date
    Jan 2007
    Posts
    1,648
    Thanks
    1
    Thanked 58 Times in 54 Posts
    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.
    Last edited by aedrin; 07-09-2007 at 05:49 PM.

  • #6
    New Coder
    Join Date
    Mar 2007
    Posts
    61
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.

  • #7
    Senior Coder
    Join Date
    Jan 2007
    Posts
    1,648
    Thanks
    1
    Thanked 58 Times in 54 Posts
    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.

  • #8
    ess
    ess is offline
    Regular Coder
    Join Date
    Oct 2006
    Location
    United Kingdom
    Posts
    865
    Thanks
    7
    Thanked 29 Times in 28 Posts
    Quote Originally Posted by aedrin View Post
    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
    Last edited by ess; 07-09-2007 at 09:08 PM.

  • #9
    UE Antagonizer Fumigator's Avatar
    Join Date
    Dec 2005
    Location
    Utah, USA, Northwestern hemisphere, Earth, Solar System, Milky Way Galaxy, Alpha Quadrant
    Posts
    7,691
    Thanks
    42
    Thanked 637 Times in 625 Posts
    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).


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •