BuddyPress.org

@brandtd, back from the dead… Looks good and I like the colors a lot.

Something I noticed is that the page links in your main navigation start with “www.” when it doesn’t need it. If you’re using RC1 then that is hard coded and you can just omit that and be good to go.

@Andy, question that I didn’t see asked… For the recent forum widget, are you using the existing widget for non-mu WordPress, or did you make a special one for BuddyPress?

I’ve corrected some bugs now. Please try the latest version, WP Google Maps – 2.0b2, that you can download at http://www.ezbizniz.com/wordpress-plugins/google-maps

wp commerce works fine in mu what are you talking about

A majority of the plugins do work, and it’s up to each individual author or admin to adjust the plugins that don’t.

The obvious plugin issue with MU is fixed in the trunk from what I understand, so it’s only a matter of time before MU gets bumped to 2.7.1 also.

So what it sounds like you’re saying is that you know the answer to your question, but you don’t really like it so you want to vent a little.

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

I would like to see the ability for users to be able to personalise their profile page, with this I mean them being able to pick ‘boxes’ with content (say, my groups, my friends, online friends, personal info, etc sort of like widgets, but picked by each user) and place them on their profile, perhaps able to move them around ajax style (and hide/minimize/maximize them) like in the WordPress backend dashboard.

Unfortunately not, at least right now.

What I consider the main reason for this, among the others, is that WPMU has a specific plugin directory devoted to “instant on” plugins, and BuddyPress relies on that specific ability within WPMU to activate itself and to load up all of the necessary files and functions.

You could, however, install WPMU and BuddyPress together, but then turn off the ability for users to make their own blogs. This will essentially make it operate like a WordPress.org install on the outside, with MU/BP’s sweet creamy insides.

perhaps I posted wrong the line:

<?php bp_friend_last_content_update() ?>

doesn’t do much, you’ll need to decide what material you want to display there.. I assume this is going to be the “home” theme of the wordpress mu right?

I recommend copying all of the contents of BuddyPress Home to a new directory, modifying the style.css to a new name, comparing your existing WP header.php/footer.php files to the ones in your new directory, taking out all the WordPress specific PHP function references and replacing them WordPress MU/BuddyPress ones. Tedious, but effective.

I found that the main hurdle when doing this kind of migration (for me) was letting go of my old WordPress ways of doing things. I.E. no longer using the page widget as my main navigation menu, etc… Which you can still do if you want to, there’s nothing stopping you. The functions are still the same, but you’ll still want to use the BuddyPress home theme as your starting point, as it gives you the building blocks towards integrating your existing theme with the new platform.

I’m also trying to integrate ecommerce capabilities into Buddy Press – but for a completely different reason.

We are setting up a campaign website on the MU platform to use the strength of WP’s CMS for the blog, new, media parts of the site – and then utilize MU and BuddyPress to allow campaigners / supports a place to communicate and interact. (similar to Barak’s “my.BarakObama.com”)

We want to allow supports to donate to the campaign and track there donations on their member pages. I’m looking into a 3rd Party Member management platform called “amember” (www.amember.com) as it has a wordpress integration plugin and offers the ability to sell “subscription” products. It is only tested with the standard version of WP – not MU, so I’m running into some database issues where the wp_1_ prefix is throwing me for a loop. (I’m not the best PHP programmer)

Any thoughts on using these two platforms together? Is there a better solution?

hempsworth, to be honest, this sounds more like a forum functionality than a blog to me. WordPress has never really had this type of straight forward user based permissions functionality, and while I can say that I think it sure could use it, I will also admit publically that I’m probably not the guy for the job. I think ideas like this should be added as feature requests to the trac, because they’re outside of the current 1.0 scope of BuddyPress, and would also involve some changes to WordPressMU.

Burt, I will take a gander. Also, you think possible to add an option to make the members of the group all editors? Could sort of have a blog/wiki that way.

Quick suggestion, although I bet many people won’t run into this issue…

function oci_get_userdata($u){

$u = (int) $u;

$user = bb_get_user($u);

if ($user->bbGroups) {

return stripslashes_deep((array)$user->bbGroups);

} else {

return stripslashes_deep((array)$user);

}

}

Then, I changed…

function oci_user_name($u){

$bp_user = oci_get_userdata($u);

if ($bp_user['fullname']) {

return $bp_user['fullname'];

} else {

return $bp_user['display_name'];

}

}

Basically, I integrated my forums before installing BuddyPress, so there are users that haven’t updated their BuddyPress profiles that won’t have fullname’s yet… This way I have all of their normal info to manipulate later and still get their original wordpress display_name to fallback on…

There is probably a much prettier way of doing this, but this is the solution my tired brain could come up with for now.

I had a heck of a time converting my WordPress.org install DB over to WordPress MU, simply because my WP export/import only worked for about 10% of the data.

