*bump* anyone able to help? Thanks 🙂
@chouf1 Thanks for your support!
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.
So, anyone-else experienced anything like this?
Oh and @chouf1: WP3.5.1, BP 1.7.1, bbPress 2.3.1, BuddyPress Group-O-Matic Pro, 1.0.3 – 39 plugins in total, I’m not listing them all here.
This gets more intriguing.
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?
hi @rypo73,
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.
Hold on, Rome was not built in 5 mn. 😉
@chouf1
OK – you’re onto something… And it seems your initial hunch of PBCK was spot on – feeling foolish, but enlightened now!
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.
// Don’t record activity for a user or show them as recently active
function my_user_stealth_mode(){
$current_user = wp_get_current_user();
if(is_user_logged_in()) {
if(‘YourUsername’ == $current_user->user_login) {
remove_action(‘wp_head’,’bp_core_record_activity’);
delete_user_meta($current_user->ID, ‘last_activity’);
}
}
}
add_action(‘init’,’my_user_stealth_mode’);
Hope it might be of use to others in future. Thanks for responding to my post. I’m now a LOT more familiar with meta data fields as a result.
p.s. you’re right about # plugins, we do need a lot, but not ALL of those. It’s our dev environment after all. Often a case of playing with different ones to see what fits the bill.
