BuddyPress.org

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.

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.

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.

You would probably have to do something like:

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

//display the profile stuff in register.php

}

You should be able to just toss that check near the top of that while loop and then remember your closing brace at the bottom.

You would probably have to do something like:

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

//display the profile stuff in register.php

}

You should be able to just toss that check near the top of that while loop and then remember your closing brace at the bottom.

Basically, check your register.php main loop and only show the groups you want to show.

You’re looking for the while loop after the bp_is_active( ‘xprofile’ ) call.

Within the loop, you can filter out groups by doing a simple if check using if (bp_the_profile_group() == "group number") where group number is the number of the group you want to show.

Similar sort of idea in this thread: https://buddypress.org/forums/topic/profile-fields-questions

Basically, check your register.php main loop and only show the groups you want to show.

You’re looking for the while loop after the bp_is_active( ‘xprofile’ ) call.

Within the loop, you can filter out groups by doing a simple if check using if (bp_the_profile_group() == "group number") where group number is the number of the group you want to show.

Similar sort of idea in this thread: https://buddypress.org/forums/topic/profile-fields-questions

If someone posts this on the Ideas forum, that’ll get this flagged for a future BP release. I know John’s working on xProfile in BP 1.3, so it’ll never work again properly *hides*

All in all, here’s my approach that I use on MU/BP sites ~

1) modify the register/register.php wp-signup.php hardcoded default text and url slugs.

2) enable xprofile and require additional fields upon registration.

2) use a captcha ~ i’m fond of ReCatcha

3) make sure you and check the NO setting under “Allow blog administrators to add new users to their blog via the Users->Add New page. ” in wp-admin/wpmu-options.php “Admin > Site Options”

4) I ban or limit the registration domains (also in Admin > Site Options) so that the commonly used spammer domains are blocked from registration and then I add an email contact for owners of these addresses to manually request registration. I hide the email address from bots with HiveLogic EnKoder

5) I then firewall off entire blocks of IP’s from my servers from commonly used spammer IP ranges you can find at sources like spamhaus.org .. and considering that these are one language sites, the need for access for the IP blocks on the pan asia network or eastern europe are unlikely. If you have a multilingual site, this might cause issues to very few users. Cpanel, Plesk, BSD, etc have tools to do this.. if you’re on a shared server, ask your hosting provider if they can do it for you, and they may be likely doing it already.

6) I also recommend using Askimet.

The only thing you might want to look into is to show/hide specific xprofile fields for different groups. That’s more advanced and requires some new code to be written by someone

This is possible without too much effort, I have recently done it for a client. I considered using usermeta to indicate the type but it worked better for my client’s site to have it is an xprofile field. I wrote some code to not display or permit changes to it after registration, too.

I don’t have a solution for all your problems but assigning different “user” types to your site is easy:

– Create a xprofile field in your BuddyPress admin. For example: What kind of user are you:

a. Swimmer

b. Skater

c. Surfer

– Install the BP Member filter plugin: https://buddypress.org/forums/topic/bp-member-filter

– Users can now filter members on the member directory page to find certain usertypes

The only thing you might want to look into is to show/hide specific xprofile fields for different groups. That’s more advanced and requires some new code to be written by someone

Good luck!

edit: Maybe if you combine both tips from Boris and me you just got your solution

ps: I’m interested in the jquery profile fields stuff as well.. sounds handy!

In my opinion, the downfall of this plugin is that it uses JS to hide xprofile fields that store the lat and lon instead of just using user-meta. That and it just works a little strangely, and I couldn’t really figure out why I wasn’t comfortable with it.

I’ve got a re-engineered version of this plugin I’m using for a client at the moment, and will probably give that code back to the devs of this plugin to be reused for later.

r-a-y

There are a number of new hooks and an array object that need to be available for the privacy component to function. Although the alpha versions may work with v1.1, the full-blown version is really targeted for v1.2 and will require that as a minimum.

Concerning your wire post, for some reason, I believe that I never received that email. Strange, since I do have all my email notifications set to “Yes”.

But, to answer that specific question, your direct calls to xprofile fields should still function properly. Since you are pulling your data directly from the table and not from a templatetag function, you should be fine. Now, if you want your direct calls to be subjected to privacy control, then that is a different matter. You would then need to pull your data after the fields array has been filtered.

There is a separate table that gets installed that handles all privacy object settings. The privacy component filters the fields array that populates the profile page, removing any field-level elements that a given user chooses to hide from a given viewer category.