I could be missing something but this seems to be a big problem.

When you click the Review order button in the checkout the order is saved to the database.
- Why now, the order is not yet complete???

You can then click back and then cancel and you are back on the checkout page.
- Also, when clicking cancel the order is not removed from the database.

You can then remove all your products from the cart and the products don't get removed from the order in the database.

Next time you add a product to your cart and go through the motions you create a new order.
(if you just go back to the cart and then back through checkout without changing products it also creates a new order and the old one is orphaned)

The original order is now orphaned in the database and doesn't even show up in the admin orders page.

This can cause numerous issues.
If modules are implementing hook_order with the save op they are operating on an orphaned order which could be quite bad
depending on what the module is doing.

Why isn't the order initially saved when clicking submit order instead of review order?

This would also be much better for anonymous user checkout because the new user account
would be available at that stage for the sake of people implementing hook_order for the save op.

Comments

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Subbing. Is this still an issue?

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

The order has to be saved at the "review order" step because the "submit order" button is sometimes hijacked by payment modules to POST to a third party site to complete the transaction, in which case Ubercart would never know that the order should be saved.

I'd actually prefer it if the order was created and saved to the database when the checkout page was first loaded, as this would avoid the problem of the order object sometimes existing on the checkout page (if the user has already seen the review screen), which has to be handled by some modules that make changes during the checkout process. Abandoned orders that are at "in_checkout" status are not a problem as far as I can see.

torgospizza’s picture

torgospizza
he/him
Primary language English
Location Portland, OR
commented

Sounds like this is really "by design" then, unless you want to write a patch that saves the order at the initial checkout stage, that or this seems more of a support request than a bug.

tr’s picture

tr commented
Status: Active » Closed (works as designed)

Yes, this was by design. The only problem the original post points out is:

This can cause numerous issues.
If modules are implementing hook_order with the save op they are operating on an orphaned order which could be quite bad depending on what the module is doing.

and IMO this is easily avoided by checking the order state in hook_order() to ensure that you don't take action on an in_checkout order. You could even just trigger on the state change if that's really what you're trying to do.

I'm open to the possibility that there should be an additional case, say 'insert' for the initial order creation, then rename 'save' to 'submit' in analogy with the hook_nodeapi() cases. That would break a lot of contributed modules, so I wouldn't want to do it in a minor release.

It would be even easier if orders were nodes, then we'd get all these lifecycle hooks for free and not have to invent our own. However, that's not going to happen. Orders will eventually be entities in the Drupal 7 version of Ubercart, which should help a lot.

shenagarg’s picture

shenagarg commented

I am wondering then how we can use hook_order to detect if order is successfully checked out i.e. payment is done and order is placed.