BuddyPress.org

I have no idea where or what BuddyPress might be doing to cause that. More likely, it’s causing some issue with custom code. I think you might have to debug it, if you know PHP.

Sorry, no, it’s not a perfect solution, just a workaround. Best practice would be to use what is explained here.

As said previously you cannot change the Name field, and to exclude or modify his description you can’t even (so far i know) modify the default view level (All) for that field.

So you have to use another CSS trick and perhaps add an “only me” message to the Name field description.

#field-visibility-settings-toggle-1 {
display:none!important;
}

Hi @ma3ry,

it’s impossible !

But there is an all or nothing trick. You can apply a CSS rule.
Try to add this to your child-theme style.css

tr.field_1 {
 display: none!important;
}

Do you mind telling what version of Buddypress you are running since I am experiencing the same issue.

Thanks for the post, and thank you everyone that chimed in to alert the OP about the protocol for security concerns. Understanding it’s possible there’s a communication gap here, this topic does also read (to my eyes) as condescending & inflammatory, which is honestly not going to yield a very positive conversation. I think y’all did a great job staying positive, and I for one greatly appreciate that.

To be clear to anyone else that runs into this topic, what the OP sees is not a BuddyPress or bbPress bug; this is WordPress doing it’s best to show published content from public post types.

About BuddyPress:
* Neither BuddyPress nor bbPress modify this core behavior
* BuddyPress does not use this interface; bbPress does
* The .org sites have not disabled this, they just do not have any unusual content to leak

The gist:
* If plugins allow for private content, it’s up to those plugins to protect it
* If you create roles with content limitations, it’s up to you to confirm they’re working

For anyone looking to modify or restrict content that appears in this list, use the wp_link_query_args and wp_link_query filters to do so.

Here is how WordPress calculates the results in this list. Note that it only uses published posts from public post-types:

$pts = get_post_types( array( 'public' => true ), 'objects' );
$pt_names = array_keys( $pts );

$query = array(
	'post_type' => $pt_names,
	'suppress_filters' => true,
	'update_post_term_cache' => false,
	'update_post_meta_cache' => false,
	'post_status' => 'publish',
	'posts_per_page' => 20,
);

WordPress has a built-in way to calculate privacy scope using 'perm' => 'readable' and even that is not used here (though bbPress does use this in its own loops.) WordPress instead takes a strict position of published public content by default.

If anything unexpected is appearing here, it is not because of BuddyPress or bbPress, and we are still happy to help anyone discover the source of this in a new & more friendly topic.

@sbrajesh (BuddyDev) published a pretty cool tip about page titles:

Using WordPress Page Titles for BuddyPress Directory Page heading & Titles

Is there a formal process for requesting this feature?

Yes. The formal place to request features is Trac.

Hi @handyandywilson

Your first stop when customising the activity stream should be bp_parse_args(). Check out this article:

Using bp_parse_args() to filter BuddyPress template loops

@earl_d

As the registration process can be different according to WordPress configs, can you please provide some details about yours :
– Multisite ? If so is BuddyPress network activated or activated on a specific blog of the network
– Plugins ? Especially the ones that might play into the registration process.

FYI, i’ve just rechecked on 2 freshes WordPress configs (regular & multisite) having only the BuddyPress plugin activated. Registration is working great.

@nnyorker you’re probably activated a standalone BuddyPress theme that has no support for the cover image feature.

I advise you to have a look at this post:
BuddyPress 2.4.0 will introduce Cover Images for members & groups!

Thank you for getting in contact with the BuddyPress team. Some of the attitudes displayed in this discussion have not been respectful and are not conducive to a productive conversation, so I am going to close this topic for that reason only. If anyone has questions about this moderation action and is prepared to discuss them civily, you can find my contact details on https://profiles.wordpress.org/djpaul/.

All projects, including bbPress, BuddyPress, and WordPress, appreciate responsible reporting of suspected vulnerabilities. Read this page on the WordPress site for reporting guidelines for all the aforementioned projects: https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/

@djsteveb On the whole, the BuddyPress team enjoys a good working relationship with rtMedia, and we have often discussed issues when it’s vague when the root cause lies. I appreciate that it’s frustrating to be passed from pillar-to-post when you’re trying to get support or report a problem. If you still have the information, I’d encourage you to get in contact with the rtMedia team to start the conversation.

