Skip to:

Opened 2 months ago

Last modified 9 days ago

#8139 assigned enhancement

Network Invitations and Membership Requests

Reported by: dcavins Owned by:
Milestone: 6.0.0 Priority: normal
Severity: normal Version: 5.0.0
Component: Registration Keywords:
Cc: dcavins


I’ve been thinking about how to make network invitations work smoothly, and also what opportunities network invitations and requests offer for sites generally. One of the big improvements we could offer is helping to cut down on spam signups. I’m thinking that if the registration order is changed somewhat, we could prevent non-verified users from adding themselves to the site to have to be removed later.

Possible change to the registration process

  1. Enter your email address and we'll send you a verification code. (This will essentially create a membership request or self-invitation in the invitations table, depending on the registration settings.)
  2. Follow email link (use email address and verification code) to access registration form.
  • Will need to add verification_code field to invitations table. Maybe add a verified column as well (that would be marked true when user completes verification step)?
  • Also maybe need to add a meta column or similar, for follow-on actions, like site or group membership invitations that would be extended upon successful network invitation acceptance.
  • Registration form email address will be readonly so that it is locked to the verified address.

Site invites & requests options for site admin to choose from:

  • Anyone can sign up. Email form will create a “self-invitation” that needs no approval, just verification.
  • Potential users may request membership and be approved by site admins. Email form will create a membership request that requires verification then approval (maybe approval converts the request into an invitation?).
  • Network members can invite people to join. Invitation will be created that requires verification, but is already “approved”

These modes can be mixed and matched, for example:

  • Create a public site - Allow anyone to sign up and also allow invitations to be sent by network members.
  • Create a somewhat private site - New members may request membership and also allow invitations to be sent by network members.
  • Create a pretty private site - Only way to join is by being invited by a current member.

Please share any thoughts you have about other ways we can improve the registration process or other things to think about while designing network requests and invitations.


Change History (9)

This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.

2 months ago

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

2 months ago

#3 @imath
2 months ago

Hi @dcavins

Thanks for starting working on this. Here are my first thoughts.

