[buddypress-trac] [BuddyPress] #4916: Wrong wording in activity

[buddypress-trac]

#4916: Wrong wording in activity
--------------------------+---------------------
 Reporter:  chouf1        |       Owner:  chouf1
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  1.8
Component:  Activity      |     Version:  1.7
 Severity:  minor         |  Resolution:  fixed
 Keywords:  has-patch     |
--------------------------+---------------------

Comment (by boonebgorges):

 Thanks very much for the comment, nacin.

 > At which point we need a number_format_i18n()

 Good call. I've opened a new ticket for it, as it's an issue we should
 address wherever we display similar counts.

 > It would probably make sense for bp_get_total_mention_count_for_user()
 to only be called once

 Yes. I was going to fix this, but I'd have to introduce a variable into
 the global scope in the template, which we normally do not do. Thus, I'd
 have to abstract the whole bit into a standalone function. But we have
 other similar content counts (groups, friends, etc) that would have to get
 similar treatments in order for the template to be consistent. As so often
 happens, fixing a small thing would require big changes, so I've left well
 enough alone for the moment :)

 >  I also noticed that it defaulted to $user_id = 0, but 0 will end up
 just returning false down the stack in get_metadata() — so it should
 either not be a default value, or a default of 0 should mean the current
 user at some point before it reaches get_user_meta().

 I agree that it'd make sense for this function, and others like it, to
 default to the displayed user when no value is passed. But it's possible
 that this'll break backward compatibility with plugin/themes in some edge
 cases, so it needs more consideration. #4998

 > what is the purpose of bp_loggedin_user_id() and how is it different
 from get_current_user_id()?

 As far as I know, the main purpose is that "this is the way we have always
 done it". We can't just switch over to the $current_user object, because
 there are certain other pieces of data that BP adds to the loggedin_user
 global ("domain", which is the profile URL; whether he's a super admin;
 the "fullname", which is loaded in different ways depending on how BP is
 configured and which therefore may be different from
 $current_user->display_name). As for the filter, it may indeed be
 "suspect" to make such a value filterable, but it *is* filterable, and we
 can't just tear it out without breaking something. I totally agree with
 the general sentiment that it'd make BP more approachable to a WP dev if
 this object were the same as $current_user and if we used WP functions in
 place of the BP wrappers. But it'd require a large amount of work to make
 the necessary changes in a way that didn't break backward compatibility,
 for what is, relatively speaking, a marginal benefit. Which is to say that
 there are places in BP where we could make changes in a similar spirit -
 better use of WP's tools, better parity with WP syntax, and so on - which
 would have a much higher impact on newcomers to BP.

 Thanks again for the thoughtful comments.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4916#comment:7>
BuddyPress <http://buddypress.org/>
BuddyPress