BuddyPress.org

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;
}

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.

Thanks for the quick response.

Looking over some of the earlier posts, it is weird that the message says “For better results, make sure to upload an image that is larger than 0px wide, and 225px tall.”. This suggests that theme is set up in such a way that it sets the cover image width to 0. As such, it’s possible that it’s being rendered, but being set to 0 width. Are you able to reproduce the problem on a WP default theme, like Twenty Sixteen?

The width for the cover image is inherited from the content_width global, which should be set by your theme (at least, the wordpress.org theme guidelines require it). It’s possible it’s not being set. Have a look at https://www.binarymoon.co.uk/2012/03/heard-wordpress-contentwidth/, and try doing something like that in your functions.php to see if it helps.

If this turns out to be the issue, then the BP team should look into having a more graceful fallback for cover image width, so that we’re a bit more compatible with non-compliant themes.

Exact location of this depends on your theme, of course, so this is based on themes that are using BP Legacy.

When a group admin views the single forum post, at the top of the post you should see the date on the left and then options at the right: CLOSE | STICK | MERGE | BIN | SPAM | REPLY – just click on STICK.

This will stick it to the top of the group’s forum.

Hope that helps

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' );

Amazing looking theme! Any chance you’re looking to make it available to others? 🙂

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.

The code you’ve given does a check against the logged-in and displayed user. Remove the if and endif lines, and it should show for all members.

For more information on how to modify your theme to show a left sidebar, you’ll want to reach out to the theme author.

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' );

Your theme is causing those issues. They also exist on the login page.
To confirm, try switching momentarily to a WP theme like 2016 and see if the issues persist.

You will need to contact the theme creator to get answers re your formatting issues.
Or you will need to learn how to use css.

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.

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.

Hi @hlubi – Generally, the sidebar is controlled by the WP theme you’re using. See sidebar.php. You’ll likely need to make your modifications in that file (probably in a child theme, if you’re not already using one).

Exactly what modifications you make depends heavily on how you want the sidebars to differ. If you have a small number of groups, and you want the sidebar to be totally customized for each one, sidebar.php might look something like this:

if ( bp_is_group() ) {
    $group_id = bp_get_current_group_id();

    switch ( $group_id ) {
        case 1 :
             // group 1 sidebar
        break;

        case 2 :
             // group 2 sidebar
        break;
    }
} else {
    // existing sidebar code
}

You could even register separate sidebars for each group, so that they can be managed separately in wp-admin. (This solution obviously won’t work well if you have lots and lots of groups.)

If you just want to have some group-specific content in the sidebar, you can use BP’s “current group” functions in sidebar.php. For example:

if ( bp_is_group() ) {
    $current_group = groups_get_current_group();
    printf( 'This is the sidebar for group %s', esc_html( $current_group->name ) );
}

This way, you’d have the same *type* of data on each group’s sidebar, but the specific data would be pulled dynamically based on which group is being shown.

@852cmd Hm, that string – ‘Error! Please upload Profile Picture’ – doesn’t come from BuddyPress. This should be your clue: whatever code is generating that string is probably also doing the blocking itself. Try searching your codebase – including your theme – for this error message.

Hi @chhayaparikh1963 – Thanks for the post!

I agree that the ability to post from the front end would be a good improvement for BuddyPress. It’s a bit complex to think about how it might be developed for BP itself, since it’s likely that many BP sites will want the feature implemented in different ways: limiting permissions to specific kinds of users, linking groups to sites within a multisite network, specific taxonomies for posts created from particular front-end contexts, etc. That being said, it’s something that’s long been on the radar of the BP development team. A recent ticket that outlines the issue is https://buddypress.trac.wordpress.org/ticket/6736

In the meantime, I know you said you have checked out all the third-party plugins, but I will say informally that I’ve had pretty good luck with BuddyForms. https://themekraft.com/buddyforms/