I would suggest to first list :

  • how joining a site of a network is happening today in WordPress (The network admin can add network members to a site, I don't remember about site admins, new members can create their own site during signup)
  • what are the available types of site: public, hidden from search results (if i remember well)

Create a public site - Allow anyone to sign up and also allow invitations to be sent by network members.

I'm unsure it's possible to sign up for a blog that isn't the root one today. When you say network members do you mean the ones that have a role on the sub site (eg: read at the very least) or any member ?

About private site it doesn't really exist today, we have sites that are not indexed by search engines, but you don't need to be a member of a site to view its content. Are you suggesting to extend WordPress using the blogs component for instance ?

NB: I remember Signups used to create members with no roles on any site, and I think BuddyPress now forces a signed up member to have a role on the root blog.

I also think the BP Invitations API could be used to improve the way members are added to a site by Network admin or regular admins for non MultiSites config. I have the GDPR in mind. Somehow today when an admin is adding a new user to his site there are no proofs the added user gave their consent...

#4 @dcavins
2 months ago

Hi @imath-

Thanks for your comments. Let me clarify a few of my less-than-clear wordings.

  • In this ticket, I'm only trying to accomplish invitations to a BuddyPress instance, I guess that is the "network" or the "base site of a network" though the terminology is pretty sloppy around these concepts. If successful, the user would be added to the wp_users table.
  • "Public" or "private" sites as I'm describing here is not a technical concept. I'm describing how a BP admin could choose to allow registration on her site. At the moment, the options are "anyone can register" and "no one can register." A side goal of this ticket is to allow the BP admin to have more control over new membership, which is a big problem (mostly spam) for the niche networks that I admin. "Anyone can join" works for Facebook, but BP seems to work best when it's more targeted, and less overrun by spammers. So, I see a real opportunity here to offer new modes of membership that fall between "Anyone can join" and "No one can join."

I agree wholeheartedly with your GDPR thoughts, too. That seems like another nice opportunity here.

Thanks again!

#5 @boonebgorges
8 weeks ago

Thank you for beginning the discussion about this, @dcavins ! I agree that the account registration process is a pain point for many BP installations. Spam is sometimes a problem, though there are others: limited customizability (such as multi-step registration), the difficulty of integrating with SSO (those tools often auto-provision accounts in a way that bypasses BP's profile fields), the lack of a built-in invitation system (see Invite Anyone), etc.

For a bit of context, the current registration flow is:

  1. User visits the BP register page
  2. User enters WP account info (username, password, email) and BP profile data, as well as blog info if enabled
  3. A new entry is created in the signups table, which includes user-provided data as well as a confirmation code
  4. An email is sent to the user to confirm their registration. This is the main anti-spam and anti-impersonation prevention measure. The email contains a confirmation link, built using the confirmation code.
  5. User clicks through and confirms registration
  6. The entry in the signups table is converted to a WP user, a site is created if relevant. These steps are handled by WP.
  7. BP saves any xprofile data stored with the signup

Your proposal suggests taking some of the existing flow that's handled by and/or closely mirrors WPMS (such as the signups table for DB storage and the WP-native user creation in f) and putting it into BP.

I have a couple broad questions and concerns about this proposal.

First, by doing ourselves what WP currently does (and has always done), we risk compatibility breaks of various sorts. For example, plugins that modify the WP user registration process, and as such automatically work with WP, may not work in the same way. The same can be said for site-specific customizations. Related, it seems bad for us to add a bunch of infrastructure to BP - like confirmation codes and meta - that duplicate what already exists in wp_signups, if for no other reason than that we don't need the maintenance overhead.

Second, I don't really see how the proposed changes help to mitigate spam registrations. The current system means that the majority of successful spam accounts are generated by real people (automated turk, etc) than by bots. Moving the confirmation email step earlier in the process won't affect that.

I love the idea of having an account invitation system, but it seems to me we could simplify it by using the wp_signups tools that already exist. So, a BP invite could trigger the creation of a signup, but we wouldn't allow WP/BP to send a confirmation email. Instead, we'd send our own invitation email, and the "accept" link would be something like: /register/?key=12345. When we detect key=12345 on the register page, we check for a matching signup, and perhaps pre-fill some of the info, like email. Then, we allow the user to walk through the existing registration system, including the confirmation step. (We might need some mechanism to allow someone from manually entering the confirmation code into /activate/ without going through registration, but this seems fairly minor.)

If we really want to help prevent spam signups, I think there are other things we could focus on, which are independent of the invitation system. BP could ship with things like honeypots; the option for admins to confirm pending registrations; improved integration with third-party services (Akismet?) for pre-screening of invitations; etc.

But I do really like the idea that having out-of-the-box site invitations would allow admins to configure their site in order to limit registration in various ways. As we build, we should think about how and whether this system can be leveraged by people trying to customize registration in yet other ways - I'm thinking especially about institutional SSO (ldap, shibboleth, etc).

#6 @dcavins
6 weeks ago

Thanks for your feedback, Boone. Yes, it would be much simpler to not change the actual registration process, so let's start there.

One question I have about your flow (which mostly matches what I was imagining, probably because I've used Invite Anyone for a long time), is that you say:

When we detect key=12345 on the register page, we check for a matching signup, and perhaps pre-fill some of the info, like email.

This makes it sound like when a user invites a new member, a bare record is created in the wp_signups table. Is this what you were intending? I was imagining that an invitation would be created, and the wp_signup would be created when the user responded (and the various hooks around signup would be fired then, rather than at invitation). In your scenario, when a user "registered" they'd be updating an existing signup, but as far as most plugins were concerned, it would be a registration.

It's an interesting approach, and I'll think more about how we can interact with the wp_signups table as part of an invitations/request process and still keep the existing important hooks around registration intact.


#7 @boonebgorges
6 weeks ago

This makes it sound like when a user invites a new member, a bare record is created in the wp_signups table. Is this what you were intending?

Yes, that was my idea. My main thought was that we could then avoid duplicating features that already exist in wp_signups - particularly activation_key but perhaps also meta (not 100% sure the latter would be needed). There's a trade-off here: by avoiding duplication, we also require a bit of extra work to avoid some of the default behavior of WP when putting entries into the wp_signups table. So it might not be worth it. I guess the overarching principle is to design for simplicity rather than complexity :-D

This ticket was mentioned in Slack in #buddypress by dcavins. View the logs.

6 weeks ago

This ticket was mentioned in Slack in #buddypress by imath. View the logs.

9 days ago

Note: See TracTickets for help on using tickets.