[@boonebgorges Keymaster 8 years, 11 months ago]

BP’s functions may not be completely loaded by the time functions.php is loaded, so it may not be possible to run directly in functions.php. That being said, there is very little that you should be doing directly in functions.php, aside from calls to add_filter() or add_action(). Similarly, your friend actions should take place inside of a callback:

add_action( 'bp_ready', function() {
    // your custom code
} );

If you’re continuing to have problems, please share the exact code that you are using and maybe someone on this thread will be able to provide more direct advice.

[@boonebgorges Keymaster 8 years, 11 months ago]

Hi @angrywarrior – Really sorry to hear you are having troubles.

The “are you sure…” message indicates that a nonce check is failing. It makes sense that the nonce check is failing, since the nonce field is not being rendered on the second step of the wizard – from what you described, nothing is.

> next step is blank – you can only see the buttons “continue” or “go back”. As mentioned before, there is no options shown in this step. It’s just blank.

An important distinction here: Is the main content section of the page blank at this step, or is the content section *plus* the rest of the page blank? That is: is the footer generated properly? If not, it’s likely that you’re experiencing some kind of PHP fatal error. Check your error log, or enable WP_DEBUG, to see if something like this might be the case.

This could also be happening because of some inconsistency or change in your theme templates. What theme are you using? Is it possible for you to run a test with a default WP theme, like Twenty Sixteen, to see if the problem goes away? This would at least help to narrow things down.

[@boonebgorges Keymaster 8 years, 11 months ago]

CSS changes must go in a CSS file; putting them into a header.php file won’t do anything, unless you use some specific syntax.

It’s possible that the style.css sheet that you are referencing is not actually being loaded, due to an improperly built child theme. You can tell by viewing the source of the page and looking for a file being loaded in a <link> tag, with a URL along the lines of: example.com/wp-content/themes/my-theme/style.css. If you don’t see this anywhere, then you need to figure out why before you can debug anything else.

If the stylesheet is indeed loading, but the change is not taking effect, there may be a problem with the selector I’ve suggested. The best way to figure this out is by right-clicking the element, selecting “Inspect Element” (or similar, depending on browser) from the context menu, and then using your browser tools to experiment with different CSS selectors until you find the right level of specificity. Here is one tutorial on how to do this, and you can find thousands of others on Google (“how to use browser developer tools” or something like that). https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_are_browser_developer_tools

My CSS also assumes that the diagnosis of the theme author is correct. I can’t verify that without actually being able to see a live copy of the site. If in doubt, you may consider reaching out to the theme author, who may be able to confirm some of the advice on this thread.

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

> 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.

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

Thanks, @friendlygooners – I did read your previous post and visit your site, but what I’m saying is that I’m not sure what “mesage” or “notification” you are talking about. I currently see a partially-hidden item in the upper-right corner of the page, which ends in the sentence “Please reply if you are not a bot”. Is this the message that you are talking about?

If so, it appears that this element is created by your theme, Buddy. I don’t have access to the source of this theme, but I’m guessing that it uses some buggy logic to decide whether or not the notice should be shown. I’m unsure how to fix this bug in PHP because I can’t see the theme code. But you can hide this element with the following CSS:

.sidebar #message {
    display: none;
}

You may also want to add some styling so that the top menu doesn’t cover up your site’s content:

#content-wrapper {
    margin-top: 105px;
}

This may look different for logged-in users, so your mileage may vary.

[@boonebgorges Keymaster 8 years, 11 months ago]

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?

[@boonebgorges Keymaster 8 years, 11 months ago]

Hi @vincent46 – Can you please share a link to the guide that you followed?

You mentioned that you changed the language file, but that the changes were lost. Is your site in English?

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

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!

[@boonebgorges Keymaster 8 years, 11 months ago]

Here’s how you’d modify the code you’ve provided:

function mb_profile_menu_tabs(){
    global $bp;
    if ( bp_is_my_profile() ) {
        $bp->bp_nav['profile']['name'] = 'My Profile';
    }
}
add_action('bp_setup_nav', 'mb_profile_menu_tabs', 201);

[@boonebgorges Keymaster 8 years, 11 months ago]

Thanks for following up, @pandraka!

[@boonebgorges Keymaster 8 years, 11 months ago]

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/

[@boonebgorges Keymaster 8 years, 11 months ago]

Hi @friendlygooners – Can you clarify what you mean by “the sitewide notification still exist”? Do you mean that it’s still in the markup, even though you are hiding it with CSS? Or do you mean that there is an element other than #sitewide-notice that is showing to all users? Can you share the markup (or id attribute) from that additional element, so that we have a better sense of what needs to be hidden?

[@boonebgorges Keymaster 8 years, 11 months ago]

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

[@boonebgorges Keymaster 8 years, 11 months ago]

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).

[@boonebgorges Keymaster 8 years, 11 months ago]

At the simplest level, you can use the following:

remove_action( 'bp_init', 'bp_core_wpsignup_redirect' );

This will prevent BP from redirecting away from wp-signup.php.

There are still Register links at various places in the interface. You could try to find them all and replace them, or you could just write a server-level redirect from BP redirect URLs (by default, example.com/register) to wp-signup.php.

[@boonebgorges Keymaster 8 years, 11 months ago]

Ha, but knowing is half the battle! Good luck, @jeffm2008.

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

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!

[@boonebgorges Keymaster 8 years, 11 months ago]

Hi @jeffm2008 – Thanks for the post!

I’ve just had a look at how Jetpack handles this. Unfortunately, it looks like it’s probably fundamentally incompatible with the way that BP’s top-level pages work. While BP does use WP’s page infrastructure in the Dashboard, it then tricks WP into thinking that BP pages are *not* in fact WP pages at the time that the sidebar is rendered. So Jetpack’s checks – technically, is_page() and get_the_ID() – are failing in the case of BP pages.

As an alternative, you might consider this plugin, which advertises support for BP content: https://wordpress.org/plugins/dynamic-widgets/

[@boonebgorges Keymaster 8 years, 11 months ago]

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.

[@boonebgorges Keymaster 8 years, 11 months ago]

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!

[@boonebgorges Keymaster 8 years, 11 months ago]

@almostsultry – It depends on your setup. By default, on Multisite, WP user objects are not created at ‘bp_core_signup_user’. By default, on non-Multisite, users *are* created at the time of registration (ie ‘bp_core_signup_user’). This behavior may be modified by other plugins, especially those that interact with the login process (like SSO plugins). To test whether ‘bp_core_signup_user’ will work for you, take @shanebp’s code from above, and at the time of signup, examine whether $user_id is populated at this point. If not, it’ll be false. If so, it’ll be an integer, which you can safely use.

Do *not* depend on incremented values, because BP (on Multisite) generates users in the order in which they are *activated*, not registered.