BuddyPress.org

Turns out there was an issue I didn’t catch until I noticed @mentions were showing up for more than just the specified user. Below is the updated code (really, it’s just a matter of swapping out $user_id for $filter_array[‘user_id’] in the edited code mentioned above). This is working on BuddyPress 1.7.1.

I opened up buddypress/bp-activity/bp-activity-classes.php, found lines 620-624 (part of the get_filter_sql function), and changed it from:

if ( !empty( $filter_array['user_id'] ) ) {
	$user_sql = BP_Activity_Activity::get_in_operator_sql( 'a.user_id', $filter_array['user_id'] );
	if ( !empty( $user_sql ) )
		$filter_sql[] = $user_sql;
}

To:

if ( !empty( $filter_array['user_id'] ) ) {
	$user_sql = BP_Activity_Activity::get_in_operator_sql( 'a.user_id', $filter_array['user_id'] );
	// START Also include @Mentions in User Stream
	$search_terms = '@'.bp_core_get_username($filter_array['user_id']);
	$user_sql.= "OR ( a.content LIKE '%%".like_escape($search_terms)."%%' )";
	// END Also include @Mentions in User Stream
	if ( !empty( $user_sql ) )
		$filter_sql[] = $user_sql;
}

@felixrami

• my best suggestion is to try and reinstall WordPress and BuddyPress & bbPress manually via ftp.
• If that doesn’t work, you’re best bet is to reinstall the most recent versions of those (before the upgrade of course) and then upload your most recent .sql backup via phpmyadmin to restore your site pre-upgrade.
• Once your site is back online, you can check your server logs for errors and report them here for assistance in finding the core issue and a best practice solution to implement to overcome it.
• Then definitely move everything to a localhost so that you can try to replicate the issue

Also, when you try to replicate the issue on your localhost, try to upgrade without any other plugins activated to see if there is a conflict with any of your plugins and the update. You can also search for “buddypress + {your plugin name here}” for each of your plugins that haven’t issued an update since buddypress 1.7, as they could possibly be the culprit.

I hope this helps and good luck with restoring your site. It can be stressful, but you’ll get it bud.

as even removing the /buddypress/ folder doesn´t run, I belive “in any place” of database there are some wrong code. Is it true?

Thanks,
felix

Hi, I get a WPMU 3.5.1 and tried to upgrade to BuddyPress to last version. Now I get a white screen of death in my home http://www.dealermarket.net but the other sites run fine, by instance http://www.dealermarket.net/actualidad

I cannot access to my Super admin network area:
http://dealermarket.net/wp-login.php
http://dealermarket.net/wp-admin/network.php … Error HTTP 500

or even throught Network Admin dashboard. So what should I to do?, before touch anything. I see in any site dashboard, at Plugin section, two Buddypress versions 1.6.1 and 1.7.1. Also I have removed the ../plugin/buddypress/ folder but the problem persist. Just one thing more, I upgraded bbpress before BP, at v.2.3.2

Note: I would need while fix it a solution to refresh/redirect from home site to another site to stay alive.

Thanks a lot.,
Felix

(once I heard about every theme compatibility, which is awesome).

However by the look of things you aren’t actually running under the new Theme Compatibility layer.
Your layout under BP pages and lack of theme compat stylesheet suggests you’ve activated the older bp-default theme? If so you don’t want to be if using a custom third party theme or have you run the BP template pack plugin to make this theme work with BP?

If you have any BP folders in your theme root try removing them and letting BP theme compatibility take over.

I Just wanted to post this solution, as I spent a lot of time trying to find what was not working, because the /register/ page wasn’t loading after installing buddypress. In fact the problem was solved after enabling the mod_rewrite in Apache but in devian linux you have to follow this procedure to enable it also modifying the files suggested by this url:
http://www.esscotti.com/resources/articles/41-general/103-how-to-enable-modrewrite-in-apache-2-on-debian-linux

Hope this helps more!

@krisdarty
Didn’t you read the requirements? It states clearly it is compatible up to: WP 3.3.1, BuddyPress 1.5.3.1. So until @djpaul has plans or time to update the plugin then I suppose you should not use it if its not working for you. Otherwise if you have time deadlines and you know how to code then the source is there for you to tweak. Otherwise you may need to hire a developer if you can’t figure it out on your own. I am in big favor of using some code that disallows installing plugins on setups until the specific WP and BP versions fit what it has been tested to work with so it just will not install unless it meets all requirements. If anyone knows a way to handle this then I would like to be educated myself so I can employ it in plugins. I haven’t seen anything in the codex so any advice is good.

@mshane8
This small plugin makes all buddypress related pages private and redirects logged out visitors to the register page. Read the readme.txt and study the comments in the plugins private-community-for-bp.php if the default functionality does not meet your requirement then you can edit it to do so. Get it here:
https://github.com/bphelp/private_community_for_bp

Hi, BP group documents plugin now compatible with BP1.7 in beta version can be found on http://lenasterg.wordpress.com/2013/04/30/buddypress-group-documents-for-bp-1-7-and-wp-3-5-1/

So you know how to code a plugin that creates and handles cpts ?

Then something like this in the plugin class:

add_action( 'bp_setup_nav', array( $this, 'bp_stories_tab' ), 5 );

// create the tab
function bp_stories_tab() {
		
	bp_core_new_nav_item( array(
		'name' => __( 'Stories', 'bp-member-stories' ),
		'slug' => 'stories',
		'position' => 200,
		'screen_function' => array( $this, 'bp_stories_screen' ),
		'default_subnav_slug' => 'stories'
	) );
}	

// load template when  tab is clicked
function bp_stories_screen() {
	add_action( 'bp_template_content', array( $this, 'bp_stories_profile_screen' ) );
	bp_core_load_template( apply_filters( 'bp_core_template_plugin', 'members/single/plugins' ) );
}

// show the stories screen
function bp_stories_profile_screen() { 
	// etc. 
} 

BP can’t do that out of the box.

You can extend it using custom post types.
No need to send them to wp-admin, they could create stories via a page within their profile.
Read and sort can be handled via the usual WP post functions, within or outside profiles.

See my response here:
https://buddypress.org/support/topic/terms-of-agreement-checkbox-for-registration/
You will need to write a page of your Terms Of Service and you can add a link in the profile field description that would link to that page. After you create the page just copy the permalink under the Title and then paste it into the field description. For example:

<a href="http://your-site/terms-of-service/">By checking the Terms Of Service Box you have read and agree to all the Policies set forth in this sites Terms Of Service</a>

Of course this is just an example. As far as making buddypress only visible after they register you can use the technique above in combination with this plugin:
https://github.com/bphelp/private_community_for_bp
Make you to read the readme.txt in this plugins folder as it has some info regarding forums.
Cheers!

Glad you got it sorted.

But ‘manage_options’ is a powerful cap.
I could see where you wouldn’t want to grant that cap to a custom role.

Now that you can explain the issue, I suggest you submit a bug.
https://buddypress.trac.wordpress.org/

Well sorry ‘Dude’ I wrote it took me a half day almost so think 1 minute spent looking for it and posting the link wasn’t too much to ask or expect 😉

Thanks dude! Realy helpful notice ^^

Documentation can be found here: https://codex.buddypress.org/developer/theme-development/a-quick-look-at-1-7-theme-compatibility/

Try giving them the ‘bp_moderate’ capabilities.

It seems edit_profile checks to see if it’s your profile or whether
bp_current_user_can( 'bp_moderate' ) || current_user_can( 'edit_users' )
so adding the ‘edit_users’ cap should work.

See bp_core_can_edit_settings() in bp-members-functions.php

It may not be a bug, but you could find out by submitting a bug
https://buddypress.trac.wordpress.org/

I know this has been a while but for some reason $bp->current_component was coming back empty . I saw some people asking around and if you change
if ( $bp->current_component != BP_LOGIN_SLUG)

for

if ($bp->unfiltered_uri[0] != BP_LOGIN_SLUG)

in Brajesh Singh it should work. just remember to place bp-custom.php in the right folder and to create the login.php file inside of registration (within your active theme)