Project

General

Profile

Bug #7280

Inconsistencies on Activity Stream on Front Page and Members Page

Added by Luke Waltzer 8 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Home Page
Target version:
Start date:
2016-12-29
Due date:
% Done:

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.

Screen Shot 2016-12-29 at 1.30.10 PM.png View (110 KB) Luke Waltzer, 2016-12-29 01:36 PM

Screen Shot 2016-12-29 at 1.35.06 PM.png View (161 KB) Luke Waltzer, 2016-12-29 01:36 PM

History

#1 Updated by Luke Waltzer 8 months ago

  • Subject changed from Inconsistencies on Activity Stream on Front Page to Inconsistencies on Activity Stream on Front Page and Members Page

#2 Updated by Boone Gorges 8 months ago

  • Category 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.

#3 Updated by Boone Gorges 8 months ago

  • Target version set to 1.10.7

#4 Updated by Boone Gorges 7 months ago

  • Target version changed from 1.10.7 to 1.10.8

#5 Updated by Boone Gorges 7 months ago

  • Target version changed from 1.10.8 to 1.10.9

#6 Updated by Boone Gorges 7 months ago

  • Target version changed from 1.10.9 to 1.10.10

#7 Updated by Boone Gorges 6 months ago

  • Target version changed from 1.10.10 to 1.10.11

#8 Updated by Boone Gorges 6 months ago

  • Target version changed from 1.10.11 to 1.10.12

#9 Updated by Boone Gorges 6 months ago

  • Target version changed from 1.10.12 to 1.10.13

#10 Updated by Raymond Hoh 5 months 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.

#11 Updated by Boone Gorges 5 months 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?

#12 Updated by Raymond Hoh 5 months 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.

Also available in: Atom PDF