Skip to:
Content

Opened 4 years ago

Last modified 3 years ago

#2590 new defect

bbp_body_class filter incorrectly marking BuddyPress user account screens

Reported by: hnla Owned by:
Milestone: 2.8 Priority: low
Severity: normal Version:
Component: Extend - BuddyPress Keywords:
Cc: hnla

Description

In the rendered wp body classes output we see the class .bbpress when we are looking at bp_is_user() screens ( buddypress user accounts) which causes issues if one is using that class for any layout management.

In templates.php bp_body_class() L:905 the function ends on a generic class .bbpress if $bbp_classes[] is not empty so at a guess one of the previous checks under the 'User' section perhaps needs modifying?


  elseif ( bbp_is_single_user() && 'forums' == bp_current_component() ) {
    $bbp_classes[] = 'bbp-user-page';

However not entirely sure the purpose of that 'User' section if I do above then I get the second block 'bbp_is_user_home()' push through 'bp-user-home' not previously visible.

Although I suspect not, if this 'User' section in the class filter is in respect of BP user account screens only I think the logic in determining what classes are shown might be flawed or at least need the above mentioned component check to prevent the classes appearing on all bp_is_user() screens.

Change History (4)

#1 @netweb
3 years ago

Duplicate: #2681

Via @SGr33n in #2681

I would report here a ticket that I also opened on the BuddyPress Trac some months ago:

https://buddypress.trac.wordpress.org/ticket/5474

If BuddyPress and bbPress are both enabled, some BuddyPress pages are positive to is_bbpress() conditional tag and the buddypress body has the bbpress class.

The pages are those starting with /users/... except the users list.

This is a bit annoying because if the user setup a css based on body.bbpress the css is also reflecting on BuddyPress pages.

#2 @hnla
3 years ago

So as the BP trac ticket suggests it wasn't/isn't a BP specific issue and matter re-directed here, that ticket however just re-states the issue.

I propose a re-factoring of the bbp classes as noted above, which looking back at isn't a viable solution if BP is not activated as the bp component check will fail.

The issue is that last class // Add bbPress class if we are within a bbPress page as that is erroneously adding that 'bbpress' class to non bbpress screens contrary to that comments statement, I get what jjj says though about how bbp needs to view things in respect of BP user accounts, it would require a few checks on the section I refereed to to ensure on a BP screen other than 'forums' no classes added and thus $bbp_classes returning as empty.

#3 @johnjamesjacoby
3 years ago

  • Component changed from General to BuddyPress
  • Milestone changed from Awaiting Review to 2.7
  • Priority changed from normal to low

A bit tricky to adjust this, so moving to 2.7.

#4 @johnjamesjacoby
3 years ago

  • Milestone changed from 2.7 to 2.8

Bumping all 2.7 to 2.8 milestone.

Note: See TracTickets for help on using tickets.