Making Login Destination, Thickbox, and MiniMenus Play Nicely
| Project: | Login Destination |
| Version: | 5.x-1.0 |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hey, all.
After a little playing around, I thought I'd share this in case someone else wondered about this in the future.
I really like the MiniMenus module that sits at the top of the page with quick links to login and register pages, plus additional pages when a user is authenticated. I ran across a hiccup when I had the Thickbox module activated to enable Thickbox for logins: redirection would not work. If I manually typed user/ at the end of my url, I could login with the standard form and Login Destination worked just fine. However, with MiniMenus, the user would remain at the previous page after logging in. I figured this was a MiniMenus issue, and found it after some brief hunting.
I figured someone besides me might want to use MiniMenus and Thickbox, while employing Login Destination.
So, bring up the minimenus.module file and make your way to the end:
else {
$links = array();
$here = $_GET['q'];
$links[] = l(t('login'), 'user/login', array(), "destination=$here");
$links[] = l(t('register'), 'user/register', array(), "destination=$here");
$block['content'] = theme('item_list', $links, NULL, "ul id=\"account-menu\" class=\"mini-menu menu account anon\"");
}
}
return $block;
break;
}
}
}It's that first destination=$here that is causing the hiccup. Simply change $here to login_redirect and you have everything working just fine.
You should now be able to click the MiniMenus login link and trust Login Destination to do its thing properly.
Thanks for a helpful module.
#1
Thanks for sharing! This is just what I needed, even if I did not know I needed it yet.
#2
Anytime. I'm glad to help. While I haven't yet taken a plunge into custom module development, I am constantly reworking stuff to make them play nice, as I had to do here.
Now I wish I kept some better notes on things. I could probably write a book of tips for people who are just getting into deeply customizing their themes and sites.
Thanks, Drupal, for a world-class CMS.
#3
Thanks for finding this issue!
It's quite critical. The problem occurs because login_destination module uses 'destination=' parameter to perform redirection. Minimenus also uses it.
Changing $here to login_redirect is a good temporary patch but this issue needs good permanent solution.
I wonder, why Minimenus uses destination? They want to get user back on the page where he was before clicked login link? If so, can we implement this logic as a snippet for login_destination? In this case we can just remove destination from Minimenus at all.
Another fix is determine current destination specified in GET somewhere in login_destination.module in order to take a user on that page upon redirecting. And create a settings checkbox "Preserve destination" or something like that. In this case other module may use destination and login_destination module will be able to keep it and don't perform its own redirection.
#4
Guys, please try the new 5.0 development release.
There is also a new Preserve destination feature. You can turn it on and when logging from the path like this one 'any-page?destination=node/18' you will be taken to node/18 instead of the page specified in login_destination settings. This makes the module sensible to destination parameter. Uncheck this feature and redirection will always take place in accordance with module settings.
I wonder, will it help to solve the problem with original Minimenus?
I also added $_SESSION['login_page'] variable which stores the page you were before clicking login form button. You can use it to determine the page instead of $_GET['q'] because $_GET['q'] will always equal to 'login_redirect'. Now you can easily create the snippet you need.
Thanks.