data being updated but not appearing on front end

[shanebp]

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

2. 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 testbp.org

You can see this on:
​http://shanebp.bearcentral.com
subscriber login: asdfshane, asdfasdf

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

[shanebp]

addendum:
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.

[boonebgorges]

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

[boonebgorges]

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

See #4348

[boonebgorges]

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

[shanebp]

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:
​http://nationalyoga.com/bp/Untitled2.png

[boonebgorges]

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?

[shanebp]

boonebgorges -

Not Multisite.

3 users in wp_users

Have not spammed or deleted any users.

[boonebgorges]

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';

[shanebp]

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

[boonebgorges]

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?

[shanebp]

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?

No

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.

[boonebgorges]

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.

[boonebgorges]

(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