BuddyPress.org

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/

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.