[madyogi]

Yeah, I figure a project like this is pretty complex, but I also figure it’s worth putting in the time on. I’d like to be able to find my own solution in the short term without completely going the wrong direction or having to backtrack too much when the tried and true, fully-developed solution comes out.

This in my mind is really going to be the future of the blogosphere. I just think it would be so fantastic if pretty much all the places on the net I frequented knew me by just 2-3 logins, and if all those places were able to share some pieces of information with each other.

You know, I work in health care, and this really has much larger implications than just blogging and social networking. It’s a real mess trying to figure out how health care providers will be able to securely share digital information about patients moving forward. Not saying Open Stack development can necessarily accomplish this, but the need is similar.

[madyogi]

Thanks for the response, Jeff. That sounds very exciting. Is there ever any timeline on these kinds of things. We’re still in the 1.1 release. I’m going live with my site in January sometime.

I’m wondering what ways a person like myself (an experienced video producer and web designer by trade, a 50% capable/wannabe web developer) might stay ahead of this curve a bit and begin implementing/understanding some of these technologies before they hit BuddyPress, instead of just waiting around for 1.4 to come out.

Any thoughts?

[madyogi]

I too think this looks very appealing. What is the consensus solution going forward for being able to allow user registration (on your BP/WPMU blog) with existing social network credentials like Facebook or Twitter? It seems to me like there isn’t one at the moment.

Is anyone (or perhaps a group of devs) working on this specifically? It just doesn’t seem sustainable to ask users to create accounts everywhere they go ad infinitum. Something’s going to have to give. Seems like a great opportunity for some solid, entrepreneurial developers!

Oh yeah, and what’s Open ID?

[madyogi]

I realize this topic may not be active anymore, but I’m curious about the functionality of the BP-FBConnect plugin. Once this plugin creates a user account based on Facebook credentials, can that user then utilize all the extended profile and wire and other buddypress features on the WPMU/Buddypress install using those credentials, or would that person have to create a separate account?

[madyogi]

Alright, everything seems to be upgraded and functioning properly now. Not sure where I went off the rails yesterday to have completely lost the buddypress functions.

This time I:

1. backed everything up (did this yesterday)
2. deactivated all plugins (buddypress last this time)
3. moved new WPMU files over to server
4. upgraded in admin panel
5. upgraded and activated buddypress
6. upgraded and activated other plugins

[madyogi]

Thanks for the ideas, Jeff. Going to give this a more systematic try now. Stay tuned …

[madyogi]

I will say this: I think it had something to do with the WPMU upgrade. Only reason I say this, I replaced the 1.1.2 buddypress folder with the backed-up buddypress plugin folder. Still gave same errors, so I’m scratching my head.

[madyogi]

So, I just reverted to my backup install … everything works fine, but everything’s out of date. Anybody got any thoughts as to how I might not break buddypress during a future upgrade?

[madyogi]

I’m searching around the forums and not seeing anything specifically related to my problem, but I’m thinking this has to be something simple. For whatever reason, after installing the new version of WPMU (2.8.5.2), it’s not recognizing any of the buddypress functions.

I’m quite befuddled.

[madyogi]

Just as an update, I activated the default buddypress theme, and all appears broken with my new buddypress install. It is giving me the same “call to undefined function” error regarding bp_page_title().

If anyone has any idea why this might be, I would greatly appreciate any advice. I tried to follow all instructions. I don’t think I have any “buddypress dependent” plugins installed, so I didn’t figure it would affect things that I deactivated buddypress first.

Any ideas why all the bp functions are suddenly not defined?

[madyogi]

Okay, by adjusting my statements to say:

if (  bp_is_whatever_component() && !bp_is_blog_page() ) {

//do whatever

}

They are functioning as I would expect, except for the wire component, which still is returning false in all cases. I have no messages on my wire, could that be causing this?

My question now has to do with shortening my code. I now have a string of 7 if … elseif statements to query all bp_components, including communityHeader.php if any return true, before my else, which includes homeHeader.php in all other cases. How might I go about reducing my string of 7 to one?

[madyogi]

Alright, I’m super-close now it seems, but I still need a bit of advice. It seems that what I have so far works in every case but search pages and 404 pages.

The way it looks to me, every bp_is_…_component() tag returns true for all wordpress is_search and is_404 queries. So, two questions:

1) What is it about all the bp pages that trigger the 404 and search conditionals in wordpress?

and

2) How might I differentiate the two cases?

[madyogi]

So, this is noteworthy – I went through and added all 7 of the top-level is_ function’s found in bp-core-templatetags.php between lines 1250 and 1330 or so. This does seem to fix all my problems except those regarding the wire component. For some reason my wire pages are still showing homeHeader.php instead of communityHeader.php.

This configuration does seem to cascade, insofar as profile > edit still shows communityHeader.php without having to reference bp_is_profile_edit specifically.

Anyway, more later.

[madyogi]

I think I’ve got a lock on this, thanks to everyone’s help.

@Xevo – It does seem like I ought to be able to query the body classes, or at least use them for styling purposes. I actually started a bit earlier in the file, at about line 1342, finding bp_is_profile_component(). With this I was able to isolate the profile page from all others. This seems to be functioning properly for now, but it still looks like I’m going to have to query for each type of buddypress component. I have not yet seen anything that functions like a bp_is_component(), combining all these together. Doesn’t seem that difficult to do in the next core, if it doesn’t already exist. It would just be nice to have one tag that would check for any of the is_ functions between line 1250 and 1587 in bp-core-templatetags.php, and return true if any of the returns true.

