Unsetting cart session causes cart contents to be lost

Works on my test site with all levels of caching. Are you using Drupal or Pressflow? That change was designed with Pressflow in mind, and I got good reports on it, but I didn't personally test it.

Worked correctly on a clean install with Drupal 6.17 with all caching levels. Are you doing anything additional with caching or sessions? Varnish, squid, or some module? Do any of your custom modules mess around with caching or sessions? Can anyone else duplicate the results?

I still think it's weird because the functions were supposed to be changed in a way that didn't affect the way they might be used by other code. uc_cart_get_id() creates a new cart id by default, so systems with lazy session loading (Pressflow and Drupal 7) will get initialized at the right time. Since a session is always created in Drupal 6, it really shouldn't matter.

I'm starting to wonder if the incompatibility comes from some other change.

I got the exact same problem when I update from 2.2 to 2.3.

I use several module that is related with ubercart :

Ubercart 6.x-2.3
Ubercart Catalog Taxonomy Menu 6.x-1.x-dev
Ubercart Discounts (Alternative) 6.x-2.x-dev
Ubercart Attribute Clone 6.x-1.0
Ubercart Stock Manager With Attributes 6.x-1.x-dev
Ubercart Option Images 6.x-1.4
Ubercart Views 6.x-3.0

I don't have any custom modules installed. The patch that wojtha proposed seems to work, though I don't know what the side effect of reverting uc_cart to previous version.

One thing I note also (maybe unrelated) is when I use drush to update, I got this weird message:
PHP Fatal error: Cannot redeclare uc_product_kit_enable() (previously declared in /Users/xxx/drupal/sites/all/modules/ubercart/uc_product_kit/uc_product_kit.module:76) in /Users/xxx/drupal/sites/all/modules/ubercart/uc_product_kit/uc_product_kit.install on line 129

which is weird, since I can't find uc_product_kit_enable() anywhere in uc_product_kit_install. When I update the database everything seems to work tho. So far I didn't notice anything unusual except that anon user can't add product to the shopping cart.

One more thing that I notice is that when the cart already contain something when I added an item (from the previous version of ubercart), the new item added to the cart correctly. But when I emptied the cart, and then try to add an item, it doesn't show up in the cart anymore.

@wojtha, yes, I reverted your patch, and disabled ubercart stock manager, and it works ! Your theory seems to be correct :)

Same problem. Checked the DB and the 0 entry was in it. This is not good since 80% of my customers are new customers.

fixed it after I removed restrict quantity mod.That is what I think I did last. Appears to be a contributing mod attached to ubercart. Also I removed caching. Take this with a grain of salt because I did do about 20 changes and clearing catches etc but everything seemed to not matter until I started unloading modules.

I can confirm that uc_multi_stock.module is the culprit here. Specifically, calling uc_cart_get_contents() from any hook_add_to_cart() is causing this issue (well found wojtha!).

#14 B) sounds reasonable but no time to test the theory right now.

It appears the that this is causing quite a few problems.

unset($_SESSION['uc_cart_id']); was added in #377798-67: Cart block always starts a session. It wasn't present in #64 and was added in #67 specifically to ensure the session is removed after checkout is completed. However the session is unset irrespective of the $action parameter to uc_cart_get_contents() and as a result the session is unset in situations where it shouldn't be.

This causes the cart to be incorrectly emptied when:

• uc_cart_get_contents() is called from hook_add_to_cart() (uc_multi_stock.module does this).
• When the user logs in and their anonymous cart is transitioned to an authenticated cart #862348: Cart emptied on login

Thankfully the fix seems pretty straight forward - #19 fixes the problem by simply adding a $action === 'rebuild' before unsetting the session (this seems to be in keeping with the use case for unsetting the session in the first place, i.e. unset it only when the cart is being rebuilt, e.g. after order completion). Attached is basically a re roll from the ubercart dir so the credit goes to wojtha for tracking this down.

Marked #862348: Cart emptied on login as a duplicate of this issue as the patch here in #21 fixes that issue as well.

I am having more or less the same issue. But my case has one extra step. From hook_add_to_cart(), I need to call uc_cart_empty(), to make sure that the inserted item is on its own in the cart, under certain circumstances. This messes everything in ubercart 2.3, perfectly described at #8. The proposed patch does not fit in this scenario, since uc_cart_empty() calls uc_cart_get_contents() with the 'rebuild' action, unsetting $_SESSION['uc_cart_id'].

