Opened 11 years ago
Last modified 5 years ago
#2084 assigned defect (bug)
Frontpage tabs - show if content is available
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Awaiting Contributions | Priority: | minor |
Severity: | normal | Version: | |
Component: | Activity | Keywords: | needs-patch |
Cc: |
Description
On the frontpage we have all the tabs:
- My Friends,
- My Groups
- My Favorites
- @username Mentions
The first 3 only shows up if there's actual content inside them. Like if you don't have a friend the "My Friends" tab won't show up on the frontpage.
The last one "@username Mentions" always shows no matter if there's content or not. I think it should have same properties as as the other 3 meaning it should only show up if you have any mentions.
Attachments (1)
Change History (9)
#4
@
10 years ago
- Keywords dev-feedback added
Not tested, but approach looks okay to me. Like you say, phpdoc needs correcting (might be worth making a comment about the renamed function's legacy behaviour for anyone grepping the source).
#5
@
10 years ago
- Keywords needs-patch added; has-patch dev-feedback removed
- Milestone changed from 1.3 to 1.4
After some discussion, Paul and I decided it would be more efficient to store total mention count in usermeta (incremented on new mentions), to avoid the extra lookup. Patch should be rewritten accordingly.
I'd like some feedback on the attached 2084-1.patch. In order to get the mention count I had to write a new database method, and I wrote some other functions (similar to what exists for groups_total_groups_for_user() ) to make sure the count could be filtered and cached. The big change I want feedback on has to do with function names. bp_total_mention_count_for_user() was being used to get the *unread* mention count, not the total like the name suggests. So I renamed bp_total_mention_count_for_user() to bp_new_mention_count_for_user() and usurped the name. Is this a bad idea? (They're easy to switch back if so.)