[buddypress-trac] [BuddyPress Trac] #6210: Create New Invitations API
buddypress-trac
noreply at wordpress.org
Thu Mar 14 21:32:21 UTC 2019
#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):
Hi Boone,
Thanks for your message. As long as you are creating or fetching
invitations via a manager class, the class name should always be
sanitized:
https://github.com/dcavins/bp-svn-bporg/blob/6210-Aug2018/src/bp-
core/classes/class-bp-invitation-manager.php#L364
The property `class_name` is set (and the sanitization occurs) in the
construct method:
https://github.com/dcavins/bp-svn-bporg/blob/6210-Aug2018/src/bp-
core/classes/class-bp-invitation-manager.php#L33
Are you thinking that you'd like to see the sanitizing happen not in the
manager class but down in the invitation object class?
Yes, I've been hoping for some blast of inspiration on how to deal with
`bp_get_user_groups()`. The sticky bit is that `bp_get_user_groups` caches
by the ID in the membership table. The best workaround I've thought of so
far is to prefix the "ID" of invitations and requests with the name of the
invitations table or similar, to avoid cache collisions. Then, I'd have to
add some logic to `bp_get_user_groups` that checks the ID to see where the
membership data should come from. Of course, blending IDs like that will
cause an order by ID sort to fail, but I guess it should, since they're no
longer apples to apples.
I'll write up a quick fix, and we can see how gross it really is.
Thanks again for reading over the patch!
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6210#comment:30>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list