Perhaps one function like this does exist already?

Thanks again for everyone’s input.

[madyogi]

Right – wick’s end … HA!

[madyogi]

@John James Jacoby – It seems like the bp_is_blog_page() is returning true under every circumstance, even if I’m in my root directory, not the /blog directory. I would love to be able to “just check one or the other,” as you say, but it seems like the wp conditionals like is_archive, is_home, etc. are competing with the bp_is_… conditionals. I am just looking for a way to check if a buddypress component such as profile, messages, activity, wire, etc is being viewed. If this is the case, display one header, otherwise, display another.

[madyogi]

Alas, my excitement continues to be dissuaded.

The statement … if ( bp_current_component(profile) ) … seems to be acting just like bp_is_user_profile … they both return true on every page load. The only reason this seemed to work earlier is because I placed the if ( is_home () ) condition above it, so that overrode it until I went to, say a blog archive page (again, there is only one blog on my page … I’m only interested in the profile/wire/activity/friend functions of BP.

Though it’s still a bit puzzling that the if … elseif … else statement in my actual homeHeader.php file functions as expected in virtually every circumstance, setting the proper menu tab setting.

[madyogi]

@Xevo – I’ve actually tried several of those, but I can’t get them to perform as I would expect. Not sure why, but bp_is_user_profile returns true even when no profile component is being viewed.

[madyogi]

Okay, so I think I’m getting somewhere. Dug through the bp-core-templatetags.php file and found the bp_current_component() tag. So I added the following to my header.php file:

...

} elseif ( bp_current_component(profile) ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/communityHeader.php');

}

This seems to work, but all the components are now giving the communityHeader.php file, not just a profile page. So the activity, messages, friends, etc pages are all returning true for this particular elseif statement. Is the parameter “profile” meaningful in this case, or is this just checking to see if there is a bp_current_component or not? Alternatively, are all these pages (activity, messages, wire, etc) considered profile components?

Thanks again so much for all your help.

[madyogi]

I am essentially not using the blog function of BP at all, only the extended profiles, the wire, the activity, etc. That said, all pages are in essence the home blog of my WPMU install. So what I’m needing is to figure out if I’m (or one of my users) is looking at a BP component or not, then display the right stuff.

Would it make sense to query the $bp global here? as in:

...

} elseif ( $bp->current_component == profile ) {

//include whatever corresponding content here

}

...

I’m not as up on my php as I should be. Is this a viable option?

[madyogi]

Thanks to you both for the quick responses!

@DJPaul – is there somewhere I can find all the parameters bp_is_page() will take? For example, I’m wondering if the profile page has a generic slug/parameter that will return true every time a bp profile page is being displayed. Same with any messages page, activity page, etc.

@David – I’m actually using a script called Dynamic Drive tabs to display the main menu tabs and their submenus. With this script, as you roll over the various options, it will display the submenu divs. Then it defaults back to the current tab, which is set when you activate the menu via javascript. The $mainMenuTab variable is assigned an integer based on what type of page you’re on, then echoed in the javascript call. It’s working quite well for me so far.

[madyogi]

Okay, so I followed your advice, toddlevy, but for whatever reason, I’m still getting my profile header the home page. The following is in my header.php file:

<?php



global $bp;



if ($bp->current_component == BP_XPROFILE_SLUG) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/communityHeaderTest.php'); //include this header on BuddyPress profile pages

} elseif ( is_home() ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/homeHeader.php'); //include this header on home page

} elseif ( is_single() ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/homeHeader.php'); //include this header on posts

} elseif ( is_page('Why We're Here') ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/homeHeader.php'); //include this header on about page

}  else {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/communityHeader.php'); //include this header on BuddyPress pages

} ?>

Any ideas as to why this would include communityHeaderTest.php on the home and about pages? Single pages are including the correct header.

I have been working with this code in my header, which seems to work for what I need:

<?php



if ( is_home() ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/homeHeader.php'); //include this header on home page

} elseif ( is_single() ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/homeHeader.php'); //include this header on posts

} elseif ( is_page('Why We're Here') ) {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/homeHeader.php'); //include this header on about page

}  else {

include (TEMPLATEPATH . '/../ARHealthCareersFrameTheme/customHeaders/communityHeader.php'); //include this header on BuddyPress pages

} ?>

Still, it seems like I should just be able to use the BP conditionals to find out which specific BP page I’m on and display content accordingly.

[madyogi]

I know this is an old topic, but did anyone ever figure out if there is a conditional that would indicate if you are looking at a member profile:

if (I’M LOOKING AT A MEMBER PROFILE)

do this

else

do this

It seems like bp_is_user_profile would do this, but it returns true when the profile is not being displayed.

[madyogi]

So, what I can’t figure out now is what precise conditions those conditional tags are checking. Specifically, the condition bp_is_user_profile seems to be true all the time. I am wanting to load in specific content only when my profile page is showing, but checking the bp_is_user_profile conditional tag always displays that content, even when the profile page is not being shown.

Is there any documentation saying specifically what each of the conditional tags checks, ie what would yield a “true” return?

[madyogi]

Thanks once again for your help, Travel-Junkie! I’m looking forward to working on this more tomorrow. I’ll let you guys know how it goes!