BuddyPress.org

/plugins/buddypress/bp-templates/bp-legacy/buddypress/members/members-loop.php

<div class="item">
<div class="item-title">
<a href="<?php bp_member_permalink(); ?>">
<?php bp_member_name(); ?></a>
<?php if ( bp_get_member_latest_update() ) : ?>
<span class="update"> <?php bp_member_latest_update(); ?></span>
<?php endif; ?>
</div>				

///////////// <YOUR CODE HERE> <LIKE_GET_THAT_FIELD> ///////////// 		
				
<?php
/**
* Fires inside the display of a directory member item.
*
* @since 1.1.0
*/
do_action( 'bp_directory_members_item' ); ?>

Check out the Languages and Translations article:

Languages and Translations

WordPress users are BuddyPress users. They’re stored in the wp_users table.

Hi @aubreyw – Thanks for the post!

I haven’t done a lot of work with these plugins myself, so I can’t give direct advice. But I was recently researching a bit, and I found that Restrict Contact Pro has a third-party add-on that does integrate nicely with BuddyPress: https://skillfulplugins.com/plugins/restrict-content-pro-buddypress/ I have not used this myself, but the screenshots make it look really promising, and worth a closer look.

> I replaced the indicated line of code in my child theme’s cover-image-header.php with yours. Not only does the Display Name not appear (only the “@” appears), but everything following it (tabs of user activity, etc) disappears. The page just ends.

Sorry, there was a typo in my original response. I wrote bp_displayed_user-id() instead of bp_displayed_user_id().

When the page stops rendering like this, it means that there’s been a PHP fatal error. If you’re going to be modifying PHP files, it’s a good idea to get familiar with either your server’s PHP error log, or the WP_DEBUG constant. See https://codex.wordpress.org/Debugging_in_WordPress

> Any insight into what I may be doing wrong would be appreciated.

Hard to know exactly what is going on without seeing your site. For the template, my guess is that you have copied things into the incorrect location in your child theme. The template overrides only work if the directory structure matches directly, as described on the codex page linked above. So, the path should be something like wp-content/themes/your-theme/buddypress/members/single/index.php.

For the CSS, it could be that your theme is using different CSS selectors for page titles. (.entry-title is used by some of the WordPress default themes, so I guessed that it might be in use on your theme too.) Use your browser’s inspector to get the proper selector. Here’s a useful tutorial: http://toolsqa.com/selenium-webdriver/finding-elements-using-browser-inspector/ Once you have found the id/class of the element, replace .entry-title in my snippet with that.

Hi @writingbox – Unfortunately, it’s very hard to debug this without access to the live site. But if the problem is indeed that there is a margin-top issue on this element, you could put the following into your child theme’s style.css:

body.single-item.groups #buddypress div#item-header div#item-actions {
    margin-top: 0;
}

Be sure to do this in the stylesheet for your child theme, not in BuddyPress itself or in your WP theme, because those changes would be lost when the plugin/theme is updated. Here’s a guide https://premium.wpmudev.org/blog/how-to-create-wordpress-child-theme/ – the section you want is under the “Creating a Child Theme” header, and the file where you should put your customizations is style.css.

If I understand the “view link” issue correctly, then the following CSS is probably enough to hide it:

.latest-update a { display: none; }

A screenshot would verify whether we’re thinking of the same thing.

Please note that if you’ve made changes in cover-image-header.php within the buddypress directory, these changes will be overwritten the next time BuddyPress is updated. Please create a child theme and override templates there. Here’s a brief guide: http://tentenbiz.com/override-buddypress-template-files/

> When I click on a user name from the member’s directory, it take me to the compose a message like it is suppose to do, and the user name appears , but it does not save the user name in the send to box, do you have a fix for this also?

Can you described this in more detail? When you say “it does not save the user name”, what do you mean? Do you mean that, when you press Send on the newly composed message, the page reloads without having been sent to the user in question?

There are a couple places where BuddyPress itself adds an IN clause like this to the user query.

1. When showing a list of a user’s friends: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/classes/class-bp-user-query.php?marks=389#L382

2. When joining against the user meta table because of some sort of meta_query: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/classes/class-bp-user-query.php?marks=455#L430

3. When parsing the include parameter, which can be populated by a plugin or by a group member query: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/classes/class-bp-user-query.php?marks=373#L360

It’s hard to give exact advice without knowing which of these cases is tripping up the WPEngine tool. Item 2 would only happen if you were using a specific kind of plugin/customization. 1 would only happen if viewing the friends page of a user with a huge number of friends. 3 would happen only if viewing the members page of a group with a huge number of members. 3 is probably the most common, but if you could verify, it would help us to narrow things down.

