BuddyPress.org

Upgrade to the trunk version.

chadfrancis, if all else fails you can try this and see if bp and bbpress *can* communicate with this tool. It just creates a xmlrpc link between bp and bbpress using your config settings on both sides. All it does is say ‘hello’ from bbpress to bp if the link works.

http://ourcommoninterest.org/downloads/xmlrpc-test-rig.zip

It’s a wpmu client plugin and a bbpress server plugin. All it does is use the settings found in site admin > bbpress forums and makes bbpress say ‘hello’.

Uses the URL, username, and password. Authenticates them and says ‘hello’. It’s by no means pretty but it might help.

Der… This might not pertain to you anyhow, as I forgot that it also involves the forum last poster bbPress plugin.

Diving deeper…

Looks like this is only happening on the Groups forums Burt. The hidden forum appears to get the correct last poster info no problem.

Still diving…

Yep, Nevermind! Not your problem!

Hey Burt… Something strange is happening… Could be I broke something, but I noticed it after I upgraded to .41 of your community blogs plug-in. It probably existed before hand, but I just noticed it now so it’s something to stay cognoscente of.

When looking at the front page of my forums, there are two (three for me) forum sections, public, group, and hidden. The most recent posts in my groups forums area link to the most recent posts in the public forums in the same position. Basically in the same order, but in the wrong forum. I think you’ll have to look at it to see what I mean.

Looks like maybe the $topics needs a separate loop or needs to be cleared? I haven’t dived into it yet, but I plan to shortly.

@johnjamesjacoby, I see the same thing John. The integration of ‘standalone’ apps such as blogs and forums under the bp umbrella using XMLRPC if necessary. We can’t rely on the possibility of deep integration of apps to be a given. Why should we even assume that it is possible? With that mechanism we don’t have to. bbpress and wp have full blown interfaces to their respective guts.

It’s possible to even completely decouple bbpress, wpmu blogs and bp so that only user identity is the common thread throughout each that ties the apps together. The implication is that they don’t *have* to run on the same server or be managed by the same site admin. I have ideas about that but I’m already way out of the zone and tone of this thread.

Burt, I think I’m picking up what you’re putting down, and I plan on integrating much of what you’re mentioning. Trying to bring MU and bbPress underneath the BuddyPress umbrella a little more really, to open up some of the core abilities and release them to the integrated apps.

I wish I understood the ixr more, because I think the purpose of it is to not have to deeply integrate the components, but rather build bridge plugins to turn on only the functions we would need, much like you did with the bbGroups.

You can always delete the topics through the “bbPress” side, but you can always create and “future enhancement” ticket at https://trac.buddypress.org/timeline for that functionality, even though I am sure it is on the list of things to do at some point.

I’m going to repost my BuddyPress on this page if no one minds…

http://delsolownersclub.com

It’s now a fully integrated BuddyPress/bbPress install, with a bbPress theme to match the Member Theme style layout that BP has become popular for.

I invite any/all of you to join as well (maybe don’t create a blog if you don’t need one) if you’d like to check it out and give it a test drive.

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.

Chad, welcome and don’t be scared; you’ve lurked long enough to know we don’t bite.

I’m going to answer as best as I can in probably no particular order…

In step 6, Trent is referring to the BuddyPress groups page.

Checking cookie integration works fine, and as a matter of fact I’ve always checked it, because I know that not checking it on the bbPress side leads you down a different installation path. I think it basically makes me do the work twice, because checking the box makes you enter the salts and things that we’re already hard coding into the _config files. So, no worries there.

If you check my profile and look at some of the posts I’ve started, I had similar problems and Burt was awesome enough to help me through some things, but chances are that the IXR just isn’t linking up somewhere…

Let me see if I can find exactly how Burt suggested to debug this, but it worked really well and got me up and on my way in a few minutes, after a few hours of banging my head against it.

Looks like I should be able to use “bp_get_field_data” to get the job done, lets see if I can get this to play nice.

Yep. You got it exactly John.

So in theory, if I write a function to filter into your oci_user_ function, say with an sql query to get the xprofile data I want to use in the forum, it will hit that function, run the query, add it to the bbGroups array, and that array gets saved to the user_meta for later access, correct? That way it isn’t always running my query everytime, but only if it doesn’t exist in bbGroups already… Am I on the right track?

Ya. Gotta do that too. User had a problem with the sequence of plugin inits. That’s the solution thanks.

The problem using xmlrpc is that it doesn’t trigger the ‘wp’ action that bp wakes up to. I had no intention of doing so myself at the time of writing bbGroups. I didn’t know what kind of mayhem that might entail. I was trying to be as minimally invasive as possible and not cause more problems than I usually do.

Also in oci_bb_group_forums.php, I added…

if (defined(BACKPRESS_PATH))

