BuddyPress.org

“WP was finding it difficult to distinguish users on our current system with users of Buddypress”

correct cause bp adds additional profile fields…xprofile fields like name for example. rest gets stored in the wp_users database.

maybe u can try setting up different subdomains…bp on community.yoursite.com and forums on forums.yoursite.com

check the min requirements here

Getting Started

Basically, you’re trying to built a page menu. That’s WP territory

See here an example using wp_page_menu function which may help to going further:
https://buddypress.org/support/topic/notification-count-in-dynamic-menu/

Hi @jpry,

I noticed that you are using buddypress activity plus with apppresser. I am unable to get it to work together on mobile ( don’t see the photo upload icons) . I thought it was not compatible but wanted to check and see does it work for you out of the box.

Never modify original files.
Custom code for BP can be added to bp-custom.php

Hi @buddycore,

have you checked BP’s Attachment API ?

BP_Attachment

Hi,

BuddyPress doesn’t handle registration. That’s WordPress territory.

You may read about WP two step authentication:
https://codex.wordpress.org/Two_Step_Authentication

And here’s a tutorial from which you can built a multi step authentication:

Building a Multi-step Registration Form for WordPress

Good luck !

Deactivate all plugins and the theme and test registering from WP using a Twenty theme as first.
Then activate BP and re-test.
Then activate S2 or whatever you use for paid membership and again, test.
And finally, you have to test your theme (if not a Twenty one).

FYI, BuddyPress doesn’t handle the password field, but WordPress.
You’ll probably get better answers on WP or S2 support forum.

I’m wondering why you don’t use WP Menu to do that !

Dashboard > Apparance > Menu > add new menu and select from BP options.

If not visible, activate BuddyPress in screen options (top right corner).
Within the appearing BP options (left column) select the items you need for the new menu. Then activate that menu on your custom page.

This menu is always contextual and is showed to everyone, whatever his status.

Don’t hack core files. (never !) Which language do you use ?

Where have you done this ?
I’ve took a look at the files and found out that the working ones are using __( "Foo %s", "buddypress" ) and the wrong ones are using _x( "Foo %s", "Blah blah blah", "buddypress" ).

Actually all BP strings are working. If you need custom translation, you have to do that in po/mo and to use preferably the original strings. For example, if you build a template and want to use the notification count on it, you copy the original string to your work. If you don’t do that, you nedd 2 po/mo ! One for BP and one for your custom work. Which is certainly not the best and easiest solution.

The notification count is defined in wp-content/plugins/buddypress/bp-notifications/classes/class-bp-notification-component.php

The counter itself is inside a span and is defined separately.

/* translators: %s: Unread notification count for the current user */
_x( 'Notifications %s', 'Profile screen nav', 'buddypress' ),
sprintf(
	'<span class="%s">%s</span>',

The bla bla bla part you mention is a comment for translators who indicates him the context. This comment appears in the pot file like: Notification %s [Profile screen nav]

That’s BP’s default coding. You haven’t to modify this. Use it as is.

If you have difficulty to translate such a string, you have to check your theme or any custom function you added (by hand or another plugin).

The corresponding custom string should reflect the original one as gettext function wouldn’t translate a string which is not identic.

__( "Foo %s", "buddypress" ) and _x( "Foo %s", "Blah blah blah", "buddypress" ) are both working, and do technicaly the same thing (foo = something) which let you modify “foo” in both case, but as the original string is _x( "Foo %s", "Blah blah blah", "buddypress" ), you couldn’t replace it with __( "Foo %s", "buddypress" ). It is the translation prefix (_x or __) which is the important thing here.

Hope to be clear. And you’re right, unfortunately your changes will be overwriten at next BP update as you hacked core files.

Hi,
you can change any field title only if you’re the site admin.

See here: https://codex.buddypress.org/administrator-guide/extended-profiles/

Hi @nabilyazghi,

You could perhaps use something like this:

function blabla() {
     if ( ! bp_is_my_profile() ) 
	$nav_array = 'what_you_need';

     return $nav_array;
}
add_filter('bp_get_displayed_user_nav', 'blabla', 10, 1 );

Function ref: http://hookr.io/plugins/buddypress/2.4.3/functions/bp_get_displayed_user_nav/

Hi @densyo,

– first, you check that xprofile component is active: if( bp_is_active( 'xprofile' ) )
– then check you’re on a user page: bp_is_user()
– allow site admin: is_super_admin()
– check if the current page part of the profile belongs to logged-in user: bp_is_my_profile()

Example here:
https://buddypress.org/support/topic/the-right-way-to-remove-nav-items/

@earl_d, this “issue” is mentionned in plugin’s FAQ. Have you done the recommended changes ?