[buddypress-trac] [BuddyPress Trac] #6210: Create New Invitations API

[buddypress-trac]

#6210: Create New Invitations API
-----------------------------------------+-----------------------
 Reporter:  dcavins                      |       Owner:  dcavins
     Type:  enhancement                  |      Status:  reopened
 Priority:  low                          |   Milestone:
Component:  Core                         |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  dev-feedback trac-tidy-2018  |
-----------------------------------------+-----------------------

Comment (by dcavins):

 Replying to [comment:35 boonebgorges]:
 > @dcavins I wonder if we could avoid much of the calisthenics in
 `bp_get_user_groups()` by using a different cache group, and handling
 invites and memberships totally separately. So:
 >
 > {{{
 > $membership_ids = wp_cache_get( $user_id,
 'bp_groups_memberships_for_user' );
 > // prime caches, etc
 >
 > $invitation_ids = array();
 > if ( invites need to be included ) {
 >   $invitation_ids = wp_cache_get( $user_id,
 'bp_groups_invitations_for_user' );
 >   // prime caches, etc
 > }
 >
 > // Loop through memberships as currently happens in the function, and
 assemble membership objects
 > foreach ( $membership_ids as $membership_id ) {
 >     // ...
 >     $groups[ $group_id ] = $membership;
 > }
 >
 > // Then loop through the invitation objects and fake them as
 "memberships"
 > foreach ( $invitation_ids as $invitation ) {
 >   $invitation = wp_cache_get( ... );
 >
 >   $invite_membership_obj = new stdClass();
 >   ...
 >
 >   $groups[ $group_id ] = $invite_membership_obj;
 > }
 > }}}
 >
 > No extra `non_cached_keys()` overhead; we only fetch the invitations
 when they're actually requested (I think this is just
 `is_confirmed=false`?); we keep the cache keys easier to understand and
 track; and the logic of `bp_get_user_groups()` is easier to follow.
 >
 > I started working on a patch, but before putting the work in, I wanted
 to check whether there was a reason for not going this way instead.
 >
 > Migration routine looks fine - I think the numbers will be small enough
 that this'll work.

 Hi Boone, yes, I have another branch that took that approach, so can
 easily verify that it works and share it. Essentially, invitations and
 requests are only needed if `is_confirmed = false || null`.

 I'm not sure that adding a special cache group
 `bp_groups_invitations_for_user` is needed, given that invitations are
 individually cached, and the SQL query results are cached using an
 incrementor. So doing a `groups_get_invites()` call should always hit the
 cache first anyway. The only advantage is that you wouldn't have to
 reformat the cached invitation objects as fake memberships, but I'm
 assuming that's a pretty low overhead operation.

 Thanks for looking it over!

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6210#comment:36>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac