BuddyPress.org

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 ?

You did not say what version you update from, but when the emails were improved in v2.5, there was a bug with exactly this that hit some people – but not everyone – which we fixed in a minor release.

First, go to wp-admin Tools > BuddyPress, and run the re-install email tool. This will delete the terms and the posts, and recreate them.

There’s no need to ask your question twice: https://buddypress.org/support/topic/adding-custom-emails/

@maryt66 You’re welcome. You can subscribe to the latest BP development news at https://bpdevel.wordpress.com/ or check out https://buddypress.org/blog/

Cheers.
Mercime

Hi @marco129

BuddyPress emails are stored as custom post types. In wp-admin, Tools > BuddyPress, there is a tool that reinstalls BuddyPress emails. You normally want to do this if you’ve translated the email text *after* BuddyPress has been installed (it adds the text in as English).

If you’ve translated the BuddyPress email text, and assuming Loco Translate works properly (I don’t know anything about it), then a re-install of the emails should fix it.

Hello,

I have the same problem here. I use WP 4.5.3 and the Theme Woffice from ThemeForest and BuddyPress 2.6.2. I translate all with the plugin Loco Translate but some translations are not working. There ist nothing to repair. What can I do? Any idea?

Best regards

Marco

Just to note that the “add friend and cancel friendship” tooltips, among other tooltips have been removed in BP 2.7 trunk (see #7090).

The BuddyPress Plugin doesn’t apply any style when you hover over a suggested @mention. When using a default WP theme (which is what the BP developers base their testing on) there is no hover effect on the suggested username. Which indicates that it is probably something in the style of the theme you are using that is applying this additional effect.

The quickest way to see if it’s the theme or not, is to quickly change themes to one of the Twenty-xx themes that are packaged with WordPress, and if the hover effect disappears, you know where the problem is.

That’s only part one. The next part is to figure out where in the theme the issue is and patch it.

This might be helpful: https://www.studiopress.com/using-firebug/

I haven’t tried this plugin in a few years, and it hasn’t been updated for a while, but it once did exactly what you are talking about.

https://wordpress.org/plugins/buddypress-activity-stream-bump-to-top/

The BuddyPress login widget is just a styled version of the WordPress login page. Hackers are still hitting the same database regardless of if they are finding your login widget — or more likely — blinding hitting your /wp-login.php page. wp-login isn’t being replaced here. If you are worried about brute force attacks, you should look into mechanisms created to protect WordPress (captchas, limit login attempts, etc.)

Replacing the WP login infrastructure with something else is a whole other matter, and something you would need to do on the WP side. As @djpaul mentioned, BP leaves that side of the site to the existing BP user management system.