It’s hard to give a simple workaround for this kind of issue. One is to prevent BP from doing this specific ‘count’ query. This will have the effect of breaking certain kinds of pagination, but it may be something that you can work around, depending on the details. Fundamentally, this might count as a bug that should be fixed in BP – we may consider switching this to a subquery to avoid this kind of host restriction.

In the meantime, you might consider reaching out to WP Engine and explaining this problem. In my experience, they’re generally pretty reasonable about disabling or loosening this query-length restriction in certain cases.

I’m going to close this issue in favor of https://buddypress.org/support/topic/change-mentionname-to-displayname-in-cover-image-header-php/. Thanks!

Hi @drnz17 – Yes, there are plugins that make this possible. This one has support for BuddyPress-related conditionals, like “show these widgets on a single user page”: https://wordpress.org/plugins/dynamic-widgets/

Hi @richardmiller-1 – The purpose of the @username part of the interface is to tell other users how to mention the user when posting new activity items, etc. It’s possible to change the value that’s displayed here, but if you do, and if users then use that text to “mention” others, then things like auto-linking of @-mentions and @-mention notifications will break, since BP doesn’t know by default how to search by display names.

If you just want to change the display, then you should copy the cover-image-header.php template to your own child theme, and then change the line you’ve referenced to:

<h2 class=”user-nicename”>@<?php echo bp_core_get_user_displayname( bp_displayed_user_id() ); ?></h2>

It might be possible to retool some of the @-mention plumbing so that notifications etc work. You’d want to start by filtering bp_activity_mentioned_users(), and copying some of the logic in bp_activity_find_mentions() but with modified regex + user lookup. (This is going to be hard because, among other things, display names are not necessarily unique across a network, so @Richard could refer to multiple people. But that depends on the nature of your network.)

The h1 at the top of the profile page is generated in a weird way, as part of BP’s theme compatibility system. It’s not directly generated by BP, but comes from your WP theme; BP is faking the theme into thinking that the user’s display name is the title of the WP page, so that your theme’s page.php template outputs it as the_title(). There are various workarounds for this. One is to tap into BP’s template hierarchy, so that WP would use a separate template file for single member pages. See https://codex.buddypress.org/themes/theme-compatibility-1-7/template-hierarchy/#single-member-pages for details. Basically, you’d copy page.php to buddypress/members/single/index.php, and remove the call to the_title(). A simpler solution is to hide with CSS:

.bp-user .entry-title {
	display: none;
}

Hi @barkins – BP doesn’t have a built-in tool for this (though it should – see https://buddypress.trac.wordpress.org/ticket/7393, https://buddypress.trac.wordpress.org/ticket/408). If you know that user IDs will remain the same between the local WP install and the live install, then you can do a simple database export/import, something like:

$ mysqldump -u db_user -p db_name wp_bp_xprofile_groups wp_bp_xprofile_fields wp_bp_xprofile_data > ~/xprofile-export.sql

$ mysql -u db_user -p db_name < ~/xprofile-export.sql

If the user names will not be the same, you’ll need to write a script to handle this, but the details will depend on how you plan to identify users (email address, etc).

BuddyPress generally shows the admin bar to all users, whether logged in or not. If it’s not showing, it’s probably due to a plugin or theme issue.

I’ve just downloaded the Point theme and I don’t see anything in the theme that would cause the admin bar to be disabled.

Perhaps you’re running another plugin that disables it? If you’re able to search your codebase, look for the string show_admin_bar.

Hi @ankitjoshi11 – Check out the file buddypress/bp-friends/bp-friends-functions.php. The functions you’ll need are:

friends_add_friend( $initiator_userid, $friend_userid );

which accepts a third $force_accept parameter which makes it unnecessary for user B to manually accept. If you want to handle acceptance separately, look at

friends_accept_friendship( $friendship_id );

You can get the $friendship_id for two users with friends_get_friendship_id( $user_a, $user_b );

Good luck with your project!

You can prevent auto-links in the profile areas.

You need to create a file called bp-custom.php and then add this function to it:

function remove_xprofile_links() {
    remove_filter( 'bp_get_the_profile_field_value', 'xprofile_filter_link_profile_data', 9, 2 );
}
add_action( 'bp_init', 'remove_xprofile_links' );

These are the BuddyPress forums.
The bbPress forums are on another site.

Hi @wackao – Thanks for the post. I agree that the REST API could be a big driver for future adoption. (And I obviously agree that BuddyPress is a superior product to its competitors!) That being said, the BP team is a group of volunteers. The folks who build BP are professional and serious, but they work on projects that interest them, according to their availability. I personally would love to spend more time on the REST API, and hope to in the upcoming months, but if I can’t, it’s not an indication of lack of seriousness.

Anyway, the good news is that “the BP devs” is basically whoever decides to show up. If you have ideas for how the REST API could work – and better still, if you want to start contributing code via pull requests – you are very much encouraged to do so. More hands make for lighter work!