BuddyPress.org

Another side note from Andy’s last paragraph, these BuddyPress extensions could come in just about any form; additional theme files to be added as a “plus pack” (remember those?!) or a plugin to override and replace existing files as a child theme, or included in the next version of the theme itself.

Also, if you’re paying attention the directory of the included parent theme is “bp-sn-parent.” It stands for “BuddyPress Social Network Parent” which insinuates that theme authors are encouraged to create their own parent themes for something other than social networking, and opens the door for other parent theme sets to be included in the core if they’re rad enough.

Say someone makes a sweet micro-blogging theme ala Twitter, that gives us “bp-mb-parent” to let you switch between totally different setups. Or say someone switches the emphasis away from blogs and users and shifts it to the discussion or support forums; that gives us “bp-df-parent” and “bp-sf-parent”

Andy’s right too. The majority of people so far interested in BuddyPress have been people that are also first being introduced to WPMU and starting a social network. Very few support questions come through asking how to port this existing theme to fit BuddyPress. The ones that do are typically answered by the theme author or the person is so devoted to making it work, that they convert the theme themselves.

I’m really not sure how much harder it is for existing themes to use BuddyPress; it’s just different, but in a better way in my opinion.

The situation can be summed up like this:

The BuddyPress 1.0 theme structure made it easy for existing WordPress sites to use BuddyPress out of the box (but only with the default theme which was never ideal). However, it made life very difficult for anyone designing a site from scratch with BuddyPress, and for 3rd party theme designers.

BuddyPress 1.1 makes it harder (but still very possible) for existing WordPress sites and themes to use BuddyPress, but makes it very easy for sites starting fresh and for 3rd party theme designers.

The number of people starting sites fresh using BuddyPress significantly outweighs the number of people trying to use BuddyPress within an existing WordPress setup. It is only logical to make the lives of the majority easier.

There will be more documentation on using BuddyPress with existing WordPress installations and themes once 1.1 is released. Let’s get it out there first.

On a side note – I’d really love to see existing WordPress theme designers coming out with BuddyPress theme extensions for their WordPress themes. This for me is the ideal scenario, let the top theme designers provide support for BuddyPress, rather than the end users trying to force a square peg in a round hole.

@crocgo

As I said above, we do not have the information necessary to help you. Please answer the questions DJPaul linked to.

I’d like to delve into this more deeply, but for now, even using the child themes there is an additional complication. It’s reasonable to expect someone to be integrating BP with an extant site using an advanced WP theme, and simply setting this theme to be a child of the bp-sn-framework doesn’t suffice. I’m working in one such setup, where a theme uses several include() statements in a functions.php file, and setting this as a child of the BP framework b0rks the whole deal. Now, I know what to do here, at least in the simplest case: just amend the functions.php calls. That won’t necessarily persist as the theme is updated, so maybe, instead, this can be done via a plugin.

The point here is that there are easily found examples where existing WordPress installations aren’t set up to so trivially extend to include BP. This one has a straightforward solution, but some will not. And as WP theme developers continue to do ever-more-amazing things with WordPress, and as you and other developers continue to make WordPress and BuddyPress more powerful, this sort of nonlinear theme infrastructure will likely become the norm. I don’t think these are quite edge cases, either; the theme I’m testing with is a free Woo theme, so not quite off the beaten path.

I don’t want to add to the confusion. Rather, I wonder if I could help flesh out some use cases, which might later get wrapped into the documentation (if it’s helpful). For instance, there is the site that purports only to offer social networking, without long-form blogging intentions. In that case, Using bp-default with customizations is pretty straightforward–well, as straightforward as the styling for the site needs to be.

However, for folks who have an existing WP site to which the BP functionality will be at most equal in priority, their branding and existing structure may be complicated enough that simply setting their existing theme to be a child of the BP framework doesn’t work by itself (styling issues aside–there will always need to be style adjustments; this is about structure and objects). Again, as my example demonstrates, this complexity is closer to the norm than some might expect, especially among the crowd using WPMu and extending it with BP. In this case, there’s more to document.

I don’t intend to suggest, as some have, that BP developers need to rethink or revise BP’s scope and structure. That’ll probably happen anyway, as things start merging more, but it’s not necessary. I only mean that the adaptation of BP to an extant site is a nontrivial use case, and while there is forthcoming documentation as to how best to manage this, maybe the forum users and devs can spec out some general use cases and work on how best to develop their solutions.

catinw12, you shouldn’t need to create any new profiles anywhere. All of the .org sites should provide you a unified login/password combo to use on wordpress.org, bbpress.org, buddypress.org, and all of their respective trac’s.

I have no idea what will work for you. I was just detailing what I needed to do.