I have tried removing from uc_cart_get_contents() these lines (starting at line 1383):

/*
    if (empty($items[$cid]) && isset($_SESSION['uc_cart_id'])) {
      // As their cart is now empty, there is no need to keep the cart ID in the session anymore
      unset($_SESSION['uc_cart_id']);
    }
*/

Now it works. I see no harm in having extra data in $_SESSION.

As one of the contributors of the patch that broke this session functionality, sorry for the trouble it's caused!

Adding that code to uc_get_cart_contents() was done because it ensures that any time that the cart goes empty for any reason, the session key is deleted.

The reasons for session cleanliness are twofold:

The primary problem is that as long as that session key remains set, Drupal (7 or pressflow) will keep a session table entry for that user that loads and saves on every page view. An anonymous user with nothing in their cart has no need to have a session at all, which keeps the session table considerably shorter on high traffic sites and speeds up page views. I realize stock Drupal 6 can't benefit from this though.

The second (and related) reason is that anonymous users without a session can be served static cached copies of a page safely, without having to show the cacheable uc_cart block. For sites that are a mix of ecommerce and largely static content, this improves scalability and UX immensely.

I'm going to have a look into another way to accomplish this though. Cron isn't really an option because Drupal won't let you load another user's session to check (plus iterating over thousands of sessions isn't very efficient), and because the user isn't there, Drupal can't delete their session cookie even if the session does go empty. Using the rebuild op also isn't optimal because that's not what it's for. It's conceivable that a hook_add_to_cart may want to rebuild the cart, which would lead back to the same problem.

I think the proper solution is to block the session unset if an add to cart is in progress, since that appears to be the only case where it causes problems? Maybe UC could set a flag for any request that calls add_to_cart?377798

I'll work on revising the patch over in #377798: Cart block always starts a session.

@neilnz Yeah the unset that was added seemed harmless, but the most benign looking ones are the ones that turn around and bite.

If you're going to explore this keep in mind #862348: Cart emptied on login which I can confirm. Anon user adds a product to their cart, then logs in, their cart is now empty.

I'd put in a vote for rolling it back. I understand the performance improvements but broken cart functionality like this is not a pretty thing.

Thanks everyone for tracking down the problem - it has been driving me potty trying to find out what was going on!

It sounds like the best thing is to revert back to version 2.2 until a fix has been found - but how could I best do this? Did version 2.3 make database changes or could I just overwrite the files in the ubercart folder?

This is an unfortunate regression. If it wasn't so pervasive, I'd suggest converting said broken functions to hook_uc_cart_alter(). Unfortunately a) it is a big regression of a long standing behavior and b) hook_uc_cart_alter doesn't really provide enough context to be useful. It'd be great if we could so easily move these anonymous users back to 100% anonymous but unfortunately uc_cart_get_contents looks to be to fragile a location to do this because of other parts of UC's design.

I'll reluctantly agree to rolling back that particular section of the other patch. Maybe we can aim for it being better in 7. The largest gain for Pressflow users will still be there with the lazy creation and not the cleanup.

A side note, I was /not/ able to recreate the cart getting emptied on login. I'm wondering if that is also caused by some contrib or non required module that was not enabled by the people testing the original patch.

I would like to add one more comment. I am not a guru in Ubercart, so I may be saying some nonsense.

As @neilnz points out, the goal is to improve the performance in a heavy loaded host. But if we think about the behavior of the users, how many will add a product to the cart, then delete this product, and continue browsing the website without actually adding anything else to the cart? I believe that the proportion will be really low. Therefore, I think that this optimization will not have a perceptible impact in the overall performance.

OTOH, users that add something to the cart and go all the way to checkout and pay for the order, can more easily be identified. Only in this case, $_SESSION should be emptied, but somewhere else in the code, as I believe it is already being done.

Re, $_SESSION getting cleaned up elsewhere, no, that's the only place the cart_id is removed from the $_SESSION. But, as I mentioned, the big gain was the lazy session creation, not the cleanup. Users that have added stuff to their cart are a smaller percentage of users and group more likely to actually need a session(site specific exceptions of course).

That said, I'll review any patches if someone wants to try to fix it the clean in some way. Do we have any direction from the UC maintainers?

subscribe

