JS: Login form in Thickbox won't work
| Project: | Extra Voting Forms |
| Version: | 5.x-1.9 |
| Component: | User interface |
| Category: | support request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
Hi,
I've installed the Thickbox module and whenever users need to login (i.e. whenever they are pointed at user/login link) the form opens up in a very cool Thickbox, so that the users don't actually leave the current page.
However, when the anonymous user clicks on the blue UP or DOWN arrows this thickbox won't open up because he is directed to a custom URL which looks like this:
user/login?destination=en-int%2Fnode%2F101
As I understand it, the last number is the node ID, so that the vote is automatically recorded after the user successfully logs in.
I'm wondering if there could be a possible work-around for this little clash of 2 great modules
If it helps, this is what the script of the Thickbox login form looks like:
// $Id: thickbox_login.js,v 1.1.2.2 2007/04/06 08:55:31 frjo Exp $
// Contributed by user jmiccolis.
$(document).ready(function() { $("a[@href*='/user/login']").addClass('thickbox').each(function() { this.href = this.href.replace(/user\/login\??/,"thickbox_login?height=220&width=250&") }) });
$(document).ready(function() { $("a[@href*='?q=user/login']").addClass('thickbox').each(function() { this.href = this.href.replace(/user\/login/,"thickbox_login&height=220&width=250") }) });Alternatively, I'm wondering if I could change anything within the Extra Voting Forms module itself, so as to facilitate this login procedure.
thanks
#1
Hi,
I think it would help if I made the redirection optional.
Doing so would be a _major_ pain, because redirection can happen via Javascript (most likely) or via redirect.
If it happens via JS, which is very likely, it will be difficult to debug and it's likely to require substantial changes to the module.
The extra_voting_forms module will _never_ handle the login process.
I am not marking this as "won't fix". However, you will need to set a bounty or get somebody else to develop this, because the development of this feature is beyond me and my abilities -- it requires changing the Javascript, and Anthony at the moment is not available.
Merc.
#2
#3
Hi,
I think all I need is a pointer at which line is one that creates URLs such as /user/login?destination=en%2Fnode%2F150
and /user/register?destination=en%2Fnode%2F150
And then I can simply delete that extra piece of code and have it as simple user/login or user/register . (Of course, that would create a fork).
Of course it would take away the following workflow: unregistered click on EVF>Register>Vote counted (but I can live with that)
But if you want to integrate that functionality into Drigg in the future in a more sofisticated manner, I guess that's up to you, as I would imagine that could be quite a bit of coding.
thanks
PS: I like that you're sorting the issues out in terms of priorities. I can start seeing the development roadmap ;)
#4
Hi,
I *think* it's more complex than that.
The only way to test this is for me to install ThickBox. Trial and error with you modifying the code is too time consuming.
Bye,
Merc.
#5
I was under the impression that you already have Thickbox (cause you liked my idea for "Thickboxification" of Drigg and the embedded videos). Thickbox is one of those things that allows the end-user to do things without leaving the page (for instance it could be useful for what watcherFR has in mind for the EVB)
Merc, really... this is not a biggie and is far from a priority... and we can postpone these kind of fancy developments until after Drigg is robust, stable and fast.
Do you want to mark this issue as "postponed"?
#6
Hi,
I want to investigate it first. It might be a 1-liner, or it might be nasty.
Will keep you updated...
Merc.
#7
Hi,
Is anybody still interested in this?
Merc.
#8
Hi,
This is a Javascript issue. For now, all of the Javascript issues are going to be marked as "postponed". I am looking for somebody to work with who knows JS well and who is willing to lend a hand to get these solved. Only one of them is a bug, and the module has very virtually no open issues... which is what we want.
Merc.
#9