Seems to work for me, though not extensively tested.
Only note to consider with this members-only plugin is that it redirects users trying to get to the main blog/site, but if they have URL’s to other “pages” members pages, etc… they can get to those directly. The redirect doesn’t apply to those pages/sections. (at least not yet)
If you find a solution to this problem wpmu/buddypress-wide, please let me know. I’m looking for a similar solution.
This is not a BuddyPress issue. It is a WPMU issue. I would suggest searching the WPMU forum for an answer. If you cannot find an answer there, then post a new thread in that forum.
Okay, so you’ve successfully upgraded to WPMU 2.8.3.
Did you finish the WPMU upgrade by logging into the backend as the Site Admin and going to “Site Admin > Upgrade” and hitting the “Upgrade Site” button?
After that, you go to Plugins menu group and under your BuddyPress plugin, it should say:
There is a new version of BuddyPress available. View version 1.0.3 Details or upgrade automatically.
Ahh. I see! I gotcha now.
I have seen this behavior in IE when you try to put a width on the body tag… which the default theme does. The simple solution is just to get rid of any width declarations on body (or maybe 100% would work) so the entire problem goes away. Just add a wrapper div around your entire site and put your page width on that. Open it as the first thing after body and close it just before the close body tag. Give it an id and then apply your width to that… so…
HTML
<html>
<body>
<div id="wrapper">
[everything else]
</div>
</body>
</html>
CSS in site-wide.css
body {
min-width: 100%;
max-width: 100%;
}
#wrapper {
width: 970px;
}
Of course… this means editing your theme files (header and footer)… not just overriding some CSS. But I think this would be a better solution than relying on javascript hacks. Also, I have not tested this in IE… so I’m not 100% sure it will work. You might have to edit the base.css files to completely remove the min-max width declarations rather than just overriding them with 100% in the site-wide.css file.
David,
Sorry realised that I’d already got body width at a fixed size but not in site-wide, which when looking at it now seems obvious.
Problem with IE however is in the calculating of sizes. When a user resizes the screen some elements are left floating and are not in line with the rest of the page. Hitting refresh works but it doesn’t help the user experience.
The body width works fine in most cases, but the need to fix the rendering bug in IE is what has been causing the problem. That is what the javascript has been about. But in drilling down through various forums, the answer has been to try and fix the css. The problem seems to be the inheritance or lack of it of position:relative in IE. Adding this to a top-level div seems to work (for me anyway)…
Hope that makes sense…..
hi there,
Integration was smooth for me, except for one thing 
here is the site in question: http://www.waapsols.com
Its running Buddypress.
These are the steps I followed to integrate BB and BP… https://buddypress.org/forums/topic/bp-103-and-bbpress-which-version-plugins-cookies#post-20006
WPMU, BP, and BB is working good. But I just can’t get the logins to work, I mean when I login into WPMU, I am not automatically logged into BBPress Forum.
I am guessing thats the reason why in my BuddyPress, the forum is working fine, but who ever posts, there is no gravtar or name is seen 
Can someone help, what might have gone wrong.?
I guess this is the latest trunk. Is there a faster way to download this thing or is file by file the only option?
It is part of the trunk; problem is that is under development and unstable versions of the code. It’s not recommended to run off the trunk version so I will let you find out where the BuddyPress SVN is and how to get the trunk version if you really want it.
Good news is, BuddyPress is due for v1.1 in a couple of weeks as far as I know, so you don’t have to wait long for the next stable, official release.
Hey there,
All the steps posted are just great and simple to follow
Thanks for it Graeme
WPMU, BP, and BB is working good. But I just can’t get the logins to work, I mean when I login into WPMU, I am not automatically logged into BBPress Forum.
I am guessing thats the reason why in my BuddyPress, the forum is working fine, but who ever posts, there is no gravtar or name is seen
Can someone help, what might have gone wrong.?
Thanks JJJ for the tip.
I’ve been playing with it and it works for me only if the template page is called fun.php instead of example.php.
Anyway I find it very useful.
Thank you
So looked around and indeed no decent default solution for a 1 blog per blog.
Could i Make a forum and just link and show 1 categorie of it then?
I could create 1 forum with different categories for differerent users, then integrate each forum categorie for each blog inside my blogs on wpmu, any thoughts about this?
People keep referring to turning certain components off, but as far as I can tell — by searching these forums and by muddling through the admin — there is no way to just “turn off” blogs so that the blog option disappears. Vanishes. As in there is no clicking on create a blog only to get a “blogs have been disabled” message. That just looks messy and like a mistake.
Maybe I’m wrong? I’d love it if I am.
I’m usually capable of working my way through a tutorial and learning something by the end. But this post is of a magnitude that I’m not sure I know enough to tackle all the steps. Is each of your posts, Burt, a step-by-step instruction on how to accomplish Ben’s request, or do you revise your answers along the way?
I’d like mostly what Ben is asking for. I want to use BuddyPress as a member directory. I don’t wish for anyone to make blogs through MU/BuddyPress other than my staff. I don’t want the “create a blog” option to appear anywhere. Not in the member profile, not in the tool bar. Essentially I want the option not to exist for users. Will the tutorial above show me how to do that?
Starting from instructions in post one, I’m finding that changing the admin setting from “only user account can be created” to “only logged in users can create new blogs” results in a “you must login to create a blog,” which takes me to the wordpress sign-in page before I have even registered.
The “only user account” setting generated what I would like to have happen, a signup screen sans “gimme a blog.”
Please forgive my being an ignoramus and let me know if I should patiently work my way from top to bottom, or if there is another solution outlined in a different post.
Thanks!
See https://buddypress.org/forums/topic/faq-how-to-code-snippets-and-solutions, “How to hide selected profile fields” and “How to show secondary profile fields while hiding the “Base” profile fields in a user profile”.
These should get you started and this has been discussed elsewhere on the forums, so do a search.
Ok that;s a shame its not possible to have 1 forum per blog..
perhaps indeed a good idea for a plugin, if anyone interested please let me know in this topic, perhaps we can work something out together.
WordPress MU and Buddypress have separate profile/user management tables that aren’t synchronized and in some ways clash. End users will see different profile editing screens, in wp-admin and buddypress front-end, with different data that have nothing to do with eachother. Users are identified by full name, username, nickname, blogname or whatever depending on where in the system you are and how it’s configured. It’s a confusing mess and my pet peeve.
But I’m not even sure if that’s relevant to your problem, so I removed the rant.
Hmm, I think these are triggered because BuddyPress doesn’t pick up who the recipients are.
Not being funny, you are entering correct usernames in the ‘to’ field, right?
I think you’re right, DJPaul.
Was late last night when I replied to that!
Follow DJPaul’s suggestion, jorrie!
Well, looks like WannaNetwork guy grew so fast it put him out of business!
Since our launch of the new WordPress powered platform on WannaNetwork in Early February, WannaNetwork has been growing substantially larger and larger.
With this growth also comes a few negative aspects. Running WannaNetwork as a free service is quickly becoming harder and harder when there are monthly server and maintenance costs adding up.
I just wrestled with that issue here.
A ‘members’ class was added to the body tag on pages under groups and blogs. BP_MEMBERS_SLUG or $bp->current_component are not very “precise” I guess.
I wasn’t able to figure out why this happens. I managed to get it to work, sort of, with the combination of lines in my custom function for the navigation.
