I’m working on a site right now that uses the Social Login plugin by OneAll, which is the first time I’ve dealt with users logging into a WordPress account via social networks. The plugin works really well, but I ran into one major issue: new user accounts were being created when matches weren’t found.
This particular project is a BuddyPress site for a fraternity; brothers can log in to see private events, content, and the full roster but the general public can only see the public pages. There’s also a public roster page with basic information about each member (name, graduation year, major, etc.), but those are dynamically generated by listing all BuddyPress members (excluding my team’s accounts, of course). Out of the box, OneAll would create a new user account for anyone who tried to log in, resulting in my mug appearing in the roster right along all the registered fraternity members…yikes!
To get around this, I was able to hook the following function into the oa_social_login_action_before_user_insert action, which OneAll calls before inserting the new user into the database:
|
1 2 3 4 5 6 7 8 |
/** * Prevent OneAll from creating a new user account */ function grunwell_prevent_oneall_user_creation() { wp_redirect( wp_registration_url() ); exit; } add_action( 'oa_social_login_action_before_user_insert', 'grunwell_prevent_oneall_user_creation' ); |
This ends up preventing the user from being imported while redirecting the user to the registration URL (on that project, /registration/). I simply created a page that had something to the effect of “we couldn’t match that email to any accounts in our system, please contact X if you’re supposed to be in the system.”
If your site will sometimes enable registrations, it’s probably a good idea to wrap the contents of our callback function in if ( get_option( 'users_can_register' ) ) { ... }; if registration is allowed, you’d might as well let OneAll do it for you!
Leave a Reply