[buddypress-trac] [BuddyPress Trac] #5827: bp_is_user_profile() and bp_is_profile_component() return false on profile subpages

buddypress-trac noreply at wordpress.org
Wed Aug 20 18:26:22 UTC 2014

#5827: bp_is_user_profile() and bp_is_profile_component() return false on profile
 Reporter:  jreeve        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |

Comment (by boonebgorges):

 Thanks for the report.

 This is a semantic issue. From BP's point of view, the 'profile' component
 is only what you see when looking at your Extended Profile data. In a
 default installation, this is `/members/[username]/profile/`, but if
 you've changed the default component to be the xprofile, it would be
 `/members/[username]/`. `bp_is_user_profile()` will also return true when
 looking at subpages of the profile, such as

 While pages like `/members/[username]/groups/` are part of a user's
 "profile" in the general sense that they're nested underneath a specific
 user, they are not part of the Profile component in BP's technical sense
 of the term.

 If you need a function to test whether you're looking at a user, try
 `bp_is_user()` (which returns a bool) or `bp_displayed_user_id()` (which
 returns an int).

 > Maybe the problem is one of consistency--when you run
 bp_current_component on a profile subpage, it returns the name of the
 subpage, but when you run it on a groups subpage, e.g.
 /groups/testgroup/members, it returns the root component, i.e. "groups."

 Yes, you are correct that this is inconsistent. It dates from the very
 beginning of BuddyPress, and it'd be next to impossible to fix at this
 point without breaking every plugin :)

 Does this make sense?

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5827#comment:1>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list