BuddyPress.org

realfam, bp covers wpmu, bbpress and bp itself. We try to address all three environments simply because we *have to* to get bp running. That thread was a little off topic for the forums. Even though it did relate to wpmu sorta, kinda.

Then again I just get cranky at times.

This thread contains non core mod fixes for the above issues:

https://buddypress.org/forums/topic.php?id=814

@4inflater

apeatling said very clearly, in accordance with what he said to do it, very simple, good luck.

My translator a language package, I e-mail to you, you increased to download the page to be possible?

I thought about doing the same thing. I setup 2 instances of bbpress. One for groups and one for ‘the community’. The groups forums were hidden. I didn’t like it too much. I wanted the public groups to be public forums but read only until users joined a group. I also wanted the private and hidden groups to have hidden forums.

See this thread: https://buddypress.org/forums/topic.php?id=696

David, have you seen this?: http://www.smashingmagazine.com/2009/01/09/tweetbacks-plugin-for-wordpress/

and this: http://www.smashingmagazine.com/2009/01/08/twitter-avatars-in-comments-wordpress-plugin/

It can, but the amount of spam accounts will increase dramatically. The reason for sending the account password via e-mail is to prevent spammers from simply entering a known username and password and creating 1000’s of spam blog posts on wordpress mu.

I have a similar situation, where I have a current site with 15k users, username and passwords. What I used is this plugin. It works well on wordpress and buddypress.

https://wordpress.org/extend/plugins/external-database-authentication/

When a user logins, it checks my “other” database for the username, and validates the password against it. This means they don’t need to do the e-maiil thing, as their e-mail was already validated on the old site. It then creates the user in wordpress and the user doesn’t notice anything.

How you could do this for your friends, just make a table of all the friends, and set the same password for everyone initially, and ask them to change it. I only suggest this for very small beta sites with friends you trust, like less then 10 people.

Brad

http://gorgeousgamers.com/beta

Hopefully this will make sense

I have 4 directories, which I download the svn update to, and then copy them over to the live site:

/bbpresssvn

/buddypresssvn

/wordpresssvn

/privatedevsvn

By logging into the command line, I can do this

svn up

inside each of those 4 folders and it will update them to the newest trunk release. Then I run this command (or similar for buddypress)

cp -R * ../beta

and copy the files to the dev server. So far this has worked really well.

The private dev svn is where I upload my own plugins and themes I’m doing development on. This method is extremely fast as I never have to ftp any files between the internet, my laptop and back up to the web server. It does require command line access and knowledge of svn.

Hope this helps,

Brad

http://gorgerousgamers.com/beta

http://www.ex-brief.com

under construction

jvinch – this is the code I use for the Featured Members on the homepage:

<div class="widget">

<h2 class="widgettitle"><?php _e( 'Featured Members', 'buddypress' ) ?></h2>



<?php $users = BP_Core_User::get_random_users( 2, 1 ) ?>



<?php if ( $users['users'] ) { ?>

<ul id="featured-member-list" class="item-list">

<?php foreach( $users['users'] as $user ) : ?>

<li>

<div class="item-title"><strong><?php echo bp_core_get_userlink( $user->user_id ) ?></strong></div>

<div class="item-avatar">

<a href="<?php echo bp_core_get_userlink( $user->user_id, false, true ) ?>"><?php echo bp_core_get_avatar( $user->user_id, 1 ) ?></a>

</div>



<div class="item">

<!-- div class="item-meta"><span class="activity"><?php echo bp_core_get_last_activity( get_usermeta( $user->user_id, 'last_activity' ), __('active %s ago') ) ?></span></div -->



<?php if ( function_exists( 'xprofile_get_random_profile_data' ) ) { ?>

<!-- ?php $random_data = xprofile_get_random_profile_data( $user->user_id, true ); ? -->

<div class="item-title profile-data">

<strong>About Me: </strong><?php echo BP_XProfile_ProfileData::get_value_byid( 2, $user->user_id ); ?>

</div>

<div class="item-title profile-data">

<strong>RV Type: </strong><?php echo preg_replace('/^.*?"(.*?)".*$/', '$1', BP_XProfile_ProfileData::get_value_byid( 3, $user->user_id ) ); ?>

</div>

<?php } ?>

</div>

</li>

<?php endforeach; ?>

</ul>

<?php } else { ?>

<div id="message" class="info">

<p><?php _e( 'There are no members to feature.', 'buddypress' ) ?></p>

</div>

<?php } ?>

