BuddyPress.org

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!

Yes, I can upload an avatar image without problems (but I can remember, that’s I’ve has had a problem with this and the cover-image was loaded without problems) and I don’t use anything like Amazon S3 or CDN. In <wp-uploaddir, which is set in WP-config>buddypress/members/<userid>/cover-image I can find 5a057ea758c30-bp-cover-image.png, which is the image that I want to be the cover.

Thanks for your reply!

Hi @barkins – Unfortunately, BuddyPress doesn’t yet have a full set of CRUD endpoints for BP objects. The team is working on it, and we hope to start rolling out endpoints in the near future. BP-REST is the repo to follow for that.

BP will work fine with the default WP REST API, if all you want to do is access a list of users. However, WP’s user endpoint won’t include any BP data, and you won’t be able to modify/add user data via this endpoint. That said, if your needs are fairly narrow, you can definitely write your own custom endpoint for fetching/updating BP profile data – it’s likely to be much simpler than what’d be required in BP itself, if your needs are pretty specific. Here’s some docs: https://developer.wordpress.org/rest-api/extending-the-rest-api/adding-custom-endpoints/

The easiest way to customize things like this is by creating a child theme and overriding the template – in this case, members/register.php. See https://codex.buddypress.org/themes/theme-compatibility-1-7/a-quick-look-at-1-7-theme-compatibility/#child-themes for some information on getting started with child themes.

Very odd – it appears that this too is caused by your theme, as BuddyPress itself just inherits the mobile styling of the toolbar from WordPress (and the WP toolbar looks fine, as shown by your Dashboard screenshot). Try reaching out to the theme author to see whether they’re able to identify the problem.

Create a template overload of this file: buddypress\bp-templates\bp-legacy\buddypress\members\members-loop.php

And place your code wherever you want in the overload.

bp_displayed_user_id() is incorrect in the context of the members loop.
Instead:

$user_meta = get_userdata(bp_get_member_user_id());
echo($user_meta->description);

Or instead of an overload, use this hook: do_action( 'bp_directory_members_item' );

You could edit a template.
If you are using profile cover images, edit buddypress\members\single\cover-image-header.php
Otherwise, edit buddypress\members\single\member-header.php

But you can use a function instead.
Both the templates mentioned above have two action hooks:

do_action( 'bp_member_header_actions' );
do_action( 'bp_profile_header_meta' );

Choose the one that will place your button where you want it and write a function that adds the button.

Thankfully, yes I have resolved it …at least for my situation. It appears that this began, when BuddyPress updated to most recent, v2.9.2. I asked SeventhQueen for help and they advised to check for any template overrides in my child theme folder. So, yes I do have a modified “register.php” BuddyPress file. I downloaded a backup of the file and also renamed the current one as “_old”. Then I carefully copied out my modifications. Then I imported the whole updated “register.php” and re-did the custom modifications. Hope this helps.

Add this to your wp-config.php file before the line that says /* That’s all, stop editing! Happy blogging. */ or your bp-config.php file.

define( 'BP_ENABLE_ROOT_PROFILES', true );

That comes from this page: https://codex.buddypress.org/getting-started/customizing/changing-internal-configuration-settings/

Sometimes the person who knows the answer simply doesn’t see the post 😉

We’ve used BuddyPress internally at my company and for client’s over the years and it has worked fine.
If you want a Good UI/UX, get a premium buddypress theme. Check the folk at BuddyBoss.

P.S Made WordPress Email Opt-in and User Registration & Profile plugins.

We’ve used BuddyPress internally at my company and for client’s over the years and it has worked fine.

If you want a Good UI/UX, get a premium buddypress theme. Check the folk at BuddyBoss.

P.S Made WordPress Email Opt-in and User Registration & Profile plugins.

@louisarthur – Thanks for sending me credentials. I’ve logged into your site to have a look.

As you note in your email, there’s no href attribute on these links. It’s not clear to me how this would be the case, but I can give you a starting point for looking into it yourself. Briefly, the buttons will be built without an href if the button constructing function passes an empty link_href parameter to the BP_Button class. The functions used in the two cases are different:

Message public: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-activity/bp-activity-template.php?marks=3090#L3079

Message privé: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-messages/bp-messages-template.php?marks=1362#L1360

The logic in each case is different, but since neither is showing up, I’m guessing that one of two things is happening:

1. One of the conditional checks shared between them is failing for some reason: bp_is_my_profile(), is_user_logged_in().

2. Something on your installation – perhaps your theme but probably a plugin (since you said Twenty Seventeen was exhibiting the problem as well) – is filtering both ‘bp_get_send_private_message_link’ and ‘bp_get_send_public_message_link’, and then incorrect returning empty strings.

To test idea #2, you might try – if you can – searching through your codebase for those filter names.