Possible bug – last_activity missing

Hi there. On a dev site we have a handful of users. As of about 48 hours ago, one of those users disappeared from the ‘who’s online’ or buddypress members plugins. Delving into it, I see that user has no last_activity row in the wp_usermeta table. They’re active all the time on the site – several times a day. Their activities appear and trigger the associated notifications etc. (friend requests, etc.)

I inserted a row into the table with an incremented umeta_id and set a date/time value of yesterday evening. They then ‘reappeared’. However, the next time they logged in to do something, that row got wiped out altogether and we’re back to square one.

Anyone-else experienced this? Anything we can do bar delete their user from the dbase and start over? Is it likely there will be other ‘corruptions’ in the dbase? Can you recommend a tool/plugin to ‘check’ the dbase for integrity or ‘fix’ a BuddyPress inconsitency?

So an update. When I set the affected User to ‘Subscriber’, they appear in the BuddyPress ‘Members’ widget with a ‘last_activity’ value appearing in the dbase (wp_usermeta table). However, changing them (back) to ‘Administrator’ they drop off the radar again.

We have 2 others with Admin role who are not affected in the same way.

After removing the affected user altogether and creating their user all over, I still have the same issue. Giving them any other role than Administrator and they show up as ‘recently active’, but with Administrator role, they don’t!

Are you going to suggest it’s a plugin conflict that affects a single-user?

wow ! That’s not a web site you have, but a plugin plant !
39 + BP = 46 plugins, aïe aïe aïe caramba
I suspect you have a setting somewhere who exclude admins from some process. But because suspition is not knowledge, you have to over test anything.

Revert back to a standart install first: WP + BP 1.7.1 with bp-default theme. And try to follow those advices:

1 – never touch the original table structure untill you know what you do
2 – deactivate all your plugins except BP and make your registering tests for each kind of user role
3 – activate bp-default while testing
4 – reactivate the plugins one by one and test the register process
4a – after an hour, you will probably understand why 46 plugins are a pain
5 – make a break in the stress: drink a coffee or a beer before continuing your test
6 – if you absolutly need the Group o’matic plugin,update it. It’s now version 1.0.4
7 – ensure all plugins are updated before reactivate them.

SO… I had some code in my custom-functions.php file to ‘hide’ the site admin activity (see below). Because we have several users with ‘Administrator’ roles, it seems this particular user was affected. Others MAY have been if they had logged in more often…

Seems this code was not the best to use:
// Don’t record activity by the site admins or show them as recently active
function my_admin_stealth_mode(){
if ( is_site_admin() ) {
global $bp;
remove_action(‘wp_head’,’bp_core_record_activity’);
delete_user_meta($bp->loggedin_user->id, ‘last_activity’);
}
}
add_action(‘init’,’my_admin_stealth_mode’);

SO I’ve removed it in favour of THIS version, specifically masking the activity of INDIVIDUAL users with ‘Administrator’ roles, like our site admin user.