not working with content profile module ?

Have you verified that login destination is causing this? Please be sure to disable the module and test the workflow again to see if the problem persists. Post you results back here.

I have tested and confirmed a conflict with the Content Profile module.

The conflict is between login_destination.module and content_profile_registration.modul -- login_destination uses drupal_goto to redirect upon user logins via hook_user, and content_profile_registration uses hook_user_register_submit to save content profile fields. It appears that hook_user_register_submit is not being called after the drupal_goto redirect.

I have tried various work-arounds but have not been able to find a viable solution to fix this conflict and am open to suggestions.

I'm having the same problem with the MailChimp module (see #685352: Mailing list registration not working for registered users), i.e. the Login Destination implementation of hook user was getting executed before the mailchimp_subscribe_auth_form_submit submit handler was being executed.

After having done a bit of digging around I found a post at #277512: Using drupal_goto in form submit handler prevents the use of multiple submit handlers which seems to support setfree's comment about drupal_goto made in #5. Unfortunately I have no workaround to offer up yet. I'm going to try the Login Toboggan module to see if that gives me the same functionality without breaking MailChimp as I have a deadline to hit but if that fails, I'll come back to this and do some more investigation.

Is there some way of forcing the login_destination_user to be the last one run? Maybe something to do with module weights? I'm at the limits of my Drupal knowledge here so these are just guesses.

I've also noticed that Login Destination's redirect behaviour conflicts with Services module, in particular the user.login service.

Setting the weight of Login Destination higher than MailChimp, Content Profile and Services, or indeed whatever module is having problems may be the most effective solution to this.

I can confirm the conflict between login destination and use content profile on registration. Content profile is not created when login destination latest stable version 2.10 is enabled.

I tried changing the login destination weight to 9999 in the systems table but that didn't resolve the issue.

I have rolled back to login destination 2.5 which dosn't have this bug.

Why not rules-module for this kind of action?

subscribe

@stevenghines -- did LoginToboggan work better for you?

Login toboggan worked for me,

TMK, there really no reason to call drupal_goto on a form submission other than to break the current process, as there's already a drupal_goto at the end of the form submission. It was already setting the $_REQUEST['destination'] so that should be enough. (Though, I think it should make sure destination is not already set, but that's another issue).

@jocken Something like "User has logged in" Then "Load content by id" ?

A similar post in Content Profile .. http://drupal.org/node/485284

Can do this with the Rules Module instead...

ON User has Logged In

DO Page Redirect

You can even write an "if" condition in rules to prevent the redirect from happening. E.g. to prevent people from skipping the Ubercart checkout complete page, an if condition:

<?php

function getMyPath() {
	$current_path = explode('=', drupal_get_destination());
	if(is_array($current_path) && count($current_path) >= 2) {
		if(trim($current_path[1]) != ''){
			  $current_url_full = htmlspecialchars( urldecode($current_path[1]) );
			  $current_url_elements = explode('?', $current_url_full);
			  if(is_array($current_url_elements)) {
				return trim($current_url_elements[0]);
			  }
			  else{
				return trim($current_url_elements);
			  }
		}
	}	  
}

//drupal_set_message('evaluating rule.. current path is ' . getMyPath());
if ( getMyPath() == 'cart/checkout/complete' ) {
	return false; //rules condition is false, will not redirect
} else {
	return true;
}

?>

Sorry if off topic.

Thanks for the remove_drupal_goto.patch this works for me.

Thanks can confirm patch works for me as well on 2.10

#13 made it work though i have content profile module..
do remember to uncheck "Return user to where he/she came from. (Preserve destination)"
if you want the user to go to a custom page...
cheers

I find this works correctly when the latest version is 6.x-2.12 .

However I noticed, it doesnt work if we have triggers/actions enabled for user login action.

guys, you know that the patch has been committed already? so "needs review" is kind of a pointless state.. basically it should be "fixed", and reopened to "active" if anybody is still encountering an issue :)

(I was just about to apply the patch myself when I found out that it was already.. a little confusing this :))

Looks like it was commited with http://drupal.org/cvs?commit=442738, but the issue wasn't updated. (My guess is people don't check the CVS repo when there's an active issue).

Yay it's commited!

I'm confused. Is the conflict still there?

Changing from calling drupal_goto() to setting the $_REQUEST['destination'] withdraws the possibility to redirect to an external URL. That is because of the goto implementation that does not allow for an url to be passed by the destination variable. Though in my opinion it is better to have the compability over feature-richness. Hacking the form and making it pass the url directly to the the form goto may be a way to go but haven't tried yet.

I have changed the way of handling redirect to something similar to how it is advised in drupal documentation (http://drupal.org/node/134000) - by setting the $form['redirect'] variable. However because the submit function in user module overrides it, I had to add a custom submit handler instead and set the redirect in it.

It brings back the support for external URL's and it looks to me like a better method of handling redirects.

And the patch.

In the $form_id switch at line 174, I guess the user_register is missing. When a user is redirected to the drupal site, from an external site along with a destination-parameter like:

link from external pointing: "www.drupalsite.com/user/register?destination=http://www.external.com/whatever"

I have tested with the 'user_register'-case, and seems to function well. Trying to apply the patch..- Coming up :)

The updated patch.

trying again..- sorry can't delete the other.

@all: Today I've setup the content_profile 6.x-1.0 and login_destination latest git dev on a drupal core 6.37 I tested with one custom content_profile field and registering a new user . The redirect worked ok!

Tested with static-url/php-url/redirect-back-to-where-they-were - all works!

I guess some parts/ similar code to the above patches's logic has been commited since 2012.

So marking this one too as fixed. With relief and apology for the long delay!

I found out what fixed it: somebody in 2010 commented out the drupal_goto usage in the redirect, leaving only upto the destination parameter.

Recently I made it possible to choose whether to use drupal_goto. It is off by default, covering this issue's case and all works here.