No this is impossible or either not recommended. If you go look inside a database with wpmu/buddypress you’ll see that without even a second wpmu/buddypress install, it’s a total mess since you get a few new tables for every blog/user, now imagine that you have 200 wpmu/buddypress installs in one database and then have 10.000 users per install. It’ll be a huge mess and probably make your server/sites really slow.

Only possible solution would be to make multiple databases, with one database per install. If your on a cheap host, this’ll be impossible, but if your on a dedicated or self hosted, you could get this to work. Still won’t recommend this though, since it’ll take a lot of resources.

I have two installations of wpmu/buddypress, one for Japanese users and one for English users. For English users, I use the user tables of Japanese users. This requires both install to use the same database, but similar to what you want, perhaps.

BP_ENABLE_MULTIBLOG basically allows BuddyPress to not look for the root domain, but instead just work on which-ever domain or blog that you’re on at the time. It isn’t really the answer to this question/issue, but rather a way to side-step the issue.

At the moment, there is no kind of “BuddyPressMU” type setup, allowing multiple BP communities on one installation. But, this isn’t an impossible task to pull off, with some effort.

The underlying problem is that BP uses 1 set of site-wide tables for all MU blogs regardless of site or association. It is coded to think that it has control over the entire MU setup. What would need to happen is for BP to look for which site it is occupying and enumerate its DB tables according to the site_id…

However… If we’re using one MU installation, we’re still talking about sharing a userbase regardless, so even the above scenario might not be optimal. Ultimately the problem comes from the shared userbase, which means even a new “site” has no real way to say these 10 users only belong to this site, and these 12 users to this one, and these 20 users to this one…

Something like this, in my opinion, is something that the core should be aware of, but not manage; similar to sunrise support in MU. As setups like this become more popular and the community need for it arises, I’m sure there will be a great solution to this.

@jjj [blockquote]Ultimately the problem comes from the shared userbase, which means even a new “site” has no real way to say these 10 users only belong to this site, and these 12 users to this one, and these 20 users to this one…[/blockquote]

On my wpmu setup I am using a number of plugins from the premium site which was setup by Andrew. I am not sure which of his plugins does this, but on my setup, each blog does have it’s ‘own’ members.

I had asked awhile back about how to properly go about allowing a user to register on a subdomain blog without ever leaving that blog. This way each blog can have it’s ‘own’ members.

So when I look in my admin, I actually have a list of blogs, and the members belonging to each blog.

Would this be what is needed in order to get bp to filter the activity for each blog, to only display members/blogs/forums/activity streams etc… from the given blog being displayed?

For the life of me I cannot figure out exactly which plugin from Andrew is allowing this. Maybe Andrea would know…

I have many blogs that have been bugging me non-stop to try and figure out how to bring social networking to their site, but have no solution for them. I know that I could simply install multiple copies of wpmu and give each blog their own complete setup with bp, but that destroys the concept of one codebase to have to update and maintain. It would quickly become a nightmare trying to manage multiple wpmu installs just to get bp working for each blog independent of each other.

Blogs can have their own users in MU; they always can. The line gets blurry when you start talking about “sites” though, because a “site” is just another blog where users have roles and caps… The WordPress dashboard doesn’t really make this a clear thing visually, but at the end of the day you still only have 1 users table, regardless of how many sites or blogs you setup and how many users have what roles/caps on which blogs/sites.

I actually like the fact that all the users are in the same table. Down the road it would allow me to do like ning does, where they have individual sites, only displaying information pertinent to the members of that site. However every member also belongs to the ‘hub’ site should they choose to visit it.

I guess the real ‘root’ of the problem for me is how to filter the activity on a per site basis, to give the appearance of a dedicated social group belonging to the site displayed.

I actually like the fact that all the users are in the same table. Down the road it would allow me to do like ning does, where they have individual sites, only displaying information pertinent to the members of that site. However every member also belongs to the ‘hub’ site should they choose to visit it.

I guess the real ‘root’ of the problem for me is how to filter the activity on a per site basis, to give the appearance of a dedicated social group belonging to the site displayed.

If that’s true (and I’m sure it is ), I’m willing to bet that BuddyPress doesn’t know the difference. I’ll need to do some testing around this, but I have a hunch that BP is just going to loop through all members not by site or blog, but just by what’s in the wp_users table, setting up the kind of situation Anointed mentions.

The problem is that domain1.com/members will show the same users as domain2.com/members, regardless of where they signed up from or what “site” they think they belong to.

So if they register at a website about puppies, and a “site” attached to that MU installation about kitties shows up, their profile will show up there too.

I have not yet looked at my database to see what ‘extra fields’ are added which tells wpmu which blogs the user belongs to. There has to be something there otherwise wpmu could not display the members belonging to each individual blog like it does now.

I’ll dig into it tomorrow and report back. Maybe we can somehow ‘hook’ into that extra field, and then use that to filter the members and activity etc…

I”m curious:

Is this something that was just not considered when bp was initially being built?

One would have thought that many users would want bp-mu from the get go, like ning does.

I’m only guessing, but to me it seems that eventually this functionality would have to be added to bp, if it’s ever going to run on wp.com. (At least I thought there were plans of adding bp to regular wp.com sites someday…. read that here somewhere a long time ago)

BuddyPress, as it stands will work perfect for a single domain setup, like 99% of the typical audience will predictably use it for, and for wp.com if bits and pieces of it are used for that purpose.

@anointed, this isn’t a “flaw” in the software so much as it is BP floating on top of MU’s infrastructure. With any of the multi-site plugins, when I look at my site-wide users, I still see ALL users registered from ALL domains/blogs/etc… When I look at a particular blogs users, then of course all that exists there are the users of that blog. Because a “site” is just another “blog” the terms here mean the same thing. 1 central user base, and all users rotate around them.

There might be a few hacks and methods to counter this behavior, but they involve checking user-meta for a list of blogs that user “belongs” to above and beyond roles and caps, or adding additional tables to route users around… It just is a strange setup and something that needs to be built custom for that particular need.

Think of how all the *press.org sites work. One central user base, yet you can login to all of bbpress.org, wordpress.org/com, buddypress.org, and all of their respective tracs and blogs, etc… That’s the same thing that BuddyPress does. The MU multi-site plugin does something a little extra, that none of the other platforms really do, and that’s allow multiple domains to use the same installation… bbPress has the power to do something similar, but no one has really explored how to do it yet, but even in that case you’re probably still sharing user tables and just mapping roles and caps again…

Member ‘xyz’ does not belong to blog #3 so filter all that members information so it’s not displayed on blog #3…

Not sure how else to pose the question…

EDIT: I just re-read the title of this post, and realized that I am not talking at all about multi-site bp, which is probably causing the confusion. I was more talking about a single wpmu install with each blog within the one install having it’s own ‘filtered’ bp…. my bad… sorry about that

@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.

@jjj I checked in the Aug-Sep timeframe and the hooks weren’t there in BP to do a true segregation by site. I have had a lot of requests for it from people using my multi-site plugin. I currently have 3 plugin releases/re-releases I’m working on. All 3 are at the tweaks & testing stages. Once those are done, I’ll be looking at BP & multisite.