BuddyPress.org

Hi @Sander – Thanks for reporting this. It looks like a legitimate bug. I’ve opened a ticket to track it: https://buddypress.trac.wordpress.org/ticket/7631

While we try to figure out a way to make this work better, you can work around the issue by disabling autolink for the field in question. Dashboard > Users > Profile Fields > Edit, and look for the Autolink metabox at the right.

Thanks for the report, @onedevstudios. This sounds like it’s probably a bug. Could you please open a ticket at https://buddypress.trac.wordpress.org with detailed instructions to reproduce? Thanks!

I’m unable to test with the proprietary Magnum theme, but with the free version of Optimizer, I’m unable to reproduce the problem. Group member searches are working as expected: https://postimg.org/image/axag5nsjr/

Here’s the relevant part of BP’s JavaScript: https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-templates/bp-legacy/js/buddypress.js?marks=863#L848 The first thing to check is that your theme is actually requiring buddypress.js (or buddypress.min.js) out of the buddypress theme directory; if not, it’s possible you’re running an out-of-date version bundled with a theme or something. Then, you may need to deminimize (or set define( 'SCRIPT_DEBUG', true );) to debug. Then, check to see whether this bit of script is actually able to find the search_terms element. It’s possible that your theme, or some other plugin, is modifying the markup so that the selectors or the element hierarchy has changed.

Hi there to all!

For those who searching for the messaging plugin, checkout this:

BP Better Messages

I don’t have access to the proprietary ARMember plugin, so I can’t say anything about that.

Here’s one way to show arbitrary content in a BP user’s profile header:

add_action( 'bp_before_member_header_meta', function() {
	$user_id = bp_displayed_user_id();
	echo 'Here is the badge for user ' . $user_id;
} );

You’ll need to use the $user_id to fetch the ARMember badge and display it.

See https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src/bp-templates/bp-legacy/buddypress/members/single/member-header.php for other hooks you could use instead of bp_before_member_header_meta.

It looks, at a glance, like the LH Private BuddyPress plugin ought to be doing what you’re asking for. https://plugins.trac.wordpress.org/browser/lh-private-buddypress/trunk/lh-private-buddypress.php#L101

If it’s not working, it’s either because of an error in the plugin logic, or because something on your server or WP setup is interfering with the redirect_to parameter.

Can you share the format of the URL at various points of the process? For example, when visiting example.com/groups/my-private-group as a logged-out user, you should be redirected to:

example.com/wp-login.php?redirect_to=/groups/my-private-group

If, after login, you’re being redirected back to wp-login.php, what is the format of the URL then?

What is the URL format of your BP/WP installation? Are you installed at the top level of a domain example.com or in a subdirectory example.com/buddypress/?

What theme are you using? It’s possible that this problem is specific to the theme. Try on a default WordPress theme like Twenty Sixteen to be sure.

Can you share a screenshot of the “comment box” and the “reply box”? It’s unclear from your questions whether you’re talking about textareas or about buttons. Also, BP doesn’t have separate Comment and Reply functionality for activity items, which makes me think that this may be a conflict with another plugin.

I’m not sure that previous_posts_link() and next_posts_link() will work in the context of a custom WP_Query loop. See https://wordpress.stackexchange.com/questions/20424/wp-query-and-next-posts-link for a pointer.

Don’t abandon the Groups functionality or BuddyPress over this small display issue! With a plugin like this https://wordpress.org/plugins/simple-custom-css/, it is trivial to add the CSS that I gave above.

Building a child theme is more complex, and is something you should learn down the road if you plan to make extensive customizations. But if you just need to make a small change like what I’ve suggested, then a plugin like https://wordpress.org/plugins/simple-custom-css/ is more than enough.

I believe those warnings are related to fetching the plural form of a number.

Do you have debug turned on in wp-config.php ?
If the only issue is the Warnings, turning off debug should make them disappear.

If they still appear or there are related issues, you should open a ticket at LearnDash.

But first, to see if the issue is related to your theme, try switching momentarily to a WP theme like 2016 and see if the warnings persist.

Ah yes, thanks for that.

It looks like your theme is loading scripts from BuddyPress, but is using an old path for these scripts. (BP changed the paths a couple versions ago. See https://buddypress.trac.wordpress.org/changeset/11009.) Look in your theme – probably in functions.php – to see how it’s loading the cookie, caret, and atwho scripts. Then update the paths as needed (I think you can just add /vendor/).

Check out this tutorial: https://rudrastyh.com/wordpress/get-user-id.html#user_id_column

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

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

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/