[@johnjamesjacoby Keymaster 16 years, 11 months ago]

This is exactly what I’ve done in the past.

There’s a lot of pitfalls and problems trying to guess at integration methods to program BuddyPress to understand how to adjust existing installations to match the new setup. There really isn’t a database upgrade involved in keeping your existing forums, it’s just making sure that everything knows where to look to accomplish what tasks.

Having two separate platforms bridged in the middle isn’t a new or uncommon thing, it just isn’t something that makes your average site admin smile.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

I suspect it was just a matter of finding the WPMU functions that don’t exist within WP, recreating them in a plugin and using existing WP functions in their place. This isn’t surprising considering that the platforms share about 99% of the same code, but with the code merge around the corner this plugin is a little bit late to the game for most folks.

A for effort though.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Yeap! This installation is probably the best example of a site with thousands of active users. You can even see how it works in a sisterly fashion at http;//profiles.wordpress.org. Same user tables but different site/blog so to speak.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

@h4x3d,

As you found, there’s some parts of this plugin that are still left to do, namely checkboxes and better trapping of false results.

This plugin is in active development, so I’ll be working on it more this week.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

I think to do this correctly, your loop will need a few more logic checks and error traps in the event that all of the info under a tab may be totally empty, or that some of the fields are empty and others are not. This might not be a problem if all of the fields are required, but you’ll need to modify the idea to taste. Example would be taking…

<?php if ( bp_field_has_data() ) : ?> …and displaying something if the field actually is empty. Same with <?php if ( bp_profile_group_has_fields() ) : ?>

I’d also check around the web for a lightweight JavaScript tab library, or do a quick Google for jQuery tabs and use the jQuery library that comes bundled with WP, and then follow the examples. I know there’s a few that just wrap the tabbed content in a container div and use an H3 or some other logical element as the clickable “tab.”

Otherwise the code above should be sufficient to output the profile data into tables, you just need to find the engine to make your tabs go.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Cool.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Check your BP version number and report back.

This post is pretty old and the avatar upload process has been almost totally rewritten since then.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Not yet, but this is on the roadmap for probably 1.3.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

I’ve got a plugin that will do this in some places. Search the WP plugin repo for “BP Translate” and you’ll find it in there. I’m actually working on an update to it now, but give it a download on a test environment and see if it does what you want it to.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Ultimately it depends on what you’re trying to accomplish. Either/or could work in different circumstances.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Neat. And most importantly, totally doable.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

The reason the type wasn’t passing in the ajax was because it wasn’t saved anywhere in the loop form… You could try replacing the “bp_the_site_member_hidden_fields” function with this in bp-custom.php, then calling this function in members-loop.php in its place…

function bp_custom_the_site_member_hidden_fields() {

if ( isset( $_REQUEST['s'] ) ) {

echo '<input type="hidden" id="search_terms" value="' . attribute_escape( $_REQUEST['s'] ) . '" name="search_terms" />';

}



if ( isset( $_REQUEST['letter'] ) ) {

echo '<input type="hidden" id="selected_letter" value="' . attribute_escape( $_REQUEST['letter'] ) . '" name="selected_letter" />';

}



if ( isset( $_REQUEST['members_search'] ) ) {

echo '<input type="hidden" id="search_terms" value="' . attribute_escape( $_REQUEST['members_search'] ) . '" name="search_terms" />';

}



if ( isset( $_REQUEST['type'] ) ) {

echo '<input type="hidden" id="type" value="' . attribute_escape( $_REQUEST['type'] ) . '" name="type" />';

}

}

Then at the beginning of members-loop.php, replace…

<?php if ( bp_has_site_members( 'type=active&per_page=10' ) ) : ?>

…with something like…

<?php if ( bp_has_site_members( 'type=' . $_REQUEST['type'] . '&per_page=10' ) ) : ?>

…but keep in mind that it’s bad practice to refer to any variable directly in the template; you should probably build a function to wrap around it and sanitize it (although in this case nothing bad could really come out of it.)

See if something like this works?

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

http://codex.wordpress.org is probably the best place to start when trying to figure out what functions perform what tasks for what purposes. Also, think about using an IDE like NetBeans so you can reference functions and trace their usage to get an idea of why you would or wouldn’t want to use a specific function, action, or filter.