If your WPMU and server environment were setup properly to begin with, and you followed the instructions in BuddyPress’ readme.txt file, you should have no issues upgrading. But, for me, I had unknown issues in my original setup environment that caused problems. So, I had to go through the process I tried. It may or may not work for you.

To do a clean WPMu reinstall, you will want to delete the WPMU install completely–this means everything including the folders. Once reinstalled, you can go grab the most recent BP trunk and manually install before reactivating it.

Okay, so everything is standard issue.

I had a similar problem when I upgraded one of my development sites to pre1.1. I ended up reinstalling from scratch–both WPMU 2.8.4a and BP trunk. I did a clean install–sort of. First, I deactivated BuddyPress since I planned on using the same DB.

Then I dragged my wp-config.php and .htaccess files out of the root directory before deleting everything else in the root directory. I reinstalled WPMU just by copying the files back into the empty root. I then put back the wp-config and .htaccess files, logged into WPMU as Site Admin, and reactivated BP and reselected the BP themes.

My problem went away.

By the way, if you are running WPMU in a development environment and you selected the subdomain install option for blogs, you will have an issue if you have not set up a wildcard DNS record and have more than the main blog. I had this issue with one of my dev sites.

What happened was that it threw an error when I upgraded Mu form 2.7.1 to 2.8.4a. It could not properly upgrade any of the test blogs (other than Blog ID 1) since it could not resolve the subdomains. I had not set up a wildcard record for that dev site.

Which version of BuddyPress are you using?

In the trunk, you’d be best to use…

function xprofile_get_field_data( $field, $user_id )

…to get what you’re after.

Used like…

$retval = xprofile_get_field_data( 'Address', $bp->loggedin_user->id );

That would return the value of the field “Address” for the currently logged in user.

When logged in to WPMU’s back end as Site Admin and visiting “Appearance > Themes”, the description under the BuddyPress Default 1.1-pre theme should say:

The template files are located in /themes/bp-sn-parent. The stylesheet files are located in /themes/bp-default. BuddyPress Default uses templates from BuddyPress Social Network Theme Framework. Changes made to the templates will affect both themes.

If you are seeing something different, you need to carefully look at how you’ve installed your themes.

You’ve got a nice custom theme. What you need to do is copy/merge the contents of the standard BuddyPress theme functions.php into that of the theme you are using.

If this has already been done, check your htaccess/mod_rewrite is enabled.

1 in 10 or 20 times, this forum generates blank pages when I visit. Something wasn’t happening before.

As per https://trac.buddypress.org/changeset/1843/, you need to re-activate the theme. Also you will probably need to go in and remove the themes/bp-sn-framework/ directly manually.

Shooting of one in the dark, but try deleting the bp-themes folder from the buddypress directory now that you’ve moved the themes over.

When you say “naked” you mean the stylesheet is not loaded?

Just working on a clean install of BP, and tried activating bp-events, running trunk. I get the following error a couple of times on different lines:

Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of do_action(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in /wp-content/plugins/bp-events/bp-events.php on line 2221

and also Failed opening required ‘/wp-content/plugins/bp-events/bp-events-cssjs.php’ (include_path=’.:/usr/local/php5/lib/php:/usr/local/lib/php’) in /wp-content/plugins/bp-events2/bp-events.php on line 21

@matthijsv You could look at how WP constructs the calendar, ie how it populates it with posts, and work from that.

I’m testing r1865, and it conflicts with /wp-admin/ pages causing options to go blank or only displays footer.

Questions/suggestions:

• So, you are having display issues with one (or all) of the admin pages in WPMU’s backend?
• What version of WPMU are you running? You need to be running WPMU 2.8.4a.
• How did you upgrade BuddyPress? Since you are running trunk, I assume that you manually installed it. Or, did you do an SVN up?
• If you manually reinstalled trunk, meaning you grabbed the zipped version, did you first deactivate BuddyPress before reinstalling? Did you delete the BuddyPress directory and do a clean install?
• Have you tried disabling all your active plugins and seeing if the page displays as it should?
• If the above solves the issue, then reactivate BuddyPress and see if the issue returns. If it does not, then it has nothing to do with BuddyPress and is more than likely a conflict with one of your other plugins. Make sure all your plugins are updated to run WPMU 2.8.4a.

You need to modify the output of the User Posts and User Comments loop. The documentation for doing that can be found here:

Custom BuddyPress Loops

And what you’re specifically looking for can be found here:

• The User Blog Posts Loop
• The User Comments Loop

I assume that you are running on the bleeding edge, that you reinstalled the most recent BuddyPress trunk. The name of the parent theme was changed in r1843 and many new improvements made to the overall new parent/child theme architecture.

As the above referenced changeset indicates, the first step you should try is reactivating your theme. If that does not do the trick, then since you’re using a customized parent/child theme, you need to make sure that you carefully inspect the new default parent/child theme and find were any changes might have been made.