BuddyPress.org

open bp-themes/bp-default/members/members-loop.php

instructions for what you need are line 42

This is now officially a “Potential Future BuddyPress Feature” for BP 1.4+ (ie, after BP 1.3, which looks to be essentially the WP 3.0 compatibility release). Here is the short list:

A quick blog post form via the theme. (try plugin: BuddyPress QuickPress)

Privacy controls (try plugin: bp-authz)

Global content tagging

Inappropriate content flagging

Bulk accept/reject friendship requests

Grouping of similar activity stream items

Ability to block all communication from a user

Option to receive forum post notifications via email

Message file attachments

Structured profile fields (templates for address / phone number)

Profile field specific searching (try plugin: BP Member Filter)

AJAX live updating of site wide activity stream

Well, yes, you should be able to make the username field non-editable. I would assume the username field is a “textbox” type. In edit.php, you should be able to just filter out the username field and not create a form “textbox” HTML element. So, in member/single/profile/edit.php around line 21, add in a check something like:

<?php if ( 'username' == bp_get_the_profile_field_name() ) : ?>

// Just display the Username with bp_the_profile_field_name() and add HTML to style how you want.

<?php else : ?>

// Do the existing <label... code on line 23 and 24

<?php endif; ?>

Now, a creative user might still be able to circumvent your little hack and submit their change directly to the form. I see a nonce being used though in the form so that might not be too much of a concern after all.

Great thread, Mr Maz.

For my part, I am very very leery of the phrase of the moment, ‘social networking’. It’s a buzzphrase, and even when it’s used specifically and accurately, it makes me want to punch throats, a little bit, because it doesn’t mean much when you dig right into it, and to me, it evokes cheesy cheap-suited salesman making currency of faux friendship.

But I’m kinda old skool that way.

For those of us — most, probably — who’ve been working or at least dabbling in the data for decades, we’ve seen dozens of bandwagons boarded and polluted and just as quickly disembarked and abandoned when the next thing came along. The avalanche of ‘social networking gurus’ and all the rest will fade in time, too.

For me, the real thing at the highest handwavy level is ‘community’ and more specifically, community on the web. Tools and toolsets and platforms and apps and APIs and all the loosely- and tightly-coupled stuff that enables people who share some set of interests, no matter how specific or broad, to get together and interact and form communities, with all the real-world parallels but also all the special because-it’s-on-the-internet factors rolled in.

This means a couple of things, and again, talking at a much higher level than the technical here — it means that the platform itself disappears for the user after they become accustomed to it. That it’s designed in terms of interface and functionality to not only provide the features users want, even if they don’t know it, but also to be as invisible as possible as they use it.

It also means that the platform has to have a robust set of tools for the administrator and moderators of the community (because these things are necessary, to some extent, in community on the web) to use a light hand in keeping the community on an even keel.

I think web community, more perhaps for people who are not so much of the disposable, in-the-moment, ritalin-riddled, post-it-and-forget it generation, needs to have feet solidly planted in not only the ongoing ephemeral stream of conversation, but also in a more long-term, permanent ‘space’ of shared history, shared interactions that are performed in public and can be gone back to, interactions that more than any set of xprofile fields or avatars build a mutual understanding between users based on personality and past discussion. Build, in other words, community.

This last is why I keep mentioning how important I believe the forum component of Buddypress to be, and why I’ve spent the bulk of my time on my current not-yet-launched BP site for an existing community trying to beef it up (with the help of some of the excellent plugins that people have been releasing).

‘Social networking’ doesn’t excite me. Communities of people from all over the place, communities that can only exist because they are on the internet, that’s what excites me. Buddypress, to me, is a toolset for building communities on the web. It may be a distinction without a difference for many, but I think it’s an important one.

OK, enough handwaving.

So, yes, by default, the register page only shows group 1 (the “base” group). You only retrieve one group via the profile_group_id= parameter in the bp_has_profile() call.

So, by default, this happens:

What I’m trying to accomplish is to hide groups 3 and 4 on the registration page not to overwhelm the user with a bunch of fields to fill out during sign-up, those fields can be filled out once the user has activated her/his account via “edit profile”.

There have been other threads on the forum regarding showing more than one profile group on the registration page; I found several, but take a look at https://buddypress.org/forums/topic/all-fields-for-registration. It’s probably going to be really difficult to implement unless you have a decent understanding of PHP.

Nope, I don’t think so. I was thinking you could remove the ‘profile_group_id=1’ arg from bp_has_profile but that doesn’t seem to allow the registration page to show more groups. I guess it appears that the only “required” fields for registration are the required ones in the Base group.

Might be worth opening a ticket on this one to see if that is the expect behaviour. Alternatively, ping R-a-y or DJPaul and see if they know.

No worries. The code I gave should display everything except group 3 & 4. Sorry, I think I said it backwards in the previous post.

That said, even without the code, I’m only getting group 1 showing up on the registration page so I’m not really sure what’s going on in register.php now.

Well, you should be able to create pretty much everything you need in your theme’s functions.php file.

First you need to decide at what point you want to populate the fields. Find a hook in the code to attach to by looking for do_action(‘some_action_hook_name’) calls. In your functions.php file, make a new function and call something like:

add_action('some_action_hook_name','my_nifty_auto_pop_function');

Then create your nifty_auto_pop_function that fills in the xprofile fields you want to populate.

Look in the bp-xprofile directory for all of the different files/functions to help fill in and read profile fields.

OK, now I’m scratching my head.

When I create a second group, even if I tag the fields in the second group as “required”, they don’t show up on the register page (the bp-default version). The second group only shows up on the user’s profile page where they can edit the fields. They are tagged as “required” but nothing seems to force the user to fill them out.

I’m confused now as to what you’re seeing and/or trying to do.

OK. I’m thinking you can do something like this. Find this part of the file in register.php:

<?php /***** Extra Profile Details ******/ ?>



<?php if ( bp_is_active( 'xprofile' ) ) : ?>

<div class="register-section" id="profile-details-section">



<h4><?php _e( 'Profile Details', 'buddypress' ) ?></h4>



<?php /* Use the profile field loop to render input fields for the 'base' profile field group */ ?>

<?php if ( function_exists( 'bp_has_profile' ) ) : if ( bp_has_profile( 'profile_group_id=1' ) ) : while ( bp_profile_groups() ) : bp_the_profile_group(); ?>



<?php while ( bp_profile_fields() ) : bp_the_profile_field(); ?>

At this point, add in a line like:

if( (bp_the_profile_group != "3") || (bp_the_profile_group != "4") ) :

Then go down to this part of the file:

<?php endwhile; ?>



<input type="hidden" name="signup_profile_field_ids" id="signup_profile_field_ids" value="<?php bp_the_profile_group_field_ids() ?>" />



<?php endwhile; endif; endif; ?>



</div><!-- #profile-details-section -->

Before the first endwhile line, insert this:

<?php endif; ?>

I *think* that should spit out groups 3 & 4 (assuming you have groups 3 & 4 defined in your profile groups). You might need to add in group “1” also to get the Base. The only part I’m not sure about right now is if the number need to be in double quotes or just bare. So it might be:

if( (bp_the_profile_group != 3) || (bp_the_profile_group != 4) ) :

I think.