BuddyPress.org

What about using the default unexited theme, and no plugins other than BuddyPress (move the folders out just to be certain). Is this something you are able to test on the server where you are having problems?

Ronia-

You are very welcome! Thank you for the kind words and the thoughtful post. As I often say, we aim to please and sometimes we actually succeed.

Our community is only as good as its members. Based on that, I’d say that the BuddyPress community is a vibrant, healthy, and quickly-growing community.

they all appear to be very nice (that’s ok) and very handsome guys (how’s that possible? everyone looks like a hero from Hollywood)

That just makes me smile and laugh! We’re actually not developers, but we play them on TV.

Thanks again for taking the time to share your thoughts.

js apps just don’t play nice with each other.

I ran into this issue before and had to hack the plugin that was relying on an older version of jquery. It worked but it was only going to work on my site. I couldn’t expect anyone else to do the same thing. I just abandoned the use of the plugin that relied on a prev version of jquery.

Sounds like your plugin is loading before bp is loaded. If the core fns aren’t there then bp is probably loading after yours. When you do the upgrade it now has a different sequence in the list of sitewide plugins.

I think jeffsayre put some checking code into the bp skel component. I don’t know if it’s been released yet. In case it hasn’t this is what it looks like:

/**

* oci_load_buddypress()

*

* Checks to see of bp is active. Attempts to load it if it isn't.

*

* @return true if bp is installed and activated

*/

function oci_load_buddypress() {

if ( function_exists( 'bp_core_setup_globals' ) )

return true;



/* Get the list of active sitewide plugins */

$active_sitewide_plugins = maybe_unserialize( get_site_option( 'active_sitewide_plugins' ) );



if ( !isset( $active_sidewide_plugins['buddypress/bp-loader.php'] ) )

return false;



if ( isset( $active_sidewide_plugins['buddypress/bp-loader.php'] ) &&

!function_exists( 'bp_core_setup_globals' ) ) {

require_once( WP_PLUGIN_DIR . '/buddypress/bp-loader.php' );

return true;

}



return false;

}

If this fn returns true then either bp is loaded, bp wasn’t loaded and it loaded it or false bp couldn’t be loaded.

True is your plugin can continue, false is do some kind of graceful exit.

Hmm…

I’ll have to revisit the user delete code, but I’m fairly certain that BuddyPress hooks into that WPMU function and clears out all the additional member info.

Are you using BP1.0.1?

If you want your bpmember and bphome theme header.php and footer.php files to always be in sync, this is what I do. It’s a little tricky, but it works really well at keeping multiple theme files totally in sync.

Copy the code below into a file called hf-sync.php and put it in your wp-content/plugins directory. Then in your WordPress Site Admin, goto your plugins area and activate the plugin called “BuddyPress Synchronized Header/Footer”

<?php

/*

Plugin Name: BuddyPress Synchronized Header/Footer

Plugin URI: http://buddypress.org

Description: Header/Footer Synchonization Functions

Version: 1.0

Author: John James Jacoby

Author URI: http://johnjamesjacoby.com

Tags: BuddyPress, Header, Footer

Site Wide Only: true

*/



// Call this in your header.php file.

// Rename the function to match your theme name.

function theme_name_header() {

?>

<!-- PUT YOUR HEADER HTML CODE IN HERE -->

<?php

}

?>



// Call this in your footer.php file.

// Rename the function to match your theme name.

function theme_name_footer() {

?>

<!-- PUT YOUR FOOTER HTML CODE IN HERE -->

<?php

}

?>

Then, in whatever header.php and footer.php files that you want to use your universal header/footer code, all you’ll need to do is call the functions above.

This lets you make edits to both of your header/footer files for both/any/all themes that use this code, in one central location.

My guess, is that this would/should work very well in keeping bbPress themes in sync also, provided that you insert HTML code to include what bbPress needs also, and make sure not to include that code if bbPress isn’t loaded.

When you delete a user completely from WordPress/BuddyPress, *they should* be totally deleted. WPMU has a process for this, and BuddyPress simply just hooks into it and calls the same action.

If you deleted that user only from the blog area (and not the site admin area) that could cause the situation you’re describing?

Where did you delete the user from?

I know that WordPress 2.8 uses the updated jQuery version, which will tend to break some older jQuery based scripts (it did on my portfolio site) but I’m not so sure about BP or WPMU.

Got a link to your site we can see? What plugins exactly?

Howdy, yes there is. It’s just not documented in the codex. Works the same though.

See: /buddypress/bp-forums/bp-forums-templatetags.php

Carpconnect-

You have another thread here that is dealing with related issues. You never did respond to my last set of questions in that thread.

Finally, to answer your question above:

the plugins i am running are

BuddyPress

BPContents

Support

Signup TOS

Additional Privacy

All in one SEO

Simple Site maps

Upgrades

Invite

I would not have thought these would have affected user profile layout?

Yes, plugin conflicts can affect the way data is output to your browser. To debug this issue, you need to distill your environment down to the lowest common denominator. That means disabling all plugins except BuddyPress AND you need to be using the default themes that come with BP.

Do that, and report back here.

I’ve moved this thread to the Miscellaneous forum. Also, I’m closing this thread as it is not a support issue but a request for services. If you wish to offer your services to the OP, contact info. can be found above.

For future reference, requests for services or offers to provide services should be made on the BuddyPress Jobs Board.

spoke to soon, doesn’t work. can anyone find the eror here?

path: wp-content/plugins/buddypress/bp-languages

files:

buddypress-nl_NL.mo

buddypress-nl_NL.po

buddypress.pot

or does the old language not work for this version?

Strange thing… this happened to me as well. I deactivated all the plugins (including those in the mu-plugins folder), tried reactivating and it started with no problems. From that point I could reactivate all my plugins and it worked.

However, I think I fixed it because I got a similar problem when trying to add media to a post from the media library.

The issue lies in the require statements, in the case of the media library it was within the bp-themes. If you change the require statements to require_once in the bp-themes folder it starts working.

Mods, I am working quite heavily with BuddyPress atm, if there’s any way I can contribute to the core code please let me know.