ok, I’ve got temporary solution.
File: wp-content/plugins/buddypress/bp-groups.php
Line 1481: yous should have (inside function groups_create_group() / case 2:)
after:
do_action( ‘groups_create_group_step2_save’ );
I’ve added this line:
oci_bb_group_updated($group_obj->id);
So it works, but i had to modify this file which I am not happy with. I guess there is another way of doing this properly. If anyone will find better solution, could you please let me know too?
ok.. i am using Codestyling Localization to edit .po files. this plugin just rocks!
tip is if you move your bp-themes from wp-content/plugins/buddypress/bp-themes to wp-content/bp-themes you can’t see lots of translate in po file.. so dont move it.. just copy it. when you keep your templates copy in wp-content/plugins/buddypress/bp-themes you can translate them from this plugin easily.
bbPress does not have any native ways to hide forums that should be hidden. You can do as I have done – installing a “blank” theme that redirects users to your main site, limiting users to use the built-in group forums functionality only – or you could install a bbPress plugin that hides forums from those that are not allowed to view them. There is such a plugin, intended specifically for buddypress users, but I can’t remember what it is called.
Just to clarify. I am talking about plugin for buddypress to communicate with bbpress. And by saying forum is visible I mean forum created with this plugin on bbpress side is visible (but should inherit settings from group).
Ok, so I found out when I create private or hidden group in buddypress and I check “Enable discussion forum” – it will create public/visible forum.
It looks like first action is creating a forum, then saving actual group settings / by default group will be “public”, so the forum.
I tried to fix it but I am not sure where exactly can I switch the order of actions triggered.
Anyone can help?
Hi
We have an Mu install v2.8 and buddypress v1.02, we moved our site url from http://beta1.ancestry24.com to http://beta.ancestry24.com, this was just a dns change. I have checked all the urls in phpmyadmin and they are all correct.
Now the members theme doesnt pick up anymore, it says
“You do not have any BuddyPress themes installed.Please move “/wp-content/plugins/buddypress/bp-themes/” to “/wp-content/bp-themes/” and refresh this page.” … but the files are there.
I set the permissions of the files to 755 and still not picking it up.
You need to remove the “- ‘.BPLANG.'” suffix from the .po/.mo files in your bp-custom.php
Use this:
<?php
define( 'BPLANG', 'mysite' );
if ( file_exists( BP_PLUGIN_DIR . '/bp-languages/buddypress.mo' ) ) {
load_textdomain( 'buddypress', BP_PLUGIN_DIR . '/bp-languages/buddypress.mo' );
}
?>
3612275Inactive
I’m trying to do this as well, however, it’s not working. I have my buddypress.po and buddypress.mo in my bp-languages folder and I uploaded a new bp-custom.php to the /plugins/ folder however, from there how do I enable the new translation?
I’m using:
<?php
define( 'BPLANG', 'mysite' );
if ( file_exists( BP_PLUGIN_DIR . '/bp-languages/buddypress-' . BPLANG . '.mo' ) ) {
load_textdomain( 'buddypress', BP_PLUGIN_DIR . '/bp-languages/buddypress-' . BPLANG . '.mo' );
}
?>
You guys are the best. Thanks for the time in answering the question. For the time being I have chosen a non-technical solution for the problem. I used domain mapping to set up the corporate blog on mysite.com and am using mysite.org as blogid_1 and my buddypress set up.
It’s important to note that BuddyPress is an opensource project, just like all of the other WordPress related ones. That being said, if you find something isn’t working up to your expectations you are free to develop or contribute to the project to make it work how you wish. As it stands today, BuddyPress does a good job of keeping tidy and cleaning up after itself; better than most plugins in my opinion. The signups table is specific to MU and is a new addition, so you can expect it’s functionality to be misunderstood. When a user is deleted, the idea is that their signup remain in the signups table as proof of their previous registration. One could even argue that removing all user data is a bad idea in the event someone ever needs it later, say for law enforcement purposes.
Regarding blocking spam registrations, read some articles about Twitter. Some analysts have said that nearly 50% of all registrations on Twitter are spammers. Crazy eh? There just isn’t a fool proof way to prevent it from happening unfortunately.
Also, while none of the moderators are directly employed by Automattic, it’s about the best internship I think anyone in our respective businesses can hope for. We all do our best to represent Automattic and are here to help to the best of our abilities.
If you can find a specific bug or flaw in how users are currently managed between BuddyPress and WordPress, you’re welcome to respond here or file ticket in the trac. If you feel your opinion warrants more attention you can message me privately if you’d like also, and I’d be happy to help further.
Hi,
I have got the same problem. I tried upgrading Buddypress to 1.0.3 and got the same fatal error.
I’ve tried replacing all the files in the plugin folder but that didn’t work.
Someone help please!!!!
Sitewide is working now. I am running on the buddypress trunk (last updated yesterday) and it works for now, 
Should this get submitted to trac?
I really do appreciate all the work you do. I’m just really frustrated with the lack of synchronization and consistency between Buddypress xprofile and WordPress users/usermeta etc. Automattic needs to take a serious look at member management.
FYI, here’s the response from the WPMU forum:
Because if a spammer signs up, for instance, and you delete their username and blogs, if their registration member is also deleted, then they can sign up again.
I’m not satisfied with that answer. There must be cleaner ways to block/blacklist spammers.
Isn’t there a plugin that deletes users more thoroughly?
I wish I had a job writing software! You don’t want to know what I do 9 to 5, haha! el_terko is correct. Andy Peatling works for Automattic on BuddyPress. Sam Bauers develops bbPress.
The moderators on this forum are Andy and: Burt Adsit, Trent Adams, Nicola Greco, Jeff Sayre, John James Jacoby and Paul Gibbs (me!). I think we did something bad in a previous incarnation and this is punishment 
. You can also check out this post for a mini-bio.
Hello,
I would like to know where the informations about members (profil buddypress) are stocked?
Is it possible to have this informations in csv?
Thank you
OK, thanks, I’ll post the question there.
But lack of synchronization between Buddypress xprofile and WordPress wp_usermeta etc. is also causing me lots of headaches, so I hope WPMU is not going to send me back here saying that it’s a Buddypress problem. Aren’t you all part of Automattic somehow?
Ask on the WPMU boards; those aren’t BuddyPress tables.
This plugin attempt doesn’t break anything, but still doesn’t put first_name and last_name in wp_usermeta either:
`
<?php
/*
Plugin Name: Real Name Synchro
Plugin URI: http://
Version: v0.001
Author: peterverkooijen
Description: A plugin to store firstname and lastname from the fullname field in Buddypress registration in WPMU usermeta tables.
*/
function real_name_synchro() {
global $bp, $wpdb, $bp_user_signup_meta;
$fields = BP_XProfile_Field::get_signup_fields();
if ( $fields ) {
foreach ( $fields as $field ) {
$value = $_POST[‘field_’ . $field->id];
}
}
$field->id = ‘1’;
$fullname = $value;
$space = strpos( $fullname, ‘ ‘ );
if ( false === $space ) {
$firstname = $fullname;
$lastname = ”;
} else {
$firstname = substr( $fullname, 0, $space );
$lastname = trim( substr( $fullname, $space, strlen($fullname) ) );
}
update_usermeta( $user_id, ‘nickname’, $fullname );
update_usermeta( $user_id, ‘first_name’, $firstname );
update_usermeta( $user_id, ‘last_name’, $lastname );
$wpdb->query( $wpdb->prepare( “UPDATE {$wpdb->users} SET display_name = %s WHERE ID = %d”, $fullname, $user_id ) );
$wpdb->query( $wpdb->prepare( “UPDATE {$wpdb->users} SET user_url = %s WHERE ID = %d”, bp_core_get_user_domain( $user_id ), $user_id ) );
}
//Actions
add_action(‘user_register’, ‘real_name_synchro’);
//Filters
?>`
Can anyone suggest fixes or am I fundamentally on the wrong track?
3509545Inactive
Avatar support would be a very nice feature. I looked at the activity code, but couldn’t make much of it. According to the roadmap the code will change in 1.1, so we have:
Grouping of similar activities by one user within X amount of time
https://buddypress.org/about/roadmap/
I really do hope there is an option in the future to liven up the activity stream in this media centered age. I’m surprised it is not included in the roadmap even up to 1.4?
Also, the roadmap also has this nice addition in store for 1.1:
Profile picture updated entry on activity streams
So it would only make sense the new profile picture would be visible in the activity stream as well, since we can’t expect members visiting each listed profile to just see the new profile picture?
this issue is also mentioned by another person at the german-language-Forum of http://www.buddypress.de
So we are not the only ones having this issue….
Ooh… good question, cozzie.
I don’t think there’s a parameter that combines both the “personal” and “friends” type.
For the avatar, I’m guessing you would need to either hack the “/buddypress/bp-activity/bp-activity-templatetags.php” file or write a filter to override one of the existing ones in bp-activity, which would include the avatar.
Just remember, when you make changes to the core code, like it appears you have, those changes will be lost the next time you upgrade BuddyPress.
That is why you should use the wp-config.php file for customizing your slugs.
There is some discussion about turning Manoj’s photo album plugin into an overall media manager. I’m not sure if he is actively considering this idea or not. You could contact him and find out.
https://buddypress.org/forums/topic/bp-photo-what-a-great-plugin#post-16549
Are you using a non-english, localized version of BuddyPress? If so, this is a known bug: https://trac.buddypress.org/ticket/757