Thank you Wojtha and fenstrat. I eventually plucked up my courage and applied your patch manually (my very first time doing this...) - and it all worked beautifully and my website works again! Yay!

I applied the patch from fenstrat (Fender Stratocaster?) in #21 and it solved all cart emptied on login/register issues for me.

The patch applied fine using the patch command in OS X terminal. I have not seen any side effects after applying this patch.

Thank you for this patch. And thanks to TR for guiding me to this thread.

After a bit of a dig, it does look like everywhere that calls the rebuild action is a sensible/safe place to perform this check.

In particular, I've identified lines 1626, 1604, 891 and possibly 1586 as places that should be checking if the session is still needed. 1626 and 1604 are calling uc_cart_get_contents() with the rebuild action.

Places where it's called:

uc_cart_login_update() lines 884+891+899 - should be safe as the old cart session is being destroyed anyway. Line 891 should be safe to unset the session, although this will mean the new cart for the logged in user will have a new cart ID (it'll set a new session in the first call to uc_cart_add_item())

uc_cart_add_item() line 1545 - should be safe as in most cases an item would have already been added to the cart, so no unset will occur

uc_cart_update_item_object() line 1604 - Safe and desirable, when qty of all items in cart goes to 0, the cart is no longer needed

uc_cart_empty() line 1626 - this is the best place to be checking the session. If the code was to be removed from uc_cart_get_contents(), it should probably be moved here, as this is called on order completion. One other place that should trigger the unset (but won't anymore) is uc_cart_cron(), when a cart exceeds either the anonymous or authenticated duration and is emptied. Because the uc_cart block doesn't use the rebuild action (for performance), this expiry won't cause the cart ID to be unset from their session, even though the cart goes empty. This is a pretty important corner case, and unfortunately regresses under the patch from #21.

At any rate, I've attached a patch that builds slightly on #21 by checking that it's unsetting the correct cart ID (before it would unset the session even if a non-default cart went empty). I'll keep thinking about a better way to solve the cron cart empty issue.

uc_cart_login_update() lines 884+891+899 - should be safe as the old cart session is being destroyed anyway. Line 891 should be safe to unset the session, although this will mean the new cart for the logged in user will have a new cart ID (it'll set a new session in the first call to uc_cart_add_item())

Cart id changes from a random md5 to the user id as the user logs in so this is a moot point.

Really though as you mentioned, this is a safe place to clear the session, but since theres this new "$_SESSION['uc_cart_id'] == $cid" and uc_cart_login_update only passes $uid, this will always fail and we'll never unset the session variable. What is that check fixing?

uc_cart_empty() line 1626 - this is the best place to be checking the session.

This does seem logical but its exactly what pmonjo was having trouble with though. Reset the cart before adding an item. Do we just require he change his logic and not call uc_cart_empty()?

It is possible to have a cart ID that is neither the user ID nor the random MD5 hash. There's nothing stopping contrib from making up an additional cart ID to allow a user to have a second cart, for instance. I've used this myself on a site before that needed different carts for different types of products.

The problem is an anonymous user's main cart ID is stored in the session. In the case where you empty a secondary cart and call uc_cart_get_contents() with that explicit cart ID, you don't want to unset the session var that points to their main cart. In theory for a normal site, $_SESSION['uc_cart_id'] should always be the same as $cid (uc_cart_get_id() should make sure) whenever the user is anonymous. In the case where they transition to an authenticated user, the session var shouldn't be set and their anonymous cart is destroyed, along with their anonymous cart ID. That's what uc_cart_login_update() does. Well that's in theory. It does seem that when logging in, the session isn't actually destroyed, so really it should be up to uc_cart_login_update() to unset that anonymous session var, since nothing will use it while the user is logged in.

So here's a revised patch that does that too.

While a little obtuse, wouldn't this get the same results?

-    if (empty($items[$cid]) && isset($_SESSION['uc_cart_id'])) {
+    if ($action == 'rebuild' && empty($items[$cid]) && isset($_SESSION['uc_cart_id']) && uc_cart_login_update() == $cid) {
       // As their cart is now empty, there is no need to keep the cart ID in the session anymore
       unset($_SESSION['uc_cart_id']);
     }

Also, we really need to add some comments to clarify what this weird logic is doing and why it works. This is just asking to get broken.

I'm not quite sure what you're trying to accomplish, uc_cart_login_update() doesn't return anything? Besides, I doubt you'd want to call it every time the cart is rebuilt. Did you possibly mean uc_cart_get_id()? That would be a sensible way to check whether or not a $cid was passed in originally, but is a bit of an ugly way to go, and like you said would need commenting.

I think the deliberate unsetting of the session var in uc_cart_login_update() is a bit cleaner and doesn't need as much explanation, but you're right that my $cid == $_SESSION['uc_cart_id'] filter in uc_cart_get_contents() might not satisfy all the cases where the session var needs to go away.

subscribe

having same issue with anonymous users losing cart contents upon creating new account or logging in with an existing one.

subscribing.

yeah, I meant uc_cart_get_id(). It seemed more elegant to me because it seemed to match the idea of the code more. Maybe I'm wrong though.

The only reason I really marked it "needs work" was that it needs docs. The patch is functionally fine.

How about this?

This latest patch worked for me, thanks.

Also please note there may be a problem with module "Ajax Attribute Calculations".
Therefore, I opened: http://drupal.org/node/876834

#43 works for me.

(Note neilnz, I didn't have Ubercart in the same directory as you so to apply the patch I had to do this from the inside the ubercart directory and use patch -p6 < 858816-uc_cart-session-43.patch.)

subscribe

We have the exact problem.

In ubercart 6.22, the following code works in hook_add_to_cart:

function uc_ismoney_add_to_cart($nid, $qty, $data) {
  $items = uc_cart_get_contents();
        if (!is_array($items) || count($items) == 0) {
    drupal_set_message(t('You do not have any items in your shopping cart.'));
    return;
  }

After upgraded to ubercart 6.23, anonymous user couldn't add products to cart, because, $_SESSION['uc_cart_id’] was lost.

So, now we have to re-implement the hook_add_to_cart in our module as:

function uc_ismoney_add_to_cart($nid, $qty, $data) {
        $cart_id = uc_cart_get_id();
        $total_records = db_result(db_query("SELECT count(*) FROM {uc_cart_products} c WHERE c.cart_id = '%s'", $cart_id));
        if($total_records ==0){
                return;
        }

     ...

We hope this issue gets fixed ASAP.

#43 looks to be working for us so far, thanks for the patch. Will update if we get any issues when we push to live.

@404 have you had a chance to try testing the patch? more reviews means quicker to RTBC and then committed.

It looks and sounds like it's working, so I guess I can commit it.

Thanks, everybody.

Thanks Is. Usurper!

Did this get into 6.x-2.4?

Yep, #43 got into 6.x-2.4 in this commit.

Thanks to neilnz and everyone else for their work on this.

@Lunk Rat nicely guessed on my username, first one on d.o to pick that up!

This patch does solve the issue for cart loss for REGISTRERED USERS.
Still, ANONYMOUS USERS loose their cart content on registering.

This is an important point on a shop.
So IMHO we should not mark this bug as fixed but "need more work".

My configuration:

Drupal new user require email verification: off.

UC anonymous checkout: off.

Cart is full of items, click checkout, register for new account, submit successful account creation, get this:

I checked Ubercart Checkout settings:
"Login users when new customer accounts are created at checkout" is checked.

The problem seems to be that new customers accounts are not logged in automatically.
After creating an account, you have to login and your cart content is lost.

Attached is a screenshot which shows the message displayed to new users. After registration, users are asked to login. Previously, new users would be logged in automatically during checkout. Could you reproduce this problem?

With reference to #57, with all modules updated ubercart logged automatically new customer at checkout and cart contents is ok.

Do you mean #47?

function uc_ismoney_add_to_cart($nid, $qty, $data) {
        $cart_id = uc_cart_get_id();
        $total_records = db_result(db_query("SELECT count(*) FROM {uc_cart_products} c WHERE c.cart_id = '%s'", $cart_id));
        if($total_records ==0){
                return;
        }
....

This needs to be clarified ASAP.
The number of new customers on my shop dropped significantly since card content is lost on new user registration.

No, I'm talking about #57.
With ubercart 6.x-2.4
Filling the cart as anonymous user and registering automatically at checkout the new customer is registered ok and logged in as expected.

I am using 6.x-2.x-dev which includes the fix.
I did a diff from ubercart 6.x-2.4 and ubercart 6.x-2.x-dev.
The cart code is exactly the same.

Filling the cart as anonymous user and registering automatically at checkout:
* The cart disappears.
* New customer is registered ok but not logged in as expected.

Can you reproduce?

subscribe

Yes, I've reproduced it. Checkout as anonymous user with 3 products into cart. Filling the new customer information at checkout. Order paid with Paypal (sandbox) and, on return from Paypal's page, the new customer is logged in. All is ok for me.
Allow anonymous checkout, create new accounts on checkout and activate new accounts checked at checkout options.
Screenshots attached.

I have just updated to Ubercart version 2.4 and the problem is still the same. Again, the only solution so far is to use the quick hack I provided at #23.

@jean guimauve That's a pretty harsh thing to say of someone who has been an active member of the community for >2 years. Lets leave the name calling out of this. Its not even appropriate ever. If you have a problem with this, contact me and will discuss it out of the issue queue.

@jmpoure Can you track down the issue any further? Is there a module you can narrow it down to maybe that causes this to happen for you?

The abusive users have now been blocked.

I have same issue as #23 has. I need to empty cart every new item is added as site is used for signing up for event. I am using uc_node_checkout for that.

First i tried to empty cart from uc_node_checkout.module adding uc_cart_empty(uc_cart_get_id()); where registration is added to cart, but this did nothing. It worked once when I updated from ubercart 2.3 to 2.4, but after that old item aren't deleted from cart.

Then I tried to move uc_cart_empty to hook_add_to_cart in my module and this will empty cart, but new item isn't going to be added either.

function pnw_add_to_cart($nid, $qty, $data) {
  // Empty cart before adding new items
  uc_cart_empty(uc_cart_get_id());

  $result[] = array(
    'success' => TRUE,
    'silent' => TRUE,
    'message' => t(''),
  );
  return $result;
}

if i remove uc_cart_empty line, items will be added fine.

Not quite sure what I am doing wrong. I also tried to use UC Add to Cart Tweaks as it provides functionality to remove other items from the cart before adding new ones, but doesn't work either.

I am using ubercart 2.4 and users are anonymous and they don't have a option to sign up to site.

See #53, this is indeed still an issue.

For anonymous checkout calling uc_cart_empty() from any hook_add_to_cart() simply does not work.

I have been fighting this issue in 6.x-2.3 and 6.x-2.4. Logged in users were able to add items to cart without an issue, most importantly being a UC Variable Price item. Anonymous users weren't able to... They would click the add to cart button, both on a product page and in a block, and were redirected to the cart. Then, while the message on the page would say that the item was added, the cart would be empty.

I have tried/applied various patches from this thread and nothing worked reliably. The best results came from #23 and those were sporadic reports of items added to carts. Caching is set to normal, page compression is on, java and CSS caching is enabled, blocks are not.

Funny thing I tried, though, to reduce the workflow and redirects to explore this issue... For the Secure Pages module which is listed in the UC Docs as basically being a requirement, rather than have only the path to the cart secured, I set it to secure all of the product nodes as well as the node type that the product blocks were on. My reasoning, right or wrong, was to have one less check in the chain (https vs http) since this issue seems to be centered around sessions being dropped and in what order the checking of the cart vs clearing sessions for anonymous users was performed.

Without the redirect from http to https from product page to cart in UC 2.4, meaning all product pages or pages with blocks/views with UC forms, all behaves as expected.

I am not intimately familiar with the UC code, etc but I'm adding this as a bit of info that may or may not be helpful.

Remember my issue and this comment here: #679422-52: hook_exit() causes Ubercart "Add to Cart" to fail - any module that calls hook_exit() could potentially break add-to-cart processing, if they are aborting scripts (in the case of Boost, by using exit()). I would look at any contribs and see if they are doing this. My original investigation led me to believe that carts were being destroyed due to the fact that the session value was never being created to start with (it seems that it needed to exist before "Add to Cart" was pressed) but after a while, we got away from that.

Not sure if it's relevant here but I thought I'd mention it.

@mjvesper

Without the redirect from http to https from product page to cart in UC 2.4, meaning all product pages or pages with blocks/views with UC forms, all behaves as expected.

Thanks for the input. We also use https and Secure Pages module to secure order management.
Unfortunately, I disabled Secure Pages and it did not fix the anonymous checkout problem.

Please note I did not test "pure" anonymous checkout. We request anonymous users to connect.
After registration, users should see their anonymous cart transferred to their new user.

Well... After a day of hard work the Secure Pages Module was the final hint.
I never used uc2.2 or uc2.3, so it was kinda confusing to find almost all the patches in this issue in the source of uc2.4.

Its clear that de Secure Pages module and uc2.4 are interfering with each other. I use a complete anonymous checkout.
The solution to get it work for me: Making Secure Pages switch to https all ready while browsing the store instead of switching when adding items to the cart.

OK, but what is Google bot policy as regards https? If i switch to https, will my website still be visible by Google?

Having the entire store be https is not really an ideal solution. I still don't think Secure Pages is the issue, as we are using Secure pages to switch from https to non-https - the Cart is non-https, the store is non-https, but the Checkout IS https. As long as your "base_url" in settings.php isn't configured to be one or the other, you should have no trouble.

I noticed this happening on a couple of my UberCart stores. I solved it by:

1) Setting Secure Pages so the cart page is now served up under https://
2) Uncommenting the redirect in root htaccess to always switch the site to http:// from http://www
3) Setting $cookie_domain in settings.php to my domain name.

The solution to get it work for me: Making Secure Pages switch to https all ready while browsing the store instead of switching when adding items to the cart.

Assuming this is true, the question would be how are you adding items to the cart? Unlike togosPizza, we actually have everything in the cart and checkout process under https and are not having this problem so if it is related to securepages, it would be something different like how you're adding items to the cart that is causing the problem.

@jasonabc:

Really, taking out the force-redirect for non-www solved the issue for you? We have that forcing users to the http://www URL and still don't see this issue. The main key, I think, is the cookie_domain and base_url settings; those always seem to cause havoc when a site needs to track things like sessions and carts.

Dear Friends,

Like Jasonabc proposed, I set the following:

1) Setting Secure Pages so the cart page is now served up under https://
I added cart*
2) Uncommenting the redirect in root htaccess to always switch the site to http:// from http://www
This was the case.
3) Setting $cookie_domain in settings.php to my domain name.
I added the domain.com only, not www.domain.com

Still, this does not work for me. When I switch from anonymous to user, my cart content is lost.

I am using Ubercart_ssl instead of Secure Pages, and after (temporarily) enabling ssl on the entire site and following the steps mentioned in the post by Jasonabc, I can confirm that the solution does not work for me either. All cart data from an an anonymous user's session is lost once they login or register.

For those experiencing problems with ssl can you test if problems persist after disabling all other uc contrib modules?

Specifically any module which calls uc_cart_empty() from hook_add_to_cart(), e.g. uc_multi_stock.module.

For what it's worth I haven't seen this and am unable to reproduce it on a site with securepages in mixed mode (SSL for checkout only) and several contrib modules installed, including uc_multi_stock.

I can confirm that this is correct : new user is not logged in correctly. Same debug in uc_cart_user() in 2.2 and later versions shows operations on user accounts not happening versions post 2.2:
USER op: load user: 0 uri: /user/register
USER op: register user: uri: /user/register
USER op: validate user: uri: /user/register
USER op: load user: 27 uri: /user/register
USER op: insert user: 27 uri: /user/register
USER op: load user: 27 uri: /user/register
USER op: load user: 27 uri: /user/register
USER op: login user: 27 uri: /user/register <== not happening after 2.2
USER : case login fall-thru <== not happening after 2.2
Registration successful. You are now logged in. <== not happening after 2.2
USER op: load user: 27 uri: /cart/checkout <== not happening after 2.2

#87: Is this the same issue? The OP states that when you go from non-https to https, the cart contents are lost. In your debug info, are you just logging in?

To me these sound like entirely separate issues. Here are the issues that people seem to be discussing, by looking again at this thread:

1) (The original issue): Anonymous "add to cart" was not working. This was subsequently patched in #52 (in this commit).

