Due to a small change in session regeneration in Drupal 5.9, the cart is lost when an anonymous user logs in using the login block (as opposed to the ec_anon login form).

I'm not sure how to fix this. One idea would be to store user-related carts in the ec_cart table and anonymous carts in $_SESSION? When the user logs in the cart should still be in $_SESSION. It could then be copied to ec_cart table in order to preserve it for later sessions.

CommentFileSizeAuthor
#6 ec_cart-cookie-instead-of-session.patch1.47 KBmotin
#3 cart.session.patch1.03 KBmfb

Comments

mfb’s picture

mfb
they or he
commented

drumm had a good suggestion:

Then the easiest thing to do is to use your own id set $_SESSION['ecommerce_cart_id'].

gordon’s picture

gordon commented
Assigned: Unassigned » gordon
Priority: Normal » Critical

It was actually a change in Drupal 5.9 which has the session being regenerated before the hook_user('login') is called instead of after.

I am going to have to take a look at linking the cart to the current user a different method instead of using the session id.

Maybe something like an additional cookie or maybe a link from the session.

mfb’s picture

mfb
they or he
commented
Status: Active » Needs review
StatusFileSize
new cart.session.patch1.03 KB
gordon’s picture

gordon commented
Status: Needs review » Fixed

Thanks I have committed the above patch, but the problem was that it left junk in session, so I made some changes so that it will remove the cart_id from session once it is no longer needed.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

motin’s picture

motin commented
StatusFileSize
new ec_cart-cookie-instead-of-session.patch1.47 KB

I am not opening this ticket as I haven't checked what has been done in 3.x-dev, but as far as Drupal 5.11 and ec 3.5 is concerned, this bug is still effective.

Attached is a patch that uses $_COOKIE instead of $_SESSION (which seems to be reset upon login in Drupal 5.11), and thus circumvents the problem.

There may exist security implications with this that I am not aware of, but this solution works for me...