12 replies [Last post]
quaoar's picture
Offline
Bug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.Not Kulvik
Joined: 08/08/2007
Juice: 179
Was this information Helpful?

Not quite sure which version this is, because the "; $Id$" in the .info files and // $Id$ are not set Smiling
But we put that site online a month ago, which should give some clue about versions being used.

Anyway, we do -not- have anonymous checkout enabled. Nevertheless orders are registered with uid set to 0. Billing information is registered and everything else seems to be ok. This happens for both payment options made available for the store.

So it seems like something must allow the uc_cart_checkout_form_submit in uc_cart to execute without the user being registered as logged in?...

Anyone experience the same?

Erlend Strømsvik
Ny Media AS
erlend@nymedia.no

webmasterkai's picture
Offline
Uber DonorBug Finder
Joined: 08/09/2007
Juice: 299
Re: A small problem: uid = 0 on some registered orders

What status do the orders have? Are they "in checkout"? I've never seen an order with uid 0 with a status other than "in checkout".

Biodiesel * (ubercart + drupal) = Sundays Energy

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: A small problem: uid = 0 on some registered orders

Erlend, curious if this is still an issue. Could it possibly be happening because you have disabled the customer checkout pane? If so, that's a silly mistake on my part and should probably be changed...

jchatard's picture
Offline
Joined: 12/10/2007
Juice: 41
Same here

Hi I've the same problem here.

From time to time new client registering during checkout have no account created.

All seems to work (paid, completed, etc.) but user->uid == 0.

Do you have any information on that ?

I'm on D5 + Ubercart 1.5

Jérémy

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Same here

Hmm... I'm not sure Jeremy. This was a bug in an earlier version, but I believe it was fixed for the 1.5 release. You might double check that your uc_cart.module got updated... there's also a new release since 1.5 that you can deploy.

jchatard's picture
Offline
Joined: 12/10/2007
Juice: 41
Ryan, Here's the code from

Ryan,

Here's the code from my uc_cart.module Ubercart 1.5

<?php
function uc_cart_checkout_form_validate($form_id, $form_values) {
  global
$user;

  if (empty(

$_SESSION['cart_order'])) {
   
$order = uc_order_new($user->uid);
   
$_SESSION['cart_order'] = $order->order_id;
  }
  else {
   
$order = new stdClass();
   
$order->uid = $user->uid;
   
$order->order_id = $_SESSION['cart_order'];
   
$order->order_status = uc_order_state_default('in_checkout');
  }

 

$order->products = unserialize($form_values['cart_contents']);

 

$order->order_total = uc_order_get_total($order, TRUE);

 

// Validate/process the cart panes.  A FALSE value results in failed checkout.
 
$_SESSION['checkout_valid'] = TRUE;
  foreach (
element_children($form_values['panes']) as $pane_id) {
   
$func = _checkout_pane_data($pane_id, 'callback');
   
$isvalid = $func('process', $order, $form_values['panes'][$pane_id]);
    if (
$isvalid === FALSE) {
     
$_SESSION['expanded_panes'][] = $pane_id;
     
$_SESSION['checkout_valid'] = FALSE;
    }
  }

 

$order->line_items = uc_order_load_line_items($order->order_id, TRUE);

 

uc_order_save($order);
}
?>

It seems to be right. And I just can't update to Ubercart 1.6 right now. But I don't think this will fix the problem.

Do really have no idea of what's going wrong?

Thanks

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Ryan, Here's the code from

The function in question is actually uc_cart_complete_sale(). There was a confusion in the use of $user vs. $account in the older versions that had this bug. Compare the 1.6 version of the function to yours to see if you can find/fix the bug.

jchatard's picture
Offline
Joined: 12/10/2007
Juice: 41
Thanks Ryan, I've just made

Thanks Ryan,

I've just made a diff between the 2 version of the function 1.5 and 1.6

They are exactly the same.

No progress so far. Can it comes from uc_adresses?

Jérémy

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Thanks Ryan, I've just made

Not sure. It could be, but I haven't done any testing with that module.

baller's picture
Offline
Joined: 12/03/2008
Juice: 2
Same problem

Hi all,

I have the same problem.
Many new orders form new users (but not all) generated normaly, but user->uid == 0.

1+more thing: This case (uid=0) the auto generated (flat rate) shipping cost disapiered from the completed order.

I tried but I can't create the same "wrong" order advisedly.

Any idea?

(Übercart 1.5)

b.

hinrichsislcocom's picture
Offline
Bug Finder
Joined: 05/28/2008
Juice: 92
same issue (?)

We have the same or similar issue.
Info:
1) User placing the order is registered
2) User is able to complete an order and data looks correct on completed orders
3) But there are "duplicate" orders created before the completed order is created, in state "in_checkout".
4) The anomalous in_checkout orders have uid==0
5) For each anomalous order created==modified
6) The user is not aware of a problem (at least not the ones we were able to ask)
7) The same user may go on and make many orders that do not have this problem; also orders just before this order did not have the problem (we were fortunate to get a single customer who made a large series of orders in one sitting).

I have no info on whether the shipping disappeared as the previous example because this guy got free shipping due to a discount.

We are using https, secure_pages module.

We are using payflowpro, with the patch applied that supposedly addresses the comeplte_sale order duplication bug.

This problem has existed over several months, and we have kept ubrcart (for Drupal 5) up to date.

We are going to ask the customer about this anomalous order to see if there was anything unusual he recalls about that particular order placement (e.g. navigating into the http pages after hitting the confirmation page but before placing the order, etc., etc.)

I have read some posts and it seems likely that transitioning between http and https could be the point of failure--the user session being lost, the uid being set to 0 when the page is submitted, then the session being restored after the order is saved so that the correct order is created.

Bob Hinrichs
ISL Consulting
http://www.islco.com

digitalfrontiersmedia's picture
Offline
Getting busy with the Ubercode.
Joined: 11/08/2008
Juice: 282
Re: same issue (?)

I'm also noticed the same issue as hinrichislcocom. We're also experiencing issues with the SSL & SecurePages. I believe it may be related to the type of SSL being used. Not sure if that's connected to the User 0 generation on http-https switching though.

subscribing

hinrichsislcocom's picture
Offline
Bug Finder
Joined: 05/28/2008
Juice: 92
more info

Hi! We have continued to look into this problem.

(eight) we spoke to a user who had this issue. She was using IE6, which crashed on her during the checkout process. This required her to restart the browser and come back to finish. I don't think it's relevant that she was using IE6, but it is that the browser quit and she came back..

Here are the steps to re-create the problem as reported by our project manager:
1. Anonymous user connects to site, item is added to cart.
2. "Checkout" button is used to take user to checkout form
4. User fills out checkout form completely and clicks submit to review order
5. User's browser is closed (IE6 sometimes crashes here)
6. User re-opens browser and follows steps 1-3 again. Ubercart remembers the user's shopping cart on entry.
7. User must re-enter all information on checkout form again and click submit
8. If user is able to complete checkout process, order moves into "completed" state, while leaving the original order from the previous browser session "in checkout" in the Drupal backend.

There is even more relevant information, including some questions of security, but right now my thought is, if it is smart enough to remember my cart, maybe it should be smart enough to use the old order id/record if I enter similar info on the checkout form (e.g. email address).

This seems like a more or less harmless feature/bug except it creates problems for our client when order ids are "skipped." (One of those things I would question, but cannot--I know we could create a custom counter for them but that is another issue).

Bob Hinrichs
ISL Consulting
http://www.islco.com