[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