Naming of Body Classes: 'my-profile' & 'my-account'

[landwire]

What is the difference between these 2 body classes? Do we need them both? Or should 'my-account' account be renamed to 'my-profile' and the old 'my-profile' class taken out or renamed to 'profile'? But there is another 'profile' class created from the xprofile component.

To me it does not make any sense to look at someone elses profile and see the 'my-profile' class displayed. It is very counterintuitive.

See: bp-core-template.php

if ( bp_is_my_profile() ) {
			$bp_classes[] = 'my-account';
		}

		if ( bp_is_user_profile() ) {
			$bp_classes[] = 'my-profile';
		}

Thanks,
Sascha

[johnjamesjacoby]

This looks like legacy code that could use a refresh IMO. Good spot.

[landwire]

Nice that I spotted something useful! Could be my first ever bug fix :-)

[boonebgorges]

The naming here is not very good. However, it's certainly understandable to have different class names for viewing one's own profile and viewing someone else's. I'm afraid we may not be able to change existing class names for backward compatibility reasons, but we could probably add something more descriptive for one of the cases if someone had a good suggestion.

[DJPaul]

I agree with Boone. I'm not really keen on changing these existing body classes because body classes seem to be used pretty regularly in themes. Adding one or two better-named classes would be OK, and we can document the legacy class names on the codex someplace.

[r-a-y]

The usage of 'my-' as a CSS class prefix is actually wrong for the majority of BP's body classes.

eg.

// this only checks if you're on a friends page within a user context,
// not if you're on your own friends page...
if ( bp_is_user_friends() ) {
	$bp_classes[] = 'my-friends';
}

We could fix this by adding a new class with 'user-' as the prefix, but that would just add an extra class.

Not sure if we want to do anything here...

Moving to the "Under Consideration" milestone.

[DJPaul]

I think adding extra better-named classes is not going to create any real overhead. We can then start to refer to them in documentation, and future template packs can target those. The old ones can just stay around forever.

[DJPaul]

This is of course dependant on someone proposing a new naming convention and everyone agreeing to it. :)

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/