CiviCRM Community Forums (archive)

Hi there,

We have a use case as such:

User tries to sign up for an event, we detect that they are not logged in, and fire them off to a register/login screen in drupal with the 'destination' query string set to the original page. The expected outcome is that, on successful submission of the form and thanks to logintoboggan, the user to taken back to the original page logged in.

There are two breakages I am noticing caused by civicrm.

The first issue is that if we are at user/register, and the destination string is civicrm/page/1, then when civicrm is enabled the page attempts to redirect to /user/civicrm/page/1, as opposed to the normal civicrm/page/1. It's not properly handling the redirection.

The second issue, related to the first, is that we are using logintoboggin to automatically log in upon registering. When civicrm is enabled, we are not automatically logged in. I can see that in logintoboggan, the function handling user registration never makes it passed a call to user_save(): the remaining code in that function — including the code which causes the user to be logged in immediately — is never called.

Both these issues appear to be caused by civicrm listening for hook_user and responding to $op == update. After following a very *long* line of function calls I have discovered that if I comment out line 284 of Controller.php in civicrm3.4.4 (this->_pages[$pageName]->handle($action); , I can stop both these issues from happening.

I've given up following it any further from here, but appears to me that civicrm is responding to a hook_user event, but is never handing back control to drupal to finish up its tasks. This is bad for numerous reasons, not least of all that other modules listening to hook_user aren't being called or (in logintoboggan's case) aren't being allowed to finish their work.

What can we do to fix this?

Torrance has done quite a bit of digging on this already & I think he as gotten to the point in the code where Civi doesn't behave like a 'normal' drupal module.

I would think that Civi would ideally hand back control of the user update hook. I presume it doesn't because it's redirecting the browser at some point in the form controller.

I'm not sure how to produce a useful backtrace for these purposes. However, I inserted a runtime error prior to the method call mentioned previously which allowed me to get an xdebug backtrace up to that point. I'm not sure if it will prove useful.

1. {main}() /sites/egwellness/index.php:0 0.3756 61215008
2. menu_execute_active_handler(???) /sites/egwellness/index.php:17 0.3756 61215104
3. call_user_func_array(string(25), array(0)) /sites/egwellness/includes/menu.inc:349 0.3756 61215352
4. single_user_page_callback() /sites/egwellness/includes/menu.inc:349 0.4094 66110760
5. drupal_get_form(string(13)) /sites/egwellness/sites/all/modules/egwc_custom_modules/single_user_page/single_user_page.module:49 0.7329 103840560
6. drupal_process_form(string(13), array(29), array(7)) /sites/egwellness/includes/form.inc:120 0.7908 104051184
7. form_execute_handlers(string(6), array(29), array(7)) /sites/egwellness/includes/form.inc:421 0.7908 104054864
8. logintoboggan_user_register_submit(array(29), array(7)) /sites/egwellness/includes/form.inc:781 0.7909 104056352
9. user_save(string(0), array(11), ???) /sites/egwellness/sites/all/modules/logintoboggan/logintoboggan.module:354 0.8082 107375528
10. user_module_invoke(string(6), array(14), class stdClass, string(7)) /sites/egwellness/modules/user/user.module:339 0.8128 107399120
11. civicrm_user(string(6), array(14), class stdClass, string(7)) /sites/egwellness/modules/user/user.module:21 0.8128 107400816
12. civicrm_register_data(array(14), class stdClass, string(7), bool, ???) /sites/egwellness/sites/all/modules/civicrm/drupal/civicrm.module:418 0.9891 113063256
13. CRM_Core_BAO_UFGroup::getEditHTML(long, string(0), long, bool, bool, null, bool, string(10)) /sites/egwellness/sites/all/modules/civicrm/drupal/civicrm.module:563 0.9932 113084840
14. CRM_Core_Controller->run() /sites/egwellness/sites/all/modules/civicrm/CRM/Core/BAO/UFGroup.php:582
I should be clear: this ONLY happens when destination is set in the query string, eg. /user/register?destination=/node/1. So it seems very likely that civicrm is seeing the redirect and attempting the redirection itself, as opposed to handing control back to drupal to do the redirection as it should.

There are actually two bugs here: 1. civicrm is doing the redirect instead of letting drupal do it. 2. civicrm isn't redirecting to the correct page. The second issue would be fixed if the first were fixed.

Lobo - where did you spot the conflict? Can we get this patch into 3.4.6? Otherwise I think we need to come up with another solution.

I'm not up on the play with civi internals, but I ran a grep and changed both variables and url strings from 'destination' to 'civicrmDestination' where it looked like it made sense.

So consider the attached patch pre-alpha.

Hi T, patch looks OK in theory ... does it fix your problem?

Yep, logintoboggan works and redirections replace the entire url, not just the last section.

See attached for changes as per Lobo's suggestion.

I'd changed both variables and string names because their were a few instances where I wasn't completely sure what the code was doing (eg. line 54 of ConfigTaskList.php) and wasn't sure if I was writing out to a variable or to the query string. Plus it seemed more consistent.

That patch has been committed to 3.x. I'm not sure if this has also been done against 4.x.