Skip to:

Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#6287 closed defect (bug) (worksforme)

get_invite_count_for_user returning incorrect value (0)

Reported by: rogercoathup's profile rogercoathup Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Core Keywords: reporter-feedback


We are seeing no group invites, even though several exist, on the invitations page for a user (/members/single/groups/inivites.php),

We have a plugin that runs a bp_has_groups() loop on the init action. On the invitations page this causes the subsequent invitations bp_has_groups() loop to fail.

The problem seems to be the wp_cache_get call in get_invite_count_for_user() (line 2425 of bp-groups-classes.php), which is returning 0 (the value from the loop on init in the plugin), rather than the correct value for the invite loop in the invite template.

Change History (4)

#1 @boonebgorges
9 years ago

  • Keywords reporter-feedback added

I've done the following in an mu-plugin:

function bp6287() {
add_action( 'init', 'bp6287', 100 );

Then, in the /members/single/groups/invites.php template,

var_dump( groups_get_invite_count_for_user( bp_displayed_user_id() ) ); ?>

The latter is returning the correct number invitations for the current user.

It's possible that there is some cache pollution going on here, but I'm not reproducing it given the above. Can you please give additional information on how to reproduce the error? Where is the cache being set during the first call to bp_has_groups()? And why would the value being cached be incorrect?

#2 @rogercoathup
9 years ago

I wasn't able to reproduce the problem on a clean test install, so suggest we mark it as invalid.

If time allows I'll reinvestigate on the development site (in the immediate term, I'd worked around by not running the plugin on the invites page).

A little further info -- the loop was being called in a register_taxonomies() function on a new BP Component (it sets up associated taxonomies for each group). The has_groups was parameterised ( show_hidden => 'true', 'per_page' => 10000 ).

#3 @DJPaul
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

If any of us can recreate, we can re-open the ticket. Wouldn't surprise me if this was some odd edge case.

#4 @DJPaul
8 years ago

  • Component changed from API to Core
Note: See TracTickets for help on using tickets.