Ubercart has the option to supply an "Alternate checkout completion page" via admin/store/settings/checkout.

The standard uc_cart_checkout_complete() runs prior to the redirect to this custom completion page. This does, among other things, the following:

unset($_SESSION['uc_checkout'][$order->order_id], $_SESSION['cart_order']);

How is a store meant to reliably/cleanly fetch order information necessary to display relevant information at their custom completion page, when the relevant session data (in particular $_SESSION['cart_order']) is seemingly nuked before the user lands there? (Bare in mind that one can for an example allow anonymous checkout without logging the user in after checkout - so one will not necessarily have a userid to query for their "last order" or similar hacks either.)

Last time I looked into it... the only solution I found that ensured consistent behaviour, in the time I had at my disposal, was to leave the checkout completion page path at default and use hook_menu_alter() to replace the callback with a custom implementation. That's obviously very hacky and less than ideal in terms of upgradability and such though.

From what I can see the cart related functionality uses $_SESSION['uc_cart_id'] to load the cart contents, and there is a safeguard in place for the checkout page where it will unset $_SESSION['cart_order'] and throw the user back to their cart if the order has changed status.

So if I were to supply a patch to allow some way of passing order info on to the "Alternate checkout completion page" - would it be acceptable to let $_SESSION['cart_order'] live beyond uc_cart_checkout_complete() and leave it up to the custom completion page to unset it? Or should we introduce a new session variable for this purpose alone - such as $_SESSION['last_completed_order']?

The latter would perhaps be the cleanest - to avoid users getting a "Your session has expired or is no longer valid. Please review your order and try again." if they try to shop again on the same session, and the custom completion page failed to unset $_SESSION['cart_order'] (the developer forgot to add it, or whatever...).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

longwave’s picture

Status: Active » Fixed

The "alternate checkout completion page" is a legacy setting, and it probably should be removed in a future version.

The easiest way to display custom information is to leave this setting at the default, and override theme_uc_cart_complete_sale() in your theme. This function is passed the entire $order object, so you can display whatever you need. If you need the checkout completion page to appear on a different URL, you can simply alias cart/checkout/complete to whatever you like.

sigveio’s picture

Not quite sure why we didn't just use the theme override back when we did the "last resort" hook_menu_alter() workaround (it's a while ago) - but I'm sure there must have been a reason, because it'd normally be the first option to look at. I guess it's possible that the "Alternate checkout completion page" simply gave us a bad case of tunnel vision... :P Thanks for the tip nonetheless.

I'd suggest adding a description that indicates that it is deprecated - that way people will know not to use it. :-)

longwave’s picture

Title: Alternate checkout completion page - order info » Deprecate alternate checkout completion page
Category: support » task
Status: Fixed » Needs review
sigveio’s picture

Issue summary: View changes

Crossed out unnecessary stuff, seeing as the issue title/task has changed.

longwave’s picture

Title: Deprecate alternate checkout completion page » Remove alternate checkout completion page
Version: 7.x-3.x-dev » 8.x-4.x-dev
Status: Needs review » Active

Let's just remove this entirely in 8.x-4.x, as I don't know of any good uses for it.

longwave’s picture

Status: Active » Needs review
FileSize
4.94 KB
longwave’s picture

Status: Needs review » Fixed

  • longwave committed b38d5ca on 8.x-4.x
    Issue #2119493 by longwave: Remove alternate checkout completion page
    

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.