Skip to:

Opened 3 years ago

Closed 6 weeks ago

#6210 closed enhancement (maybelater)

Create New Invitations API

Reported by: David Cavins Owned by: David Cavins
Milestone: Priority: low
Severity: normal Version:
Component: Core Keywords: dev-feedback, trac-tidy-2018
Cc: david.cavins@…


Create a flexible API to create/retrieve invitations across components.


  • invite to a group
  • invite to the site
  • invite to a blog
  • invite to edit a doc


  • Write tests for group invitations. (See #6209)
  • Write core invitations API code.
  • Switch group invitations over to using invitations API.
  • improve group invitations experience
  • Add new features.

Data structure

On one hand, it makes sense to use a dedicated table for this like we do with notifications, but it could easily be built using a new custom post type and post meta (since Boone’s been souping up WP_Query's meta queries...)

I would really appreciate some feedback on which way BuddyPress wants to go with future data and the positives of each approach.

If a table, here are the fields I’m imagining:
id - primary key
user_id - ID of invited user, maybe 0 if invitee is not a site member
inviter_id - ID of user that created invite, maybe 0 if a request for membership
invitee_email - used when invitee is not yet a member of the site
component_name - e.g., groups, similar to activity/notification
component_action - to cover components that need several invitations
item_id - e.g., group id in the case of a group invitation
secondary_item_id - flexibility for components
content - store extra information provided by inviter/requester
date_modified - date created or date invite sent
invite_sent - 0 if draft, 1 if sent.
opt_out - Has this user asked to receive no more invitations from a component?

Group Memberships

Currently, outstanding group memberships are stored in the group members table and identified via a combination of statuses. I’m thinking that users who have been invited or have requested membership would exist only in the new invitations table.

Areas for improvement/Adding new features

  • Allow multiple invitations to a group from different users, as imath proposed—this helps with transparency.
  • Allow site admins to decide if members can only invite friends to groups (current behavior), or if users can invite any site member.
  • Apply the new suggestions API to the group invitation pane. (Can it be extended to display status messages like “Violet Vance — already a member”?)
  • Allow invitation of non-site members to the site and groups, like Invite Anyone.
  • Maybe provide centralized invitations pane for user with status. Could be a new tab, or maybe should be under some other tab—there are a lot of navigation options on the user’s profile already—could notifications about invites contain actions for responding to invitations/requests?
  • Improvements to invitations UI so that it’s clear what status each invitation has—draft, sent (and when)—and the ability to resend.
  • Improved invitation management for group admins and site admins (via wp-admin groups management pane).

Attachments (1)

6210.01.patch (158.5 KB) - added by David Cavins 23 months ago.
Adds nw invitations table. Switches group invites to use new invitations API.

Download all attachments as: .zip

Change History (24)

#1 @John James Jacoby
3 years ago

  • Milestone changed from Awaiting Review to 2.3
  • Priority changed from normal to low


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

3 years ago

#3 @Paul Gibbs
3 years ago

Looking at this at a high level, why is this a Component? The only current feature that would use an Invitations Component are Groups. You list possible cases such as "invite to site", "invite to edit a doc", but all those would rely on third-party functionality.

My initial reaction is that I'm unsure why promoting this specific piece of Group functionality to its own Component would make sense. (I don't think every plugin for BuddyPress is going to require user invitations)

#4 follow-up: @Boone Gorges
3 years ago

I agree with DJPaul that there's no need for an Invites component, but I also think that dcavins never suggested one :-D

#5 @Paul Gibbs
3 years ago

Maybe I'm just being too pedantic; one of the top lines in the patch says "Classes used for the Invitations component." ;)

#6 in reply to: ↑ 4 @John James Jacoby
3 years ago

Replying to boonebgorges:

I agree with DJPaul that there's no need for an Invites component, but I also think that dcavins never suggested one :-D

The patch is setup as src/bp-invitiations.

I would love for this to be some kind of "common" library (similar to what we are envisioning attachments to be?) with a universal approach towards inviting members to do things.

  • Join groups
  • Join a site/network
  • Join a private message thread
  • Become friends
  • Third party components like events, docs, chat, etc...

If that means making it a full-fledged component, I'm fine with that approach, but we will want unit test coverage on existing invitations code to ensure nothing breaks.

If we went the component route, we would want to default it to on for upgrades, and let each component continue to work as before, and decide whether or not new installations should be "invitation" friendly networks, or whether that's worth allowing someone to turn on.

Last edited 3 years ago by John James Jacoby (previous) (diff)

#7 @David Cavins
3 years ago

  • Cc david.cavins@… added

I've been thinking about the component-ness of this ever since talking with @jjj about it, and I still don't think it needs to be a component (as I understand components to be--core code that includes critical user-facing functionality and is on a par with "activity" or "groups").

However, once you add the ability to invite someone to the site or to manage a variety of invitations in a central interface, that probably happens via the user profile (like Invite Anyone). Since "add new features" is pretty far down the list (ha ha), I'm still considering this as a library, not a component, with the thought that some critical and awesome user-facing functionality to be named later could cause it to grow into component-ness.

I'm really building a helper library at the moment, although I'm taking many code design cues from the notifications component. I will also be taking cues from @imath's work on the non-component attachments API.

Also, trac, why don't you email the ticket creator when the ticket is updated? :)

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

3 years ago

#9 @Paul Gibbs
3 years ago

  • Milestone changed from 2.3 to 2.4

#10 @r-a-y
3 years ago

Maybe we can think of invites as a pending signup in the wp_signups table.

wp_signups already has a meta column, but it's pretty much ugly. Perhaps all that is needed is a wp_signups_meta table?

That way, we can attach information about what groups, friends, etc. that this signup user should be a part of once the user successfully registers.

#11 @David Cavins
2 years ago

  • Milestone changed from 2.4 to 2.5
  • Owner set to David Cavins
  • Status changed from new to accepted

Punting to next version. I'm going to scale back what I'm trying to do to get the core changes in place and then add new features. I was taking too big of a bite at one time. :(

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

2 years ago

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

2 years ago

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

2 years ago

#15 @David Cavins
2 years ago

  • Milestone changed from 2.5 to Future Release

It's so sad to punt this (again). :(

@David Cavins
23 months ago

Adds nw invitations table. Switches group invites to use new invitations API.

#16 @David Cavins
23 months ago

I've just added a new "progress" patch. In it, I've worked out many of the details of saving, updating and retrieving invitations from the new invitations table and switched BP groups to use the new core functions for their invitations and requests. There are plenty of places I see to make improvements, like letting the group invites rely on default core invite behavior more.

The biggest questions mark for me is that this change removes pending members from the groups_members table. It seems like a nice improvement, but it really messes with BP_Groups_Member_Query. I'd love some feedback on how this could work more smoothly--I hacked something together but I have doubts. Many tests are failing because of how group invites are created in the tests (new BP_Group_Member( $args )), which could be fixed in the tests, but, geez, are people in the wild using the BP Group Member class in that way? If so, this idea just got harder. :)

Also feedback on my caching mechanisms would be very helpful (especially the bits where I'm filtering lists of invitations to avoid making more database calls). Of course, any feedback is helpful--this is a big lump of code changes.

Moving to a new table will also require an upgrade method, which is still to be worked out.

Thanks for your comments!

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

22 months ago

#18 @Paul Gibbs
21 months ago

  • Component changed from API to Core

#19 @Paul Gibbs
21 months ago

  • Type changed from task to enhancement

#20 @David Cavins
21 months ago

Now that I have an understanding of how the business parts of invitations could work, I was thinking about how to make it more like an API. The two approaches that came to mind were:

  • handling it like the BP_Group_Extension class or the BP_Attachment class with stub functions that new implementations should include to specify the behavior they need.
class BP_Invitations_API {
public function send_invitation() {}
public function verify_invitation() {}
public function accept_invitation() {}
  • handling it more like the class WP_Customize_Setting, by declaring callbacks via some helper function, like
bp_register_invitation_set( array(
	'send_invitation'   => 'my_send_invitation_callback',
	'verify_invitation' => 'my_verify_invitation_callback',
	'accept_invitation' => 'my_accept_invitation_callback',	
) );

Does BP have a preference for what style we'd like to use?

#21 @John James Jacoby
21 months ago

Other than the _API suffix (which I assume was just paraphrasing code) I think this type of code clarity is exactly what BuddyPress needs more of, specifically for Invitations, and to wrap around the otherwise relatively complex and procedural logic involved with site invitations in WordPress.

I also think the array of arguments that gets passed into any registration function will require more scrutinization, but I think you have the right idea, so keep running with it. I imagine @boonebgorges will have deeper examples of existing patterns that could be useful as starting off points.

#22 @Paul Gibbs
6 weeks ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see
or find us on Slack, in the #buddypress channel:

#23 @Paul Gibbs
6 weeks ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.