Hi @paulrooms

The Italian translation of BuddyPress is up to date: https://translate.wordpress.org/locale/it/default/wp-plugins/buddypress

For the menu items (at least what I think you mean), you’ll need to go into wp-admin > Pages > Edit, and just rename/translate the pages yourself.

I am pretty sure this this not easily changeable and is hardcoded to use the login or nicename (depending on the value of the BP_ENABLE_USERNAME_COMPATIBILITY_MODE constant; https://codex.buddypress.org/developer/filters-reference/).

Problem with display name is that because people can change that (unless you customise a site to prevent people doing that, but that’s not something we want to force on in BuddyPress), you can have situations where people swap display names (accidentally or maliciously) and then start receiving at-mentions intended for other people, etc.

@navyspitfire BuddyPress does not use wp_mail(), so any calls to that function are ignored and not treated with BuddyPress’ email templating.

If your BuddyPress emails were being sent plain text, then that means you have a plugin that re-declares the wp_mail() function — probably your SMTP plugin, I’d guess. There are other SMTP plugins that don’t redeclare the function, and so compatible with BuddyPress.

We fallback to plain text in these cases to maximise compatibility with all the many ways of customising emails that WordPress permits.

The equivalent function is bp_send_email(), and for the type of email you mention, here’s an example usage: https://github.com/buddypress/BuddyPress/blob/master/src/bp-core/bp-core-filters.php#L533

This is not a BuddyPress problem. It’ll be a issue with the PHP you’ve added. You’re probably missing a semi-colon from the previous line, or something.

@mingjie0409
there has been some discussion of this here: https://buddypress.org/support/topic/bussdypress-title-and-seo-yoast-problem/#post-253510

and here:

https://premium.wpmudev.org/forums/topic/bp-meta-tite-description-for-groups-and-members-pages

and several other places including the suggestions / feedback area amongst others.

I’ve had it fixed a time or two but updates to either bp or themes have broken my fixes.
This is something that google’s webmaster tools screams at you as being bad, and hurts your site the more members you get.

so I added a noindex no follow to the robots.txt file to remove most of the bp pages from being indexed.

Is this a fresh install? If yes check the min requirements in buddypress codex

Find out which S2 function returns member ids based on S2 levels.

Then look at this function bp_has_members. It has include and exclude arguments.

If you have more paying members than non-paying members, then pass the non-paying member ids to the exclude argument.
Otherwise, pass the paying member ids to the include argument.

You can adjust the bp_has_members call in your Members Directory template.

Or you can write a function using this approach:
https://codex.buddypress.org/developer/using-bp_parse_args-to-filter-buddypress-template-loops/

managing users, groups, comments, handling any abusive users etc.

buddypress has a wonderful admin backend and the above can be handled properly…and there are a bunch of plugins which you can use for backend admin

using buddypress+bbpress for 2 multisite websites and works great

would suggest you do a test drive and see what you get form buddypress

@abooster – I found a similar issue in regards to uploaded pictures and videos some time ago. It really disturbed me that it was trivial to see other people’s uploaded media within buddypress / wp -multisite.

I found at the time role scoper had a method to limit the permissions there and fix this issue on one install for me – it has since transformed into ‘press permit core’

I never bothere3d to report this, as it seemed like I’d report it to bp and it would get the whole ‘it’s not bp, it’s wp – or it’s rtmedia’s plugin problem’ – then I’d probably report it to rtmedia – and it would get a whole – thats the way bp and wp works – and although we were multi site compatible, we are not responsible for how permissions within those setups work..

and so, it’s really a problem for the bp community, but more so for those users who sign up assuming that we have good security practices like big social networks. I am guessing issues like these run afoul of the eu data privacy and protection laws, but I’m not there and don’t know enough about them.

So I just put in my terms that this is all beta software and not to post anything you don’t want exposed – there is not way any of this stuff is secure and everything could inadvertently be exposed one day even without a hack attempt.

sucks but that’s about all i can do as a user, not an expert of php or anything wp / bp / etc.

thanks for mentioning another similar issue that I had never considered – I think I had seen something like this when logged in as super admin, had not considered it may also show for non-super-admins – this sucks.