WordPress has a steep learning curve, and it uses an action oriented code structure rather than an object oriented one. There are objects out there, but you rarely interact with them directly, and in the WordPress world interacting with those objects is typically left to plugin developers to tinker with, and best left out of the template files.

Since you’re just learning, the best advice I can give you is not to edit any “core” file, or rather any file that comes included in WordPress or any plugin that you might use. If something isn’t doing exactly what you want it to, chances are you can adjust it somehow. If you can’t adjust it, make your own plugin and copy/paste the code that isn’t good enough and make your own functions out of them. If someone would have told me that 3 years ago I would have been a much happier person then.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

To be honest, there really isn’t one, at least not on paper. I can’t say that WordPress has one either.

It isn’t really about how the pieces fit, as much as it’s about how you adapt them to fit your needs. This is similar to WordPress, where it started as blogging software but people bend it around backwards to work in other ways.

Without sounding too much like a broken record, the about page sums up almost all of the functionalities of BP; none of them are more important than the others. It’s up to a good theme designer and code slinger to bring those components out and emphasize their importance to a community website.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Out of the box, BuddyPress is designed for all elements to be created equal. Groups are no more important than friends are no more important than activity are no more important than forums are no more important than directories are no more important than… You get the idea… It’s up to a good theme designer and a great developer to make the functions of BuddyPress pop-out and turn a WordPress site into a meetup.com or linkedin.com.

All of the elements exist in the core and in external plugins to do it, it just has yet to be done.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Donnacha, maybe check permissions on the plugins directory? Do any other plugins appear in the plugins screen?

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Tagged this to look at it tomorrow.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Running WPMU alone in a subdirectory isn’t recommended either, so adding BP on top of it could have some unexpected results too. Either way we still want BP to try and be as flexible as possible so tracking down any ways to make it play nicer with any setup is a good thing.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Check the second line of your .htaccess and make sure it’s pointing to the sub directory where you have WPMU installed.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

If anyone with these avatar issues wants to volunteer to let me peek in at your installation, I’d like to try and fix this for 1.1.3 or at least 1.2. I am away on holiday until Monday, but PM me here if you’re interested in letting me check things out.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Yes it will eventually. The branch is for bug fixes to the current stable version, and the trunk is for new features and code changes. Andy goes through and merges the branch into the trunk as he adds things to it.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

I put a fix for this (and any other possible strange http request) in the 1.1 branch of code. While thickbox is the culprit this time, It’s possible there could be other culprits later. If you NEED to use thickbox and are comfortable using branch code, it’s in there for future versions.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

This is a typical day for us.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

@anointed, I think the best way to do something like this would be to extend the existing multi-site plugin(s) and introduce a method to either serialize the sites that users belong to and add it to a _usermeta field, or insert/update/delete blog_id/site_id to the _usermeta every time a user is added or removed and check against those meta’s on every page load if the user is logged in.

The problem comes from situations where site-admins technically are users on all sites, and how to deal with collisions where users can be added to blogs without being added to sites, if that makes sense?

What you would need to do is hook into all of the places where users can be added/removed from blogs, and add your own actions to those functions to perform your special tasks, which-ever you choose to do.

Then… Once that’s all done… You’ll need to modify the members directory to sniff out only the users that are in those _usermeta values that you assign them to. In my opinion, this is a modification of the kind of magnitude best left for professionals or tinkerers with lots of extra time to test and make sure you don’t corrupt the relationships between users, sites, and blogs.

There are functions already to see which users are already part of which blog_id’s, but that doesn’t really work for all users across any particular group of blogs based on a site_id. I haven’t needed to do something like this myself so I can’t say for sure, but I haven’t seen a core function to find users belonging to particular sites… It would require first checking the wp_blogs table for all blog_id’s matching your site_id, and then checking the roles and caps for users that match.

[@johnjamesjacoby Keymaster 16 years, 11 months ago]

Silly questions…

• Are you 100% there’s no deep integration?
• Maybe put some echo’s in the original bbPress files and see how and when they’re getting included?
• Is there a widget or plugin that’s preloading bbPress before BuddyPress?
• Do you have the old integration plugins disabled?
• Can you confirm in wp_sitemeta that “bb-config-location” is pointing to the new bb-config.php and not the old one?

Just a few things to look at and consider…