Review order page keeps looping back to itself???

I suggest you first read the other similar issues in this queue where we've enumerated the things you should check, the steps you should take, and the information we need to help you figure out what's going wron on your site.

Specifically, try disabling secure pages, and see what happens. If the problem goes away, there is an error in your secure pages configuration.

I am also experiencing this issue. The following is a repost from http://drupal.org/node/1187632.

Hi,

I am currently encountering this error and would appreciate any kind of help in determining the problem. I am not currently using HTTPS.

As far as I can tell, the "looping" effect mentioned above is occurring for me under uc_cart_checkout_review():

if (empty($_SESSION['cart_order']) || empty($_SESSION['uc_checkout'][$_SESSION['cart_order']]['do_review'])) {
    drupal_goto('cart/checkout');
}

This happens both when I refresh the page (which I imagine is intended) and when I click "Submit order" (which I'm sure is not intended). For some reason the $_SESSION['uc_checkout'] variable is getting set to an empty array, and I can't tell where.

It's not happening before uc_cart_checkout_review_form() is called, because printing this variable inside the form callback returns the correct results. I've also printed the $_SESSION variable at the end of Drupal's index.php file, and uc_checkout dumps out correctly. So I know it can't be anything that occurs from anything invoked while the page is rendering.

When I submit the form, I've confirmed the redirect occurs before any form processing functions are called.

What's strange is that it's as if the uc_checkout variable gets reset right when the session is initialized. To test this, I went to the review form, and then changed index.php so it would only initialize the session without loading any other files. Then I went into drupal_session_start() and dumped $_SESSION right after session_start() is called. The output showed uc_checkout had been set to an empty array.

Those two tests make me feel pretty confident there isn't some rogue module resetting uc_checkout. If that wasn't enough, I changed the name of the uc_checkout variable wherever it occurs inside uc_cart.page.inc, the idea being that if it was some other file or module causing the problem, they wouldn't know to touch the new variable name. But when I did this, and clicked "Submit order", the same behavior occurred; where the new variable was set to an empty array.

This seems to suggest the problem is somewhere inside uc_cart.page.inc. But there are only so many places the variable is reset, and in all my tests, the only time the variable is reset explicitly is inside uc_cart_checkout_form(). Which shouldn't be causing the problem.

I'm wondering if it's some session settings related to my server. This is a different hosting provider than I've used before. But I've compared my current PHP session settings against ones that have worked before, and they're exactly the same. Also, if it were a settings issue, why is it that only one variable gets reset, instead of the whole session? Variables like 'uc_order' and 'uc_addresses' are preserved through the entire process.

I guess I could just comment out the line that's causing the redirect, but does that make the cart insecure?

Again, any help would be greatly appreciated.

Thanks!
Ethan

I wonder if our issues are unrelated, actually, because htalwala's loop happens when "Review order" is clicked. Mine happens on the review page after "Submit order" is clicked. (My original post had a confusing reference to clicking "Review order")

@drum5ormore: I asked you a specific question in that other issue - please answer it. And please read what I said in #1.

Alright, so even though unset($_SESSION['uc_checkout'][$order->order_id]); on line 282 should not be getting called on the review form; even though whenever I print a message above if (empty($_SESSION['cart_order']) || empty($_SESSION['uc_checkout'][$_SESSION['cart_order']]['do_review'])) { on line 375, it always prints before any message inside uc_cart_checkout_form() when an order is submitted; even though all this is the case, when I comment out line 282, I'm able to submit an order successfully.

As such, I made a change to that line to make make extra sure that we're on cart/checkout before unsetting the variable. Like so:

  if (arg(0) == 'cart' && arg(1) == 'checkout' && !arg(2)) {
    unset($_SESSION['uc_checkout'][$order->order_id]);
  }

And now the checkout form works for me. Very weird.

@TR: I believe I did answer your question didn't I? "You might also mention whether you're using HTTPS and whether you've tried turning it off ..."

See my reposting of the issue:

"I am currently encountering this error and would appreciate any kind of help in determining the problem. I am not currently using HTTPS."

That's what you wanted to know right? Sorry if I didn't make it more clear.

Do you have any broken images, any JavaScript or anything similar on your checkout or review pages that may inadvertently be (re)loading /cart/checkout, triggering the unset() by mistake?

Or if you move that unset() inside uc_cart_checkout() does that still work? I still don't see why this works happily for most people but not you, though.

@longwave: your post in #8 was totally the issue. There was a broken image on the page; one of those cosmetic things I was going to take care of after finishing the functionality. I never realized that would cause a reload. Removing that fixed my issue.

Thanks a ton!

Marking fixed based on #10.

If this is not the same problem the original poster had, please reopen with further information.

For anyone still struggling with this issue, I solved it by correcting a theme issue. Another developer on my team had attempted to include an external Google font in the theme's .info file, which was causing an erroneous style sheet declaration. When I removed the line and cleared the cache, it corrected whatever stylization issue I had that was preventing checkout. Hope this helps.

Hey hey! Thanks guys. My looping issue was caused by a jquery script that didn't need to be included on that page. Was made aware of its presence by the console error warning in Firebug.

ubercart-7.x-3.2

Same exact issue here, with Secure Pages and Ubercart, when clicking "Submit Order" at cart/checkout/review, I get redirected to cart/checkout.

After spending a day debugging the same issue, it boiled down to setting a $base_url in settings.php.

I did not have one set.

I can now complete an order under https without getting stuck in a redirect loop, FWIW.

To follow up, my redirect loop was caused by using Addthis-4.0-7.x-alpha1. This issue has been addressed by the latest version - Addthis-4.0-7.x-alpha2. See more about this conflict between Addthis, Secure Pages and Ubercart here.

I did not need to set a $base_url after all.

update

Hoping to save someone some time if they encounter this issue as I did:

Longwave's suggestion in #8 helped me in the right line.
I had a jquery script changing the value of all submit buttons to say "Busy.." when clicked. In retrospect I realise this was a dodgy move, but it caused the looping issue for me, possibly because the review page is expecting a specific value there.
Needless to say I now just add a busy class tag to my buttons.

We can replicate this Notice easily. If some at the Review Order page and refresh the browser then hit Submit donation => They'll see the message.