The home theme is just a theme, you’re free to do anything you want with it.
I made the above changes and the center column is gone. It has left an empty space, however, the right column did not take up that empty space. Since the above recommendation is a bit dated, are there any additional changes to be made if running RC-1? Thanks. Maybe a future BP version will allow the admin to choose between two or three columns.
Oh. “site admin”, you must be using Tarski theme or have the meta widget running in your theme. I thought you were talking about “site admin” in the mu backend.
Do you get an error msg saying “Invalid group slug: ‘your-group-slug'”?
I’m going to repost my BuddyPress on this page if no one minds…
http://delsolownersclub.com
It’s now a fully integrated BuddyPress/bbPress install, with a bbPress theme to match the Member Theme style layout that BP has become popular for.
I invite any/all of you to join as well (maybe don’t create a blog if you don’t need one) if you’d like to check it out and give it a test drive.
I’ve had his same problem before when i first installed a new theme bp home. I changed the front page displays a the readings settings to show a static page and i worked. Now i doesn’. say does that setting in any way affect the display of pages?
just my 2c 
I’m using http://www.slicehost.com for some of the wpmu/buddypress sites I’m building now. I’ve started with a 256MB slice, and will/can expand when needed to a larger/more slice(s). My configuration is/will be:
– nginx instead of apache (implemented)
– eAccellerator (implemented)
– Multi-DB from premium.wpmudev.org (implemented soon, 256 DBs)
– WP-SuperCache or WP-SuperCache-Plus (not sure which one yet)
– offload themes to S3 (maybe)
I think the main css elements are based here:
/member-themes/buddypress-member/css/base.css
As far as I can see these can be changed in
member-themes > buddypress-member > header.php
Search for id=”nav” around line 39
Would be good to have a language file for these elements.
BP is about inspiring community interactions, so it looks like it’s doing its jorb.
No problem; I should have been more clear with my question anyway. I don’t have all that much experience with open source, but I can certainly understand being defensive about software that you’re very involved in.
For the record, this is the first time I’ve actually participated in development forums for any software I’ve developed for. Most of the time I just lurk and hope my questions get asked by someone else. It speaks very highly of BP that installing it spurred me to actually make an account here and start posting questions and whatnot.
I think the idea is not to have BuddyPress permanently alter the WordPress related data. Right now, and please correct me if I’m wrong, but past of the design and development process of BuddyPress is that it can be added and removed without any changes done to the WPMU data structure, apart from conveniences like changing a password, etc…
You can rename the “Full Name” in the BuddyPress to say “Nick Name” or “Display Name” or whatever you’d like, and then code your themes to use that info if you so choose…
To be honest, from a developers standpoint, I like how it is right now, as it allows me to keep things separate. If you’d like to open up the ability to modify the fullname, then really BuddyPress should be able to modify ALL of the original WordPress user info exactly like the profile admin panel does, with website, info, firstname, lastname, etc…
Andy keeps telling me that any WP theme can be converted to a member theme.
It can. The member theme is like a normal WP theme but with added functionality. Because of the nature of the themes I run on my site, I decided to customize the member theme rather than trying to convert my WP theme into a member theme, but the principle is the same.
I’m going to check out the the bp_styles() function mentioned in the readme.txt. It seems like as good a place to start as any. Thanks for the tip
Andy keeps insisting that it’s not a big problem.
That what’s not a big problem?
tekanji, sorry if my response to you was kinda abrupt. I get ‘tech support cranky’ some times. Ask me ‘how’ and I might be able to help. Ask me ‘why’ and I get defensive even though I didn’t write this software.
The plugin-template.php file does exist in the member theme. I don’t know of anyone who has tried such a thing. The member theme has a header and footer file. Andy keeps telling me that any WP theme can be converted to a member theme. There may be some guidelines that you might find useful in the /wp-content/member-themes/member-themes-readme.txt.
Andy keeps insisting that it’s not a big problem. I keep saying ‘uh huh’ and ignoring him. Andy is usually right.
Ah, I was trying to ask if there is there something about the code that makes it impossible to implement the redirect I was talking about. I am definitely interested trying to code an enhancement, but I’m new to BP (just installed it a few nights ago) and, while I’ve coded a few WP plugins for personal use, there’s a lot about coding plugins/hacks/etc that I don’t yet know.
In other words, I’m trying to figure out 1) if coding a redirect (or other function) is within my current coding capabilities, and 2) if so, where to start.
Sorry for being such a newb 
I’m with DJPaul; I would like to see BP’s proprietary fullname field deprecated and have WP’s native fields be used instead.
Not only would it allow for more customizability/adaptability of BP themes, plugins, etc but it would also get rid of an extra field that, as far as I can tell anyway, can be handled just as well with WP’s first_name and last_name fields.
I agree that we should put this suggestion into a trac ticket.
You are asking in a support forum why design decisions were made and why, considering the evolutionary nature of software, bp ended up as it did. As an end user of bp I have absolutely no idea how to answer either of those questions.
The real answer is that things don’t have to be like they are if you don’t want them to be. Come up with an enhancement and share it with us. That’s the beauty of open source under a GPL license.
Code is Freedom.
I’m not sure why the member directory and blog directory have to be handled as part of the standard WP theme instead of the members theme?
The member theme is not a standard WP theme it can’t be used as such. It puts up the error message because it’s required.
Unfortunately, that doesn’t actually make a big difference in my case; the main problem I have is that the header and footer files between the two themes are vastly different. The two main problems are that 1) one of my themes is fixed width at a size smaller than the minimum size for the BuddyPress themes (which breaks the layout) and 2) they don’t have the header with “Home”, “Blog”, etc. which I don’t want on my main site, but *do* want on the members directory and blogs directory.
I was thinking about it, though; the member-theme actually has plugin-template.php although it doesn’t appear to be used. Is there some particular reason why if a blog theme doesn’t have that file it puts up an error message instead of redirecting to the member-theme file?
Small mistake on my side… The member-theme folder was empty.
Nope. Sorry. The directories all have their own css you can skin. bp has a site-wide.css file you can drop into your theme in /themes/<your theme>/css/site-wide.css
In bp-core-cssjs.php which fires up the css and js for bp is this fn:
function bp_core_add_css() {
// Enable a sitewide CSS file that will apply styles to both the home blog theme
// and the member theme.
if ( file_exists( WP_CONTENT_DIR . ‘/themes/’ . get_blog_option( 1, ‘stylesheet’ ) . ‘/css/site-wide.css’ ) )
wp_enqueue_style( ‘site-wide-styles’, WP_CONTENT_URL . ‘/themes/’ . get_blog_option( 1, ‘stylesheet’ ) . ‘/css/site-wide.css’ );
wp_print_styles();
}
add_action( ‘wp_head’, ‘bp_core_add_css’ );
Well, personally I consider the member and blog directories to belong to the same “type” of page as the profile and other pages that use the member theme.
But, more to the point, the problem I’m having is that plugin-template.php relies heavily on proprietary BuddyPress functions which makes it hard to integrate into themes with layouts that are different than the basic BuddyPress layout. Since the member theme is designed specifically for BuddyPress I figured it would be easier to have the pages that use the plugin-template.php use that theme rather than writing code that changes the way the blog themes display just for that one page.
I mean, it should be possible to have the “members” and “blogs” directories use the members theme rather than the main theme since “members/username” uses the member theme. I was hoping that there would be an easy way to do it (like bp_get_member_header() or something like that). Oh well.
OK people this seems to work. This requires modifying the member theme since I didn’t find any actions in bp to hook this into so here goes:
In the member theme the file:
/buddypress-member/blogs/create.php
There is this chunk of code:
<?php if ( bp_blog_signup_enabled() ) : ?>
..(some other stuff here)..
<?php else: ?>
<div id=”message” class=”info”>
<p><?php _e( ‘Blog registration is currently disabled’, ‘buddypress’ ); ?></p>
</div>
<?php endif; ?>
Replace the ..(some other stuff here).. with this:
<?php
global $bp;
$blogs = bp_blogs_get_blogs_for_user($bp->loggedin_user->id);
if (!$blogs)
{
bp_show_blog_signup_form();
}
else
{
?>
<div id=”message” class=”info”>
<p><?php _e( ‘Limit one Blog per member’, ‘buddypress’ ); ?></p>
</div>
<?php
}
?>
This is the entire little create.php file in pastie: http://pastie.org/396083
This was a: “quick ya we should have that and I’ve got to get to the store and get some boxes because I’m moving from Michigan where we have a snow storm today and Virginia where I’m moving to comes to a screeching halt when they get 1″ of snow and I gotta run now” solution.
When I get back from the store I’ll help clean up the damage this might cause. This does work for me in a quick test.