I currently have a setup like you’re looking for, from delsolownersclub.com and delsolownersclub.com/blog. I think I did this my chance, because I made a few mistakes in my transition myself.

So, yes it’s possible, and it actually shouldn’t be too difficult if you already have WPMU installed on your /blog directory. If you simply have WP.org there, then it’s a little bit of trial and error and DB dumping and editing.

The other thing I ran into as an issue were the attachments and their directories, and the associations for those files in the database. Example, WP.org saves files in the root/uploads directory, but WPMU saves them in root/wp-content/blogs.dir. That meant dumping the whole database to a .txt file, searching and replacing /uploads with /wp-content/blogs.dir, and then importing the whole thing in phpMyAdmin.

I did it that way for myself rather than running any weird SQL queries because my site could afford the downtime and because I didn’t want to miss anything, causing bad image links, etc…

Does that make sense?

export your blog to the wordpress format then install mu and buddypress, your blog can then still be accessed by /blog, but obviously you will have to import it first,

most of the plugins will work with mu but some will not, i guess you can only hope and try them out

you will need to add your plugins again, i suggest you add them one by one to see what is working and what isnt, hope that helps, let me know if you need more help

There’s a few WP plugs that might work (I’ve not tried them and cannot guarantee they will work):

https://wordpress.org/extend/plugins/login-style/

https://wordpress.org/extend/plugins/bm-custom-login/

etc.

You should use wordpress hooks to do that,

but if it works that’s ok, but when will be the next update you’ve to hack the code again

OT “haaah “Che culo!””

You can also check out the following plugin as well

https://wordpress.org/extend/plugins/peters-login-redirect/

Trent

I think the idea is not to have BuddyPress permanently alter the WordPress related data.

I’m new to BP and so I’m not familiar with how all the functions work, but what in the original WP data structure would be altered by deprecating fullname in favor of using the WP fields?

…then really BuddyPress should be able to modify ALL of the original WordPress user info exactly like the profile admin panel does…

I would like that, actually. Or at least to have the option to have the profile be able to modify that information.

I want the original WP functionality that allows a user to choose which fields — username, first name, last name, or nickname — to display for them. I thought that was a great addition to WP and I don’t like that installing BP has effectively cut me and my users off from that choice without some serious code modification on my end.

I think the idea is not to have BuddyPress permanently alter the WordPress related data. Right now, and please correct me if I’m wrong, but past of the design and development process of BuddyPress is that it can be added and removed without any changes done to the WPMU data structure, apart from conveniences like changing a password, etc…

You can rename the “Full Name” in the BuddyPress to say “Nick Name” or “Display Name” or whatever you’d like, and then code your themes to use that info if you so choose…

To be honest, from a developers standpoint, I like how it is right now, as it allows me to keep things separate. If you’d like to open up the ability to modify the fullname, then really BuddyPress should be able to modify ALL of the original WordPress user info exactly like the profile admin panel does, with website, info, firstname, lastname, etc…

I’m with DJPaul; I would like to see BP’s proprietary fullname field deprecated and have WP’s native fields be used instead.

Not only would it allow for more customizability/adaptability of BP themes, plugins, etc but it would also get rid of an extra field that, as far as I can tell anyway, can be handled just as well with WP’s first_name and last_name fields.

I agree that we should put this suggestion into a trac ticket.

@jimthedj65, Regarding WP video framework plugin integrated into BP, you need to liaison with ddmitry on this. He got it working on his site !!

https://mu.wordpress.org/forums/topic.php?id=10778&page=2

When you use deep integration bbpress clears all the actions and filters. bp runs on actions. It does this as part of the load sequence.

In bb-settings.php:

/**

* Remove filters and action that have been set by an included WordPress install

*/

if ( defined( 'ABSPATH' ) ) {

$wp_filter = array();

$wp_actions = array();

$merged_filters = array();

$wp_current_filter = array();

}

When I’m using xmlrpc I have to manually fire up the bp globals I want to refer to like:

function oci_bp_group_forums() {



// only do this if the xmlrpc server is firing up and we are servicing a request

if ( defined('XMLRPC_REQUEST') && XMLRPC_REQUEST ){

// bp's globals don't get set until a 'wp' action occurs. this seems to be all that is needed.

bp_core_setup_globals();

groups_setup_globals();

bp_activity_setup_globals();

}

}

add_action('init','oci_bp_group_forums');

That gets triggered by the end of the wp-load.php sequence. do_action(‘init’) is the last thing that happens there.

bp gets woke up by listening to the ‘wp’ action. I think all of bp gets activated by ‘wp’.

I just remember having some problems with xmlrpc and the ‘wp’ action so I manually tied things to the ‘init’ action. All the plugins for bp load, it’s lots of other stuff that gets initialized by ‘wp’.