require_once( BACKPRESS_PATH . '/class.ixr.php' );

Does the same thing on the bbPress side…

Ok John. If you downloaded that 0.24 zip do it again. The one on the net has initialization of globals for all components now. Except the forums component. It does something that I don’t have time to investigate right now and I don’t know the exact implications of it.

That makes sense. I’m actually using a modified version of your oci_bp_custom.php that you linked me to previously, and I think I have a good understanding of how they all work together.

The problem is going to be getting the xprofile fields and data that I want to use, since there doesn’t seem to be a function that says “get all the users extended field data.”

I guess what I’m running into is that the xprofile data doesn’t seem to be in a variable or a global anywhere, because it isn’t really considered meta. It’s kinda like how $bp doesn’t carry around all of the messages in your inbox on every page load, it also doesn’t carry around all the xprofile fields.

Deep integration actually starts WPMU and BuddyPress before it ever touches bbPress, so all of the functions and variables and data I need and can access seem to be available within bbPress.

Create a file called oci_bp_custom.php and put it in the same dir as oci_bp_group_forums.php. Create a filter like:

function johns_filter($user){

$user = “johns info going across to bbpress and bb user meta”;

return $user;

}

add_filter(‘oci_get_user’,’johns_filter’,10,1);

This traps the filter you want ‘oci_get_user’ with add_filter(). It says trap that filter and call the function ‘johns_filter’ we just created. Give this filter a priority of 10 which is normal and the function johns_filter() takes one parameter.

The $user array that johns_filter() gets when called contains the user id as $user that was built in my fn oci_get_user(). Anybody can create more filters now and add more info that goes across and gets associated with every user.

Once you import again all your new info will get put into meta data for use each time the ‘bbGroups’ info gets pulled out for the current user. This plugin was designed for people who are not running deep integration. It works for you but frankly the xmlrpc overhead is not needed. You have access to all the bp data and functions. One thing you might run into is that the data you are trying to get at and the functions are not initialized yet by the bbGroups plugin. I only fire up the global vars for the components I need. I just do:

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 core, groups and activity globals initialized. You are going to have to fire up the xprofile globals yourself:

xprofile_setup_globals();

Well, hang on a sec and I’ll include that in my ‘init’ handler.

Wow that’s cool… So if I understand correctly, the idea would be to add another function inside the oci_get_user_filter function that would get the xprofile info that I’m looking for? This way it exists within the bbGroups array for later access versus having to pull the query everytime?

I get the feeling that getting the xprofile info might be harder than I thought.

Also for the sake of those of us using deep integration, in oci_bp_group_forums.php if I could ask you to do…

if (!defined(BBDB_NAME))

require_once(ABSPATH . WPINC . '/class-IXR.php');

That helps check to make sure that it isn’t previously included anywhere… Require_once doesn’t seem to really cut it with deep integration…

I didn’t have time to dig through the xprofile component to do exactly what you want but I did have time to do this. I added a filter to the group and user data that goes across to bbpress. There are two fns that build the associative array of info that goes across and gets stuffed into bbpress forum and user meta tables.

I added the filter ‘oci_get_user’ to the oci_get_user() fn and ‘oci_get_group’ to the oci_get_group() fn. I also did a little demo of how to create such a filter for any data you want to go across to bbpress. I pulled the user’s forum list and the list of forums where the user is ‘staff’ and implemented that as a filter. It doesn’t get created or include by the fn I created for that purpose anymore. It uses a filter. oci_get_user() builds and includes info from the bp user obj and then calls the filter for the added and needed forum info.

/**

* oci_get_user_filter()

*

* Live example of how to use the filter mechanism to add info to the data going across to bbpress

* This filter adds the user’s forums and forums where the user is staff into the $user array

* @return

* @param associative array $user from oci_get_user()

*/

function oci_get_user_filter($user){

$users_group_info = oci_get_users_group_info($user);

$user = $users_group_info;

$user = $users_group_info;

return $user;

}

add_filter(‘oci_get_user’,’oci_get_user_filter’,10,1);

The data being stuff into the $user array used to be included in the oci_get_user() fn and now it’s being included in that filter.

You just need to create your own filter fn and trap the ‘oci_get_user’ filter chain like I did above. The zip with the new capability is available on my site as:

http://ourcommoninterest.org/downloads/bp_group_forums_0.24.zip

I didn’t bump the ver number, change the readme.txt or update the plugin’s blog post yet. This reply is the docs for the moment.

You have to be careful what you send across. Only primitive types can go over through xmlrpc. No objects. int, string, bool, array…

That will be super slick of you. I’ve tried scanning through some of the code, and to be honest the only way that I would know how to do it would be through making a new BP_XProfile_ProfileData object and getting the data that way, which I would rather not add a new query to every user on the page if I can help it.