Add option to only show password login form after a click (solely appearance)
Closed this issue · 17 comments
I run my own blog and I would love for Clef to be the default login choice when I attempt to login to wp-admin/
.
What do you think about adding a new option to make Clef the default and have a link at the bottom of the page to show the regular WP login?
I assume you've seen the ability to make Clef the only login?
This is definitely a good idea and I'm supportive of it — I'm not sure when I'll have the dev time to get it done, but if someone else makes a PR it will definitely get merged in.
I can see benefits to both of those suggestions.
Scott
On Jan 21, 2014, at 4:24 PM, Patrick Rauland notifications@github.com wrote:
I run my own blog and I would love for Clef to be the default login choice when someone attempts to login to wp-admin/.
What do you think about adding a new option to make Clef the default and have a link at the bottom of the page to show the regular WP login?
—
Reply to this email directly or view it on GitHub.
P.S. When BFTrick speaks, everyone listens ;-)
But seriously... On another note, when I tested Clef for WP a few months ago, it was difficult to understand the secret back door for logging in with Clef. I suppose the opposite could also be coded too. But it's mostly for emergencies, right?
I assume you've seen the ability to make Clef the only login?
Yup yup. I want Clef to be the default option and to have a backdoor in case I need it.
I'll take a look at the code base and see how hard it is.
So, what exactly is the difference between the current functionality and what it currently has? I think I'm a little confused.
If you just want the appearance of Clef as the default (but the ability to login with passwords), maybe we could just not render unless you click a link, which adds a certain param.
Jesse. That sounds good... 'the appearance of' being the default by hiding the regular sign in box until clicking a JavaScript unhide link ... The more options the better!
If you just want the appearance of Clef as the default (but the ability to login with passwords), maybe we could just not render unless you click a link, which adds a certain param.
Yup correct. That's what I'm thinking. I want this for a couple reasons.
- If Clef is the default it means less clicks to login
- Cleaner
- I still have a backdoor in case I misplace my phone
One thing I'm a little worried about with this is that we're adding too much complication to the settings here. This would give the user 4 unique choices around password vs. Clef usage for login — kind of overwhelming.
I might recommend the following hack instead: disable passwords, then in the code that renders the login footer, just add a link with your override key appended to the login URL. Or you could add it here.
This definitely isn't a general solution, for sure, but it does what you want.
I'd be interested in hearing what y'all think about this confusion tradeoff.
@jessepollak I was also thinking that it's getting too complicated. That's one of the reasons I didn't jump in on this right away.
Can we nest the options? That might help. The three sub points would only be shown if the parent option is checked.
- Enable Clef login
- Allow passwords
- Disable passwords for Clef users
- Disable passwords for all users with privileges greater than or equal to ___
- Hide the password form and only display it after a button click
I like that idea of nesting the settings. Putting it on my todo.
Or, if you're interested, a PR would be accepted with this change.
@jessepollak I haven't done many backend UIs with more than a few settings. What is the standard for hiding and showing fields in the backend? Just enqueue a JS file and use some jQuery / jQuery UI to do that?
I've been hiding fields on the backend by just not adding them. To be honest, I have no idea whether that's a good strategy or not.
@jessepollak hmm well I wouldn't do it that way since it would probably require a refresh to show the new fields. I would assume you just enqueue your own JS to hide the fields when appropriate.
Yeah, I guess that's not the best...I'm down with the jQuery route.
Thanks for the contributions. Functionality shipped in 2.2.
This took a little longer than we would have liked, but we think it's turned out awesome :)