Home » Forums » Ubercart » Bug Reports

A small problem: uid = 0 on some registered orders

Submitted by quaoar on Wed, 10/10/2007 - 07:22
quaoar

Posts: 50
 Joined: 08/08/2007
Bug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.Not Kulvik

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
permalink #1 Wed, 10/10/2007 - 11:53
webmasterkai

Posts: 94
 Joined: 08/09/2007
Uber DonorBug Finder

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

permalink #2 Mon, 10/22/2007 - 12:01
Ryan

Posts: 5617
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

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...

permalink #3 Thu, 11/06/2008 - 07:36
jchatard
Posts: 14
 Joined: 12/10/2007

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

permalink #4 Thu, 11/06/2008 - 09:09
Ryan

Posts: 5617
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

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.

permalink #5 Thu, 11/20/2008 - 08:53
jchatard
Posts: 14
 Joined: 12/10/2007

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

permalink #6 Thu, 11/20/2008 - 10:35
Ryan

Posts: 5617
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

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.

permalink #7 Thu, 11/20/2008 - 10:45
jchatard
Posts: 14
 Joined: 12/10/2007

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

permalink #8 Thu, 11/20/2008 - 11:03
Ryan

Posts: 5617
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

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

permalink #9 Wed, 12/03/2008 - 08:44
baller
Posts: 1
 Joined: 12/03/2008

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.

permalink #10 Thu, 12/18/2008 - 19:09
hinrichsislcocom

Posts: 14
 Joined: 05/28/2008
Bug Finder

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.

permalink #11 Fri, 12/19/2008 - 13:24
digitalfrontier...

Posts: 20
 Joined: 11/08/2008

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

--

Digital Frontiers Media

permalink #12 Fri, 12/19/2008 - 17:16
hinrichsislcocom

Posts: 14
 Joined: 05/28/2008
Bug Finder

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).