</div>

I understand completely. What we got here is just the core of a wonderful thing. Some areas of bp are feature rich and some need to be fleshed out. It’s up to us to determine what the features should be based on how we want to use bp. Our problem now is that the docs for the features that do exist are kinda sparse. Like any open source product it’s up to us to create them.

This is really how wpmu, bbpress and buddypress are designed. The architecture is extensible and the extensions and features grow out of need. I’d much prefer this way of doing things than being stuck with something monolithic. Here’s what ya get. Take it or leave it.

What does this have to do with bp? This is a buddypress forum.

No, you wouldn’t have to do any of that running around. If that theme is only used on that blog and you have it turned off for all other blogs except the home blog on your site, then you just have to drop this into functions.php for that theme.

remove_action( 'wp_footer', 'bp_core_admin_bar' );

remove_action( 'wp_head', 'bp_core_add_css' );

In that theme the admin bar won’t show. Ever. If you use that theme on other blogs then you’ll have to wrap those two calls in some code to detect what blog it’s running on and only make those calls on blog id 1.

You could also create a plugin that runs in /mu-plugins, use those two calls above and just detect what blog it’s running on and make the calls only for blog id 1. That might be better.

so far, it seems we’re the first band to be using BuddyPress.

Check us out at:

http://aimusic.com

We’re not using the blog features on it…we’re mainly using it as a way for our fans to connect w/ us and our video posts etc. We just launched it yesterday. come check us out.

Nick

The plugin adds a Google Map into each profile with a marker where the member is. The member can manually set the location by moving the marker and saving it.

If the member hasn’t saved the position, the position of the IP-address the member last used to login is used.

You need to have the latest buddypress-member theme from trunk in order to see the map in the member profile as I’m calling add_action(‘bp_custom_profile_boxes’, ‘bp_google_maps_profile’, 2); to insert the map into the profile.

Kinda something like this?: https://buddypress.org/forums/topic.php?id=540

I have an early beta version of a Google Maps plugin that works with WordPress, WPMU & BuddyPress.

Go to http://www.ezbizniz.com/wordpress-plugins/google-maps and click on the “WP Google Maps – 2.0b1” link to download.

Put the wp-google-maps folder in mu-plugins, copy the bp-google-maps.php file to mu-plugins, go to wp-admin/admin.php?page=wp-google-maps/wp-google-maps.php and enter your Google Maps API key for your site.

I wouldn’t expect / demand that buddypress should work with a beta. I believe Andy et al. will after 2.7 is released.

Thanks burtadsit.

In my install it looks like none of the slugs got created… I have no idea why… but it means /groups or /register of course go nowhwere . Apache error log ain’t much use… of course it tells me those pages are 404!! Is there some way of manually creating these in the DB? It looks like a number of people are getting one or more slugs not created for some reason. My install is in the site root, so nothing to do with that. It’s on my own Clark Connect server, so shouldn’t suffer any of the shared hosting issues.

I’m trawling through bp-core.php right now and sticking echo’s all over the place, I’ll report back if I find anything.

Not sure why this thread got overlooked.

As far as I know the choice of subdirectory or subdomain as an mu blog option on install doesn’t matter. I have seen complications where people install mu in a subdirectory under the document root and then have chosen the subdirectory blog option.

I haven’t been able to pin it down but some weirdness crops up in that case. In both cases it’s been difficult to determine exactly what the problem was. They had difficulties getting their shared hosting provider to cooperate. It’s kinda tough to pin things down when getting access to error logs is like trying to get an audience with the pope.

There are no ‘subdomain’ only specific requirements.