Hey all,

I have a shopping cart, users add items to it, update quantities, login, cart gets converted to an order, order gets paid for... the usual experience with a shopping cart.

We've had many successful transactions but every now and then we get an email saying something like "I placed items in the cart, went to checkout and before I could enter my login details I got an error saying 'Your cart is empty'."

Now, the only way that error is displayed is if nothing is found in the cart table matching the users session ID. The session ID is obviously set as they have been able to add items to the cart and update the quantity.

Does anyone know what might be causing this?

session_start(); is used on every page.

I'm thinking I'm going to have to start setting cookies (don't really want to), but if there are any other alternatives, I'm open to suggestions.

Thanks

    Check your session expiry time. Some users may take a long time to get through the basket process. Also copy to your dev site and have a print_r($_SESSION); and work your way through the process and see if anything is overwritten etc...

    We run all of our shopping carts off sessions and never have any problems.

      Just a hunch: it might be a cookie domain issue with the session cookie if a link or redirect uses a "www." sub-domain when the user originally accessed the site without it -- or vice versa.

      You can accommodate this by setting sesssion.cookie_domain to ".yourdomain.com" (note the leading dot).

        knowj;10908355 wrote:

        Check your session expiry time. Some users may take a long time to get through the basket process. Also copy to your dev site and have a print_r($_SESSION); and work your way through the process and see if anything is overwritten etc...

        The session expiry time is set to 3 hours, but the items in the cart are actually deleted after 30 minutes of being added - to replenish stock from abandoned carts.

        I did as you said and nothing seemed to get over written - I've never actually experienced the problem myself which makes it a bit harder to understand if the user could be doing something differently.

        NogDog;10908356 wrote:

        Just a hunch: it might be a cookie domain issue with the session cookie if a link or redirect uses a "www." sub-domain when the user originally accessed the site without it -- or vice versa.

        sesssion.cookie_domain is currently set to null, but I tried manually changing the sub domain while reading out the session and they seemed to stay intact.

        If it's any help, this is the code that checks to see if the user has anything in their cart:

        session_start();
        //Is Cart Empty
        function isCartEmpty()
        {
        	$isEmpty = false;
        
        $sid = session_id();
        $sql = "SELECT id
        		FROM cart
        		WHERE sessionID = '".$sid."'";
        
        $result = mysql_query($sql);
        
        if (mysql_num_rows($result) == 0) {
        	$isEmpty = true;
        }	
        return $isEmpty;
        }
        
        if (isCartEmpty()) {
        	setError('<li>Your cart is empty.</li>');
        } 
        
        

        The same $sid = session_id(); is used when adding items to the cart and when echoing $sid throughout the checkout process, it stays the same for me.

        Thanks for your help.

          I think that the user's session_id() is changing as they go through the checkout pages, but I am unable to recreate this. Does anyone know what may cause this to happen?

          Thanks

            middleman666;10908398 wrote:

            I think that the user's session_id() is changing as they go through the checkout pages, but I am unable to recreate this. Does anyone know what may cause this to happen?

            Thanks

            Session cookie expiring.
            Session data being deleted (possibly if session.gc_max_lifetime has expired)
            The sub-domain issue I referred to above
            User error
            Something else I haven't thought of.

              NogDog wrote:

              Something else I haven't thought of.

              http://mysite.com => https://mysite.com
              http://mysite.com/dir1/script.php => http://mysite.com/dir2/checkout.php ?

              Try manually setting the domain (to ".mysite.com") and path (to "/") for the session cookie and see if that doesn't help. Note that you'd want to make this change in every script that uses sessions; making the change in a php.ini or .htaccess file would therefore be best.

                Thanks for the replies, I did a lot of hair tearing last night and I think I've found the issue... Our cart is sometimes used by clients within their site using a iFrame/frame and we've discoverred that all the errors were originating from one of these clients sites.

                Testing on another machine and going through the client site, I could see that the session ID's were not being held and changing each time the page was refreshed. When setting the browsers security settings to low this issue seemed to disapear.

                I'm not entirely sure if this relates to the url issues you've pointed out, but I'm guessing it's something similar?

                So now I'm looking at solutions, one would be to tell the client to integrate the iframe cart the way we told them to as none of our other clients have the issue. Another which I've been experimenting with is holding the session in the url, this works, but it's not the ideal situation.

                Do you have any tips on how to pass the session through the url safely? and assuming the user has cookies disabled?

                Thanks for your help!

                  For the no-cookies issue, you'd want to make sure that session.use_only_cookies is turned off and session.use_trans_sid is on. However, this does have certain security issues, namely that the session ID is part of the URL, which means it's easily visible and a user could unknowingly send it to someone else by sharing the link via email, for example.

                    Write a Reply...