BuddyPress.org

The “BuddyBar” is by default not shown to visitors that are not logged in. You can change this in the BuddyPress settings, at http://example.org/wp-admin/wpmu-admin.php?page=bp_core_admin_settings

Mine does the same thing… I was thinking it might be because my buddypress is not in the root, it is at /community/ or because my blog is at /blog/ …. changing my blog to /blog/ did require me to get creative because example.com/wp-register came up with a blank page but if I went to example.com/blog/wp-register/ it worked ok….. not sure if this helps or is even related…

I basically started going through what changes were made to your plugin since it last worked, and started replacing code block by block. Once I could debug the XML request, it gave me some eyes in the back of my head so to speak, to watch what I couldn’t otherwise see.

So basically, it sounds like there is something in the xprofile field, and/or something in some users meta info that the XML parser just doesn’t like, so it gets caught up and returns a crappy value? Is that a good guess? You think it’s time to just rip through the user meta and see if anything looks suspicious?

Here’s a question. What if there are users that haven’t yet updated their profiles in BuddyPress? They were converts from a wordpress.org install, and if they haven’t returned since then, BuddyPress doesn’t have a “fullname” for them yet, and they also don’t have xprofile info. Could that break this somehow? Is there a way to watch this user by user and have it spit out an error when it finds a bad value?

Also, just for the record. I’m using BuddyPress RC1, bbPress Alpha6, and WPMU2.7. Is it possible there was a trunk update that you’re using that I’m not that maybe gives you different results than me?

More specifically, if I comment out line 335 in oci_bp_groups_forums.php…

//$user['xprofile_' . $group->name . '_' . $field_obj->name] = array('group' => $group->name, 'name' => $field_obj->name, 'value' => $field_obj->data->value, 'type' => $field_obj->type);

And run the group import, it works without error as well.

If I put a switch on the $field_obj-> name…