2) When a NEW, ANONYMOUS user has a cart and moves to checkout, and then registers, their shopping cart becomes empty.

3) Switching from non-https to a secure (https) page results in loss of cart contents. (I am unable to reproduce this.)

There is a 4th issue that I think is a non-issue, and that is users who are testing as ANONYMOUS and then logging in as a user (who ALREADY exists). This is, as of now, a "by-design" function that should probably allow for a MERGE of shopping carts or a solution where the NEW cart blows away the OLD cart. (In other words, your anonymous cart contents replace what was in your previous logged-in cart contents.)

Does this sum it up? Am I missing something here? I feel like this thread has gotten confused by people posting about various issues that may or may not be related. On top of that people are not really posting "what it is they are doing" and so this is causing more confusion and less help to the rest of us trying to figure out what is going on. Some of us are talking about Secure Pages, some of us are talking about /user/register, etc. I think this thread should be closed and others who are still experiencing issues should create entirely separate threads so we can focus on one specific issue at a time.

@torgodPizza, for me it was issue 2).

BTW I agree w/you 4th issue is a non-issue.

Contrary to the experiences of #32 and #33, the fix in #21 did not seem to work for me.

My checkout settings are:
-Enable anonymous checkout (users can checkout without logging in).
-Login users when new customer accounts are created at checkout.

