Skip to:

Opened 12 years ago

Closed 12 years ago

Last modified 9 years ago

#4348 closed defect (bug) (fixed)

data being updated but not appearing on front end

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


On a WP 3.4, BP 1.6 beta 2 install -

No caching plugins of any kind, including object
No forums enabled or installed.
The only activated plugin is BP.

So far, I see two examples of the front end not showing correct data that exists in the database.

  1. Members tab - Members count is wrong
  1. bp_xprofile_visibility_levels

I added a field group (Sports) and a field (Golf) with 'Let members change the this field's visibility' selected.
The visibility_level can be changed on the front end.
The change appears in wp_usermeta -> bp_xprofile_visibility_levels for that member.
The front end always shows the 'Default Visibility' selection.
Tried it both as a required and not required field.

To be sure it wasn't some caching issue on our server, I had Rackspace, in this order:

  1. Restart apache to flush APC
  2. Restart varnish
  3. Restart memcache to flush sessions
  4. Restart mysql server

But the issue is still there.
Also tried deleted all history, cookies etc in browser.

I don't see this issue on

You can see this on:
subscriber login: asdfshane, asdfasdf

I see this issue for both admin and subscriber log-ins.

Change History (14)

#1 @shanebp
12 years ago

The bp_xprofile_visibility_levels settings are being honored - ie. only friends can see fields set to 'My Friends'.

So it's the Editing Some Profile Group - 'Who can see this field'
that does not show the correct db value.
This is consist across Chrome, IE and FF on my win7.

#2 @boonebgorges
12 years ago

  • Milestone changed from Awaiting Review to 1.6

Re: visibility level. This appears to be due to a typo on my part. Fix is coming.

#3 @boonebgorges
12 years ago

(In [6174]) Fixes 'enabled'/'allowed' type in BP_XProfile_Group::fetch_visibility_level()

See #4348

#4 @boonebgorges
12 years ago

  • Keywords reporter-feedback added

Re: members count. Can you explain how it's wrong? Note that there was a change in the way this count worked for 1.6: #4235, #4061

#5 @shanebp
12 years ago

Re: visibility level. 6174 is confirmed as the solution.

Re: members count. Will look into this further and try the 'old bp_get_total_site_member_count()' referred to in 4235.
Meanwhile, here is a screenshot that shows active members and an incorrect Members count:

The 'old bp_get_total_site_member_count()' approach shows the 'correct' Members count.
But I think the issue remains open.

btw - could you re-open #4235 ?
I absolutely see the merit in the change in approach - but how you did it bears some discussion. Figured you want such opinions on that ticket.

Last edited 12 years ago by shanebp (previous) (diff)

#6 @boonebgorges
12 years ago

shanebp - The issue in your screenshot may be related to the changes in #4235, but not by design. The number in the All Members tab should be *the same as* the number in the pagination phrase "of x active members".

I can help to try to debug, but first I need more info on your setup. Are you running Multisite? How many users are there in your wp_users table? Have you spammed or deleted any users on this test installation?

#7 @shanebp
12 years ago

boonebgorges -

Not Multisite.

3 users in wp_users

Have not spammed or deleted any users.

#8 follow-up: @boonebgorges
12 years ago

shanebp -

What do you get when you run the following query?

SELECT ID FROM wp_users WHERE user_status != 0;

How about this one?

SELECT COUNT(user_id) FROM wp_usermeta WHERE meta_key = 'last_activity';

#9 in reply to: ↑ 8 @shanebp
12 years ago

Replying to boonebgorges:

SELECT ID FROM wp_users WHERE user_status != 0;

Result: zero rows

SELECT COUNT(user_id) FROM wp_usermeta WHERE meta_key = 'last_activity';

Result: 3

#10 follow-up: @boonebgorges
12 years ago

How about this?

select option_value from wp_options where option_name = '_transient_bp_active_member_count';

I'm guessing it'll return 1, which means that your transient is stale.

The transient is designed to be refreshed on the following actions:
'bp_core_activated_user', 'bp_core_process_spammer_status', 'bp_core_deleted_account'

I've probably missed a spot. How did you create the users in question? Through the Dashboard? Through a normal front-end registration? Do you have any plugins that modify the registration process?

#11 in reply to: ↑ 10 @shanebp
12 years ago

Replying to boonebgorges:

I'm guessing it'll return 1

Yes, return is 1

How did you create the users in question?

The admin was created upon WP install - so that is the '1'
The 2 subscribers were created thru wp-admin - Users - Add New

Do you have any plugins that modify the registration process?


So reliance on 'bp_core_activated_user' for new signups is the issue, yes?
Then users created thru wp-admin-add-user, and imports, and front-end registers in installs that bypass (don't require) the emailed activation link are not going to be included in active member count.

#12 @boonebgorges
12 years ago

shanebp - Yes, you're right. The real issue is that we need to detect the first activity by a user. We don't have an action for that at the moment, but I'll add one.

#13 @boonebgorges
12 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [6179]) Introduces bp_first_activity_for_member action, and busts member count cache on it

The bp_first_activity_for_member fires when a user's last_activity meta value
is set for the very first time (typically, on login). Busting the total member
count cache on this event ensures that the active member count in the All
Members tab will always reflect the most recent count.

Fixes #4348

#14 @johnjamesjacoby
9 years ago

  • Version changed from 1.6-beta to 1.6
Note: See TracTickets for help on using tickets.