BuddyPress.org

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.

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

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/

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.

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/

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.

The hook you mention does not provide any arguments.
Perhaps you need to research how do_action works.
The hook I mentioned already provides the $user_id.

Example:

function sultry( $user_id, $user_login, $user_password, $user_email, $usermeta ) {
   // do something with $user_id
}
add_action( 'bp_core_signup_user', 'sultry', 10, 5 );

I try to answer even if I am not an expert.
It could be some user management plug-ins that conflict. It happened to me in the past that the profile image was not linked to the wordpress avatar. I found out that it was a user management plugin that sent him into conflict (the name of the plugin was Ultimate member). I hope I have helped you.

Hi friend, this is my website http://www.99wordpressdevelopers.com and help me for adding more than one social media buttons in footer. If you have any ideas then suggest me?
Also i want to know how to install WordPress blog through Cpanel.

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.

Thanks ositive for the code. Gonna try it out now.

WordPress Email Opt-in Plugin

have a look at https://wordpress.org/plugins/network-subsite-user-registration/

@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 @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/

I wholly agree with the sentiments of the guy who posted this.

I think bbPress and BuddyPress are, frankly, appalling offerings to ordinary WordPress users.

They may well be excellent tools for developers, but they are the most user-unfriendly bits of software I have encountered in WordPress. Indeed, they make me wonder whether WordPress is for users anymore, rather than professional developers.

It simply should not be this complex, and dismally supported, to have a forum on WordPress.

I agree wholly with the view that there should be a premium paid-for service with a solution aimed at WordPress users – that is people who create editorial and run a site. Not the professional developers, who can look after themselves.

It does not surprise me that outfits like Wix are growing given this direction of WordPress. If it is for developers only – who hone their marketable skills doing this stuff – then fine.

For an ordinary user, who is not totally useless on WordPress, I have found this BBPress / BuddyPress combination utterly toxic and a waste of time.

WordPress has a built-in function for getting the number posts published by a user:
https://codex.wordpress.org/Function_Reference/count_user_posts

If you’ve been able to figure out how to display profile data, use the same approach here, and you should be in good shape.

This is probably a server configuration problem. This simple plugin can help you figure out if your WP installation can send emails:

Check Email

Alternatively, the emails may be being sent, but ending up in your users’ spam folders.

Ajax calls need access to wp-admin.
You’ve blocked it so the ajax calls will not work.
And you see that in the areas you’ve mentioned.

You’ll need to add this conditional to your whitelist check:
wp_doing_ajax

Something like: if ( ! is_admin() && wp_doing_ajax ()) {

Hi @VentureCore-

It seems like you can make avatars work remotely. Check bp_core_fetch_avatar() for some filter opportunities. https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/bp-core-avatars.php#L98

I’ve not done what you’re trying to do, but it seems that the filter points bp_core_avatar_folder_url, bp_core_avatar_folder_dir could be useful, but there’s a filter on the final result at bp_core_fetch_avatar for the “html” output version and bp_core_fetch_avatar_url for just the url.

Cover images should actually be easier to manage. Take a look in https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-core/bp-core-attachments.php#L28

Alternatively, you could filter the other plugin to ignore avatar and cover image requests. Lots of ways to solve this, I’d bet.

What about using a custom member front page? Then you’d have total flexibility:
Custom Front Pages for your users profiles

Otherwise, I think you could conditionally filter bp_displayed_user_get_front_template to specify members/single/activity.php for self and friends and members/single/profile.php for non-friends. See this function:
https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-members/bp-members-template.php#L1397