My user settings are:
-Visitors can create accounts and no administrator approval is required.
-E-mail verification NOT required

I would register as a new user, lose my cart content.

I was careful to clear cache between each test. Should I have also emptied uc_cart_products? Or the sessions table? Let me know. I did not do that, I only emptied cache between tests.

The cart was getting emptied every time. This is when I wrote #87.

Here's what I did after, and the problem disappeared. But why? I don't know. If you can shed any light on this I would be grateful.

*I rolled back to a 2-day old backup

*In uc_cart.module I applied rev 1.56 line 1289 change for function uc_cart_complete_sale for the heck of it (i did not see how this could make a difference but I'm just reporting what I did)

- uc_cart_empty(uc_cart_get_id());
+ uc_cart_empty(uc_cart_get_id(FALSE));

That's all I did. It works, the cart is not emptied on login anymore. Why?

I append all my modules below.

****************
Drupal core 6.19
Admin role 6.x-1.3
Administration menu 6.x-1.6
Advanced help 6.x-1.2
Apache Solr Facet Builder 6.x-1.x-dev (2010-Jul-11)
Apache Solr Search Integration 6.x-2.0-beta3
Apache Solr Views 6.x-1.x-dev (2010-Sep-10)
Authorize.net Advanced (CIM) Payment Gateway 6.x-1.x-dev (2010-Jul-11)
Content Construction Kit (CCK) 6.x-2.8
Content Taxonomy 6.x-1.0-rc2
Content Templates (Contemplate) 6.x-1.2
Date 6.x-2.6
Devel 6.x-1.22
Field Indexer 6.x-1.0
FileField 6.x-3.7
Hovertips and Clicktips 6.x-1.x-dev (2010-Jul-11)
Image 6.x-1.0-beta6
ImageAPI 6.x-1.8
ImageCache 6.x-2.0-beta10
ImageField 6.x-3.7
Javascript Tools 6.x-1.0
jCarousel 6.x-1.1
jQuery UI 6.x-1.4
Lightbox2 6.x-1.11
Link Image Field 6.x-1.0-beta2
Mime Mail 6.x-1.0-alpha6
Nodequeue 6.x-2.9
Nodetype 6.x-1.0
Package Tracking for Ubercart 6.x-1.1
Pathauto 6.x-1.4
Secure Pages 6.x-1.x-dev (2010-Jul-11)
Skinr 6.x-1.5
Special menu items module 6.x-1.5
Taxonomy import/export via XML 6.x-1.3
Taxonomy Menu 6.x-2.9
Token 6.x-1.14
Ubercart 6.x-2.4
Ubercart Addresses 6.x-1.0
Ubercart Discounts (Alternative) 6.x-2.x-dev (2010-Aug-24)
Ubercart Views 6.x-3.x-dev (2010-Aug-01)
UC Gift Certificate 6.x-1.1
UC Upsell 6.x-1.21
Unique field 6.x-1.2
Views 6.x-3.x-dev (2010-Sep-30)
Views Bulk Operations (VBO) 6.x-1.10
Views carousel 6.x-2.x-dev (2010-Jul-11)
Views Custom Field 6.x-1.0
Views PHP Filter 6.x-1.0-beta1
Views Slideshow 6.x-2.3

This issue has become seriously confused.

Marking as fixed as per #86 and #88.

If problems persist please start new issue(s) with specific details.

thanks for the patch!

an update of ubercart 2.3 to ubercart 2.4 breaks imagecache or imagefield for my site, but if i only apply this patch, the bug is tackled, and imagecache/magefield keeps working !!!