Bug #7280
closedInconsistencies on Activity Stream on Front Page and Members Page
Added by Luke Waltzer over 7 years ago. Updated about 7 years ago.
0%
Description
User activity as represented on the front page does not correspond with activity represented at https://commons.gc.cuny.edu/members/.
Two screenshots attached.
Files
| Screen Shot 2016-12-29 at 1.30.10 PM.png (110 KB) Screen Shot 2016-12-29 at 1.30.10 PM.png | Luke Waltzer, 2016-12-29 01:36 PM | ||
| Screen Shot 2016-12-29 at 1.35.06 PM.png (161 KB) Screen Shot 2016-12-29 at 1.35.06 PM.png | Luke Waltzer, 2016-12-29 01:36 PM |
Updated by Luke Waltzer over 7 years ago
- Subject changed from Inconsistencies on Activity Stream on Front Page to Inconsistencies on Activity Stream on Front Page and Members Page
Updated by Boone Gorges over 7 years ago
- Category name set to Home Page
- Assignee changed from Boone Gorges to Raymond Hoh
Ray, could you have a look? I wonder whether this is due to the way the widgets are cached.
Updated by Boone Gorges over 7 years ago
- Target version changed from 1.10.7 to 1.10.8
Updated by Boone Gorges about 7 years ago
- Target version changed from 1.10.8 to 1.10.9
Updated by Boone Gorges about 7 years ago
- Target version changed from 1.10.9 to 1.10.10
Updated by Boone Gorges about 7 years ago
- Target version changed from 1.10.10 to 1.10.11
Updated by Boone Gorges about 7 years ago
- Target version changed from 1.10.11 to 1.10.12
Updated by Boone Gorges about 7 years ago
- Target version changed from 1.10.12 to 1.10.13
Updated by Raymond Hoh about 7 years ago
- Status changed from New to Resolved
The related widget caching issue made me come back to this one. Sorry for the bump-a-thon!
With regards to Luke's issue, the actual list of members are correct, but due to the nature of widget caching the active timestamps are not going to be accurate.
I did write a plugin called BP Relative Time that fixes this, but for some reason, it was deactivated on the Commons. I've reactivated it, so this should fix the issue.
Boone - We did add in dynamic timestamps into BuddyPress 2.7.0, which kind of replaces BP Relative Time. But in order to take advantage of that, we'd need to change some markup in our own custom widgets and theme.
The one benefit of BP Relative Time is we don't have to deal with localization issues since it's all in English. BP suffers from the l10n issue that has been discussed in the past on the BuddyPress Slack channel.
Updated by Boone Gorges about 7 years ago
Thank you, Ray! It'd be good to move to BP's native timestamp handling when we get a chance, but it sounds like it's probably not urgent.
Do the l10n issues affect performance? Do I recall correctly that non-en_US domains are only loaded when they're needed?
Updated by Raymond Hoh about 7 years ago
It'd be good to move to BP's native timestamp handling when we get a chance, but it sounds like it's probably not urgent.
Definitely not urgent.
Do the l10n issues affect performance? Do I recall correctly that non-en_US domains are only loaded when they're needed?
No performance hit for the Commons. For foreign BP installs, BP will load up an additional locale JS file by based off wp_locale() if found, so you recall correctly!
The main problem with BP core's timestamps is lack of context. BP just displays X ago instead of active X ago.
An easy way to address this in BP core is to do the following active <span class="timestamp">X ago</span> and just run livestamp on span.timestamp. However, I'm not sure if that works across different languages. We already do this in PHP; for example, see bp_get_member_registered() and bp_get_member_last_active().
I'll create a ticket for BP core about this.