[buddypress-trac] [BuddyPress Trac] #4676: Resend activation key link/page
buddypress-trac
noreply at wordpress.org
Tue Mar 25 17:42:18 UTC 2014
#4676: Resend activation key link/page
-----------------------------------------------+-----------------------
Reporter: sooskriszta | Owner: r-a-y
Type: enhancement | Status: assigned
Priority: normal | Milestone: 2.0
Component: Administration | Version: 1.0
Severity: major | Resolution:
Keywords: ui-feedback ux-feedback has-patch |
-----------------------------------------------+-----------------------
Comment (by boonebgorges):
This technique looks good to me.
> I was thinking, what about using the login widget instead of the wp-
login.php page ? this way user's would be able to eventually not use it.
I'm not sure I understand the question. Do you mean we should hijack WP's
redirect back to wp-login.php on a failed authentication? That seems a bit
outside the scope of this ticket (and it would be pretty complicated,
because we'd have to figure out whether a login widget appeared on the
page we planned to redirect to).
> We might also have to figure out how other authentication plugins like
WP Email Login or LDAP will work with this.
I took a look at a number of authentication plugins, including simple-
ldap-login and wp-email-login. They all work in a similar way: hook into
'authenticate', return the $user object if it's already legitimate,
otherwise run their own authn and then return either a WP_User or a
WP_Error. So our technique should work smoothly with any of these setups.
As a precaution, we could move our priority higher. But even that
shouldn't be necessary, since in any case where we might interfere with
another plugin - eg, when an LDAP plugin is auto-provisioning users -
`bp_core_signup_disable_inactive()` will bail with `return $user` well
before we start messing with the error message.
> I think this is a valid point. Perhaps we can add two email addresses to
the signup form similar to how we have a confirm password field.
I like this idea, but I don't think we have time to implement this
properly for 2.0. Let's open a separate ticket for it.
4673.04.patch reworks the documentation a bit to give more focused
background for developers.
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4676#comment:16>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list