Project

General

Profile

Actions

Bug #3917

closed

New homepage display errors

Added by Matt Gold about 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Home Page
Target version:
Start date:
2015-03-17
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

Thanks very much for applying the hotfix in http://redmine.gc.cuny.edu/issues/3910

The page looks improved, but I am seeing errors in the ordering of most recently active members. Please see the attached screenshot -- the ordering is mixed up, with some more recently active members listed above less recently active members


Files


Related issues

Related to CUNY Academic Commons - Bug #3910: Home Page Display ErrorsResolvedBoone Gorges2015-03-12

Actions
Actions #1

Updated by Boone Gorges about 9 years ago

  • Assignee changed from Boone Gorges to Raymond Hoh

Ray, can you please take a look?

Actions #2

Updated by Raymond Hoh about 9 years ago

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.

Actions #3

Updated by Raymond Hoh about 9 years ago

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.

Actions #4

Updated by Boone Gorges about 9 years ago

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?)

Actions #5

Updated by Raymond Hoh about 9 years ago

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.

Actions #6

Updated by Boone Gorges about 9 years ago

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.)

Actions #7

Updated by Raymond Hoh about 9 years ago

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.

Actions #8

Updated by Raymond Hoh about 9 years ago

  • Status changed from Assigned to Resolved

Hotfix looks like it is working. I have added the fix in commit cd6110f in both 1.7.x branch and master branch.

I've also opened a ticket on BuddyPress Trac with this info:
https://buddypress.trac.wordpress.org/ticket/6299

Boone, should I be tagging this as a release as well? I think CAC 1.7.15.2 on the dev blog explains the same issue so I've opted not to tag at the moment.

Actions #9

Updated by Boone Gorges about 9 years ago

  • Target version set to 1.7.16

Thanks, Ray. It's not technically part of 1.7.15.2 (which has already been tagged), so let's put it in the next maintenance release.

Actions

Also available in: Atom PDF