Opened 8 years ago
Closed 8 years ago
#7301 closed enhancement (fixed)
Add Member & Group ' types' string to body class array for bp_user/groups single screens
Reported by: | hnla | Owned by: | hnla |
---|---|---|---|
Milestone: | 2.8 | Priority: | low |
Severity: | minor | Version: | |
Component: | Core | Keywords: | |
Cc: |
Description
With the addition of members & groups 'types' it would be helpful to identify the group and members type on their single screens i.e Groups single/bp_user adding a body class token - we already add classes in the directory loops so this will balance that out for styling requirements or script hooks in the single screens.
I'll run up a patch in due course for this.
Attachments (2)
Change History (5)
#1
@
8 years ago
Makes so much sense +1. Mind that we already support multiple types in bp_get_member_class()
, so I'd do:
// Add current user member types. if ( $member_types = bp_get_member_type( bp_displayed_user_id(), false ) ) { foreach ( $member_types as $member_type ) { $bp_classes[] = sprintf( 'member-type-%s', esc_attr( $member_type ) ); } }
Although the group types aren't yet part of bp_get_group_class()
(another opportunity there!), you can mimic this for group types, like so:
// Add current group types. if ( $group_types = bp_groups_get_group_type( bp_get_current_group_id(), false ) ) { foreach ( $group_types as $group_type ) { $bp_classes[] = sprintf( 'group-type-%s', esc_attr( $group_type ) ); } }
#2
@
8 years ago
Odd had thought members didn't have multiple types - knew I would have to loop for the group types, and yes had avoided groups due to that inconsistency which I think is better addressed first really. Thanks for the comments. I had actually avoided adding any further to the string to partly avoid translation requirement thought it was easier all round to leave just as the type slug as devs would know what it was.
Add user 'type' token to body class on bp_user screens.