CUNY Academic Commons

I've disabled BP Widget Cache and BP Relative Time on production and the problem still occurs.

Perhaps there is something wrong with how the member last activity is saved. Will take a closer look after the dev chat.

Boone: Clearing the 'bp_last_activity' cache fixes the problem for the users in question.

The issue is we are not invalidating the 'bp_last_activity' cache often enough.

This problem doesn't show up on the Members Directory page because we are using the legacy user query, which doesn't use the member's last activity cache.

Some suggestions:

• We are not running bp_core_record_activity() in the admin area. We only run it on the 'wp_head' hook, which is only applicable on the frontend. Run this on the 'admin_head' hook as well.
• We do not update the user's last_activity timestamp when an activity entry is added into the DB. Update it whenever an activity item is saved into the DB.

There are probably other instances I haven't thought of where we should be invalidating. Temporary solution would be to default to using the legacy user query everywhere instead of just the Members Directory page.

So this is a BP bug, I take it? I don't suppose we have any idea of the actual places where invalidation is failing to take place (your suggestions are, I assume, guesses?)

So this is a BP bug, I take it?

I think it's because the 'bp_last_activity' cachegroup is not global. Pretty sure this is the case now that I'm looking at the code some more and that members on a sub-site will not be invalidating the right 'bp_last_activity' cache.

Ray, could you make the cachegroup global as a hotfix, and we can monitor to see if this solves the problem? (I'm not sure of a reliable way to reproduce for testing.)

I've added the hotfix on production so we can monitor if this will fix the problem, but haven't committed the change to the CAC repo yet. Let me know if I should.