lol. This ‘buddybar’ thing I started is catching on. With all the right people it seems. I’m never gonna live this one down.
The buddybar(tm) relies on lots of mu specific stuff. It gets generated on each page load in mu. We ain’t in mu no more when we get to bbpress. I’ve been thinking about this issue also. A quick think tells me I might pass a global var from mu to bbpress that holds all the menu items that are useful to me over at bbpress. Then create a bbpress menu bar that builds a menu from that global. Same look, same items just not dynamicly built for each page load. Just gens it from the global each bbpress page load.
Just a quick think.
PHP var space is PHP var space. bbpress is just another hunk of code in PHP var space. Gotta go do some research on this php session stuff.
If you come up with anything, let me know, please?
Hey, the ‘buddybar’ is a great name. It stuck with me after I first heard/read you using it.
Yeah I agree that there should be a MU pass-through for the Buddypress plugins to work on bbpress. I don’t see why they wouldnt since everything is fully integrated, but for some reason they are not. This also, makes me wonder how Nicola gets avatars to show up on the bbpress side. I am having some issues with that as well! Any ideas? I would love to see the forum theme that Nicola is using and make my modifications off of that!
I believe Nicola is using gravatars for both his buddypress and his bbpress installations.
I’ve noticed even if I use what bbPressers call “deep integration” (including wp-load.php in bb-config.php) on the bbPress side, bbPress still seems to blast out the BuddyPress specific content. I’ve echoed the files and I know they are all getting included, they’re just not doing anything once bbPress gets a hold of it.
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’.
