I'm not familiar w/ any issues with anonymous checkout. Can you verify what version of UC you're running? I'll go try it on the Livetest right now...

Open mouth, insert foot. It may just be general server issues, since I had some HTTP requests failing, but I did end up with one anonymous order going through fine and creating the appropriate user account. The second went through fine but didn't attach it to the previously created user.

Yeah...hmmm... I'm just using the 1.0 release with the credit card debug sandbox. Maybe I have some awkward session settings on my server or a conflicting module installed? Bizarre though, everything else in ubercart works totally fine.

Thanks for taking a look at it!

Yep, I'll keep looking into it. There may be at least one bug in the way we're generating new user accounts. Let me know if your testing turns anything up, too.

So it appears that the problem is that sessions are being unset, all over the place, when they shouldn't be. I tried commenting out what appeared to be the relevant calls to unset corresponding $_SESSION['var'] instances, but still no fix. I had some success in various scenarios in doing this, but nothing that let the anonymous checkout process work in whole.

In addition, this session disappearing issue is also apparent when I disable anonymous checkout, for instance when the user is redirected to login before checking out, the ?destination=/cart/checkout does not show up in the form action.

This bug must be related to the one found http://www.ubercart.org/forum/bug_reports/4713/checkout_problem

Which is still unresolved.

So here's what happened...

Somewhere along the way I lost the "0" user, the blank user with a uid of 0, from the user table. I've installed, modified, and written tons of modules on this drupal install, so I have no idea where along the line this happened, but it did.

Because drupal sessions use an inner join rather than a left join (for some frustrating reason), anonymous sessions where saved to the database but not properly read (since the result was null). The tricky part here is, is that cookies functioned fine, and sessions that were instantiated would last until the next page reload (since they of course can exist via the declaration alone)...so the behavior wasn't obvious.

To make things even worse, I, like several over individuals who I have seen having the same problem over the interwebs, have attributed the error to ubercart over drupal (since ubercart seems to be one of the few modules that uses sessions on anonymous users).

Cheers!

Thanks for taking the time to post back such a comprehensive reply. I really appreciate you toughing it out and finding a solution. I also just fixed and committed the bug that was there that caused UC to fail attaching anonymous orders to pre-existing accounts.

In the function uc_cart_complete_sale() in uc_cart.module I had to change $order->uid = $user->uid; to $order->uid = $account->uid;. (Was line 1718 in my working version.)

I tried checking to make sure I still have the blank user with UID 0 and I did, and I tried changing the proper code to "$order->uid = $account->uid;". Anonymous checkout works fine in Internet Explorer, it just doesn't work in Firefox? What else can it be?!

Thanks peacetaker - I've been debugging this one for hours now. Worst thing was, I know this was working last week, but this week it doesn't. Turned out I'd also lost my 0 user.

Funny thing is, the same thing happened on another Drupal site that's been in production for a few months now. That one doesn't use Ubercart at all, but I was getting some other funny behaviour (I forget what it was now) which was resolved by restoring the 0 user.

Does anyone have any clue what causes the 0 user record to be removed from the users table?

I'm really glad people decide to post back with what their problem and solution was! I just had the same thing!

I posted about it here: http://drupal.org/node/262669#comment-1113759

It looks like my user 0 was removed during a phymyadmin export/import and I fixed it by going to the users table, browsing it, then editing the row that was for the anonymous user, but had the wrong uid...

Thanks!