Redirect preventing subsequent submit functions from running
marc.groth - November 2, 2009 - 17:05
| Project: | U Create |
| Version: | 6.x-1.0-beta2 |
| Component: | ucreate.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Hi there,
First off thanks for this great module, it's been really helpful!!
I only have one problem... On line 218 of ucreate.module there is a line of code that redirects the user once the form has been submitted. This line of code stops any subsequent submit function calls from running. I have attached a patch which changes this one line of code from drupal_goto($_GET['q']) to $form['#redirect'] = $_GET['q'], which allows submit functions to be run after create_user_form_submit().
Can this be added to the module? I wasn't quite sure if this was a "feature request" or " bug report" since it seems to fit under both.
Many thanks,
Marc
| Attachment | Size |
|---|---|
| ucreate_redirect_patch.patch | 311 bytes |
#1
Changing title to be more clear and changing status for patch to be reviewed
#2
Yeah, this drupal_goto() needs to go.
Shouldn't $form['#redirect'] be defined in ucreate_user_form() ? I think it does not have an effect in submit callbacks.
#3
Why does the hook_user() even have to exist? Why do we have to redirect the user to change password upon login? If they want to change password they can go to their edit account page.
the hook_user does in fact break other login modules behaviour such as logintoboggan.
#4
You're right alex_b, an oversight on my part. Thanks :)
Attached is a new patch (to be rolled instead of the previous one) which removes drupal_goto() altogether and adds the code $form['#redirect'] = $_GET['q'] to the end of the code in ucreate_user_form() function.
Agree with tayzlor... ucreate_user() seems rather redundant and unnecessary. Can this be removed too?
#5
Attaching patch...
#6
#5 patches the original patch. Here is a patch against UCreate HEAD.
#7
Committed, thank you.
#8
re-opening.
This patch does not play nice with content_profile_registration module.
Again, i ask, is there a need for the hook_user() implementation here?
If someone really wants to go to change their password (again) they can through the edit profile link on their profile.
The problem occurs because the content_profile_user_register_submit() function which fires after the ucreate submit one does not get a chance to fire.
#9
Hang on, isn't the hook_user() issue a different issue? The patch doesn't change anything with that.
If that's the case, please close this issue and open a new one with a description of the problem. I'm open to addressing the hook_user() issue, but I'd like to avoid issue drift.
#10
alex_b you are correct, this is a separate issue which I have created here: http://drupal.org/node/624082
Closing this as the original issue has been resolved.