BuddyPress.org

Profiles are by default public, you can also extend them by creating your own custom xprofile fields, these and any profile fields can be further modified if wished to show or hide some based on whether the displayed user is also the logged in user.

Hey @davidveldt this should do it if you are using the default theme. Otherwise you should integrate as you see fit.

theme/registration/register.php

You can add any groups or fields as you require. The groups and fields here are arbitrary.

` ‘player’, 4 => ‘coach’, 5 =>’parent’, 6 => ‘instructor’); ?>

`

Create some profile groups to cater for each role. You can find the group id within the BuddyPress admin… In the url bar or investigate your database.

You should set-up the $roles array above to match your requirements.

Within the loop you can show any fields you have created within that xprofile group. If you have a select box within that group you would add the following code as outlined in the bp-default register.php

`

<label for="”>

<select name="” id=””>

`

Finally add the following jQuery where you house any other code of similar ilk.

`
jQuery(“.role-fields”).hide();
$roles = jQuery(“#roles”);
jQuery(“#field_2”).change(function()
{
$role = jQuery(this).val().toLowerCase();
jQuery(“.role-fields”).hide();
jQuery(“#” + $role).toggle();
});
`

Here’s a pastebin for all that above. http://pastebin.com/QFdTdstz

No need for tabs or accordion this time.

Hope that helps you on the Road.

Just an example here, running with Paul Gibbs start point.

Create xprofile fields as normal.

Each career group would also have its own xprofile group.

Player would have his / her own set of fields.
Coach would have his / her own set of fields.
Parent would have his / her own set of fields.
Instructor would have his / her own set of fields.

None of the above would be required fields. (as far as BuddyPress is concerned (unless you roll some PHP codes))

You’d have another xprofile group specifically for required fields (this would be your first group).

You would make the “type” part of the required group and set it as a select box.

You could then write your registration form mark-up matching the requirements of jQuery tabs or jQuery accordion.

The “type” would be the last item on the required fields. Once that was selected you could then show or hide the corresponding jQuery ui-tab-panel that holds those form fields.

You could then on-the-fly make those fields then required using some jQuery also but a bit hacky.

Just read you don’t want to edit home.php. There isn’t a filter for privacy like there is with messages for showing profile sections. Messages and xprofile fields has logic for output and can be filtered but the actual page needs a code edit.

Tested just now, works for me.
You need to use the profile id #.

Go to your profile field setup and check the ID by putting your mouse over the “Edit” field. The ID # is field_id.
For example, “Name” is 1.

Either that or go to your DB and manually look up the profile field id in the wp_bp_xprofile_fields table.

You can also use any profile template tag and do your conditional.

If you wanted to use the profile name, use bp_get_the_profile_field_name() instead.

@thelandman, in my solution I use javascript to generate the username from the weird semi-optional xprofile fullname field, hide the username field on the form, use the email login plugin so members don’t need the username to log in, add more custom code to synchronize the fullname and the fullname-derived username to all the various similar fields in the database, etc. It’s messy, but somewhat workable.

The point is that it should not be that hard. Using full names, Firstname Lastname, should be part of the core. Seeing that none of this is fixed in 1.2+ and probably will never be fixed, I have no plans to upgrade to newer versions of Buddypress and will continue developing my version as a fork, more suited for professional and business use. If anyone is interested in working with me on that, please contact me directly.

So it works? Tag the topic as resolved.

It becomes just string manipulation. Create a new function (my_funky_function) and do something like this:

function my_funky_function() {

echo str_replace( "username","", bp_get_the_profile_group_field_ids() );

}

Then replace the bp_the_profile_group_field_ids() call in edit.php (in your child theme of course) with my_funky_function().

I think that will work but it’s not tested.

Edit:

Oh, sorry, I’m sort of wrong. This is what I get in my edit.php form in the HTML:

<input type="hidden" name="field_ids" id="field_ids" value="1,3" />

Field_id 1 is the Username for me. You just need to filter that out so the str_replace call should be “1,” instead of “username”.

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

That line is your problem. Well, more specifically, the call to bp_the_profile_group_field_ids() which creates a list of the expected field names.

Unfortunately it doesn’t have a filter so you’d have to clone and own the function into your functions.php file and manually filter out the “username” field from the string that gets generated.

Make sense?

Oh, nope, it probably means that the code is actually checking that the field ‘username’ should be getting updated. I was sort of wondering if that would happen.

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.

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.