When the "Use UC Node Checkout to prevent anonymous node add access for node types it governs" setting is enabled for Node Checkout, and the create node_type content is granted for anonymous users so that they are forced to log in before adding a checkout node to their cart, the user is not redirected back to the checkout node create page. Instead, they are left at the user profile screen. This is because the module sets the redirect url in $_SESSION['node_checkout_redirect'] and then does a drupal_goto() to /user, and then attempts to read that value from the SESSION variable in uc_node_checkout_form_alter after the user has logged in. The problem is that the SESSION variable has been wiped out when the session is killed as part of drupal_goto(), so it is not there to read later.
The attached patch gets the current destination, and then passes it to drupal_goto() as the $query parameter (i.e. ?destination=/path/to/checkout/node/create). This is then picked up by the Forms API and the user is redirected back to that page after login or profile creation.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | uc_node_checkout_redirect.patch | 881 bytes | dwightaspinwall |
| #5 | 409134_201003172043+0700.patch | 1.83 KB | sammys |
| #4 | uc_node_checkout.patch | 748 bytes | PaulHruska |
| uc_node_checkout_anonymous_redirect.patch | 1.56 KB | wonder95 |
Comments
Comment #1
wonder95 commentedWell, it turns out that this patch works fine where the user exists and just logs in, but not when the user has to create a new account. The destination parameter is saved when the user gets to /user, but when you click on the Create New Account link to go to /user/register, that parameter is removed from the URL, so the user is just sent to the normal screen after creating the account instead of being redirected. The best way seems to be what the module was originally doing - storing the location somewhere and then referring to it later to modify the $form['#redirect'] value - but the issue is where to store it since $_SESSION gets wiped out as part of drupal_goto() and isn't available later when needed. One possibility is the session table, which would be a pain. Anybody have suggestions of where to store this?
Comment #2
socialnicheguru commentedsubscribing. I am not sure if I should implement this module.
HOW do you get to the CHECKOUT NODE create page? I am new to ubercart and don't understand this?
Figured it out...
Comment #3
artatac commentedsubscribing
Comment #4
PaulHruska commentedI ran into the same problem, and came up with an independent solution, before I checked the issues queue.
The attached patch saves the requested URI instead of calculating a redirect based on the 'type' of content type. In my testing it preserves the URI even after creation of an account.
Please consider the attached patch...
Paul
Comment #5
sammys commentedHere's my patch for this bug report. It adds session variables for the product node ID and quantity so when it redirects after an account is created it won't bounce you to the product selection form (if you're using a view) and will show you the node editing screen.
It's working for my limited test cases at this point. YMMV and I don't expect this to cover all bases yet. Just a starting point for anyone working on it.
Comment #6
dwightaspinwall commented@PaulHruska, I think you're patch is on the right track, but it didn't work for me when the uri contains a query string. In that case, $form['#redirect'] expects an array. I've attached a patch that works for me.
Comment #7
aidanlis commentedComment #8
aidanlis commentedNone of these patches are on the right track ... I'm going to postpone this, if someone has would like to sponsor this development please reopen the issue.
Comment #9
dwightaspinwall commentedCan you explain why the patch in #6 is not good? Does it introduce a bug?
Comment #10
aidanlis commentedFirstly, thanks for attempting to patch - it's definitely appreciated!
However, there's usually two ways to fix a problem: at its source or where it manifests. Fixing a problem at its source is usually harder and often requires an intimate knowledge of the rest of the application. The alternative however results in these strange chunks of code littered throughout the codebase (e.g. "preg_match('!^/?([^?]+)\??(.*)!', request_uri(), $matches);"), often in duplicate, and make fixing the source of the problem more difficult when it manifests later.
I know it seems a little counter-intuitive to not apply a patch when it fixes the problem in favour of leaving it broken ... and it is, so I encourage you to dive a little deeper and see what you can come up with :)
Comment #11
tr commentedComment #12
stewart.adam commentedFor what it's worth, this is confirmed to be working with current 6.x-2.x git for users that need to login.
As mentioned in the original post this never really worked for user registrations because the destination gets destroyed (plus they may have to perform email verification first, so a redirect after that isn't necessarily something we would want anyways).