switch ($field_obj->name) {

…and only retrieve the custom title and forum signature, the groups import also works (still not for all users though, only groups.) I think it may be tripping over a specific type of field. I’m going to guess the textarea field, but that’s totally a blind guess with no merit or motive what-so-ever.

Okay, so I dipped into phpMyAdmin and deleted ALL bbpress live info, all bbGroups info, and uninstalled all of the plugins completely to get back to 0.

I installed all of the plug ins. Confirmed that BuddyPress could see the bbPress forums. Created a topic, verified on both sides that it was updating. All successful communication from both directions.

Then, I installed 3.0 of the bbGroups plugin. All of the previous stuff that was working, still works.

bbGroups .3 still will not import any group data.

Reverted back to .24, clicked import. Success with no other modifications other than replacing the 3 plug in files.

That is quite interesting, Trent. So you have to wait until 2.8, but the question is, if it will then be possible to add BuddyPress and split the databases afterwards, when the DB gets really big?

(To be honest, the multi-db plugin is the only interesting for me at wpmudev premium, and until they don’t support buddypress I will probably not become a paying member.)

Great explanation Trent. For me it seems like BuddyPress without a multi-db is like shooting yourself in the leg; nothing good will come out of it, if the site will grow big in a short time. Multi-db is of my opinion a must, but is seems like we will be waiting for it quite long time

My process above was using deep integration. Even if an XMLRPC request looks for the xmlrpc.php in the bbpress install directory, it still loads bb-load.php, which loads bb-config.php, which loads all of wordpress before proceeding to load the remainder of bbpress. If an XMLRPC request is being made from buddypress to bbpress (like when viewing a group forum from within BP), I don’t want to reload all of buddypress again invisibly, if that makes sense?

That’s why I did…

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

in bb-config.php, to prevent reloading ALL of wpmu and bp just for a quick xmlrpc peek.

What I don’t get is why it works in every version but this new one.

Short answer, it was written to use anything other than the main WPMU install domain. Even though the MSM plugin allows you to almost run “additional” WPMU instances (virtual), the plugin suite doesn’t work that way. You would have to actually create another install for social.domain.com and run BP or hack the code up which I am sure would be a wreck. Don’t think there is an easy way around this one I am afraid.

The buddypress home them you mean? Just treat it like any other theme and put in an RSS widget to display your feed. Since the member theme isn’t editable in the admin, it requires more, but the buddypress home theme doesn’t.

Trent

Trent, thank you for your instructions. It got me much further in integrating buddypress and bbpress. Unfortunately I still run into the “There was an error posting that reply.” error. I’ve tried everything with no luck, now I think it might have something to do with the fact that I’m running Buddypress/BBPress on a Windows machine (in Apache though). Can anyone confirm this? I enabled the CURL extension for PHP, but that didn’t help.

I tried the Buddypress and BBPress versions from the SVN respositories, still no luck. Anyone got suggestions left?

You might want to look at this: https://codex.buddypress.org/developer-docs/creating-a-custom-buddypress-component/

It’s the dev guide for creating custom components in bp. It also has a complete skeleton component with lots of comments in the source code. Might help.

WordPress detects the currently enabled theme’s root and css directories via the bloginfo(‘template_directory’) and bloginfo(‘stylesheet_directory’) functions.

To call the css and images from the home theme in a member theme template you would have to hard code the path references as “/wp-content/themes/buddypress-home/styles.css”.

Personally, as hard coding is generally a bad idea, I would suggest simply copying the elements you wish to use from the home theme directory to the member theme directory and reference them the usual way.

http://mybodypart.org/

MBP is a social community meant for those of us who wear artificial body parts, and those that love us. If you own a body part that’s made of acrylic, steel, plastic, or any other man-made material, you’ll probably want to have a look around. You can learn more about why MyBodyPart.org exists here. MBP is completely free. Why not sign up for a profile and start connecting with others who have had, or are having similar experiences?

(still needs branding and theme changes, oh, and also users, so why not sign up and help me create this community?

But then we have this page when press [sign up]:

“You must first login, and then you can create a new blog.”

No options for new users.

Thanks…

hello burt,

i posted a comment on your site but in the meantime i’ve found that slug is just the name of the group, isn’it ?

i installed the community blog plugin in the blog i want to become the community blog, enabled it, indicate the slug (name without nothing and no/) of the group but the plugin isn’t doing what i expect.

i would like that any new registered in a group becomes automaticly author of the group blog.

did i miss something ?

thanks for your help

edit after few minuts

OK i installed the plugin on an other test version of buddypress without localization (fr) and it works : the invited users becomes automaticly author rights on the community blog and apperas in the registered users of this comm. blog.

could it be the localization, any idea of what could be wrong with it ?

I couldn’t agree more with donnacha. I would rather see patience and success, than instant gratification and failure. (not that it would ever fail of course:)

You already know that,possibly,

but just to make it sure: You are Great, people.

WP to WPMU wasn’t hard at all, actually. I was really nervous taking my site from WP to WPMU but it went without a hitch.

BP for WP sounds sweet!

That message “Are you sure you want to do this? Please try again” is a nonce failure message. Did you upgrade and not upgrade the bp themes? All bp code is now ‘nonce security’ aware. If your themes don’t send these ‘nonce’ values to bp everything comes to a screeching halt.

For example:

<p><input type="submit" value="<?php _e( 'Save Changes', 'buddypress' ) ?> &raquo;" id="save" name="save" /></p>



<?php wp_nonce_field( 'groups_edit_group_details' ) ?>

That’s taken from the edit group details form. wp_nonce_field() creates a little hidden field with an access key for ‘groups_edit_group_details’ that gets compared in to a similar ‘nonce’ value generated in the actual function that does the validation and saving of group details. If they don’t match, the security check fails with that cryptic message from wpmu.

Have a look at buddypressdev.org, Nicola has already developed a plugin for that!