BuddyPress.org

Here’s that plugin I was referring to: https://buddypress.org/community/groups/bp-profile-privacy/

BP can’t fill every feature gap nor everyone’s wishes – why plugins are created. Sure this can be easily done with bypassing some of the xprofile data (or create your own fields) and hook into the wp_usermeta first/last name. (even though xprofile is syncing that data)

@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.

I use a Profile Privacy plugin created by http://www.jfarthing.com/. Sadly, the link to the plugin in my dashboard comes up 404 in the wp repositorty, and I can’t seem to find reference to it on his site. That said, the plugin allows for you to manage who can see certain fields in the profile (everyone, friends, user). When profile fields are set to “user” only the user and the site admin can view the info. Perhaps an attempt to contact jfarthing will met results. Good luck.

I would use this, cool idea.

Not sure it will be that simple you may have to loop out the whole section in other words replicate the code that the line refers to but changing the id for the newly copied code so you then had all groups being displayed.

To be honest unless there is real compelling reason for a new group of fields I would simply add the new field to the ‘Base’ group. If it’s important for registration I think it’s better added to the base group and set to ‘required’.

The problem:
multiselectboxfields cannot be saved by trying to save profile of a user.

the errror-message:
“There was a problem updating some of your profile information, please try again.”

is still present in buddypress 1.2.3 and wordpress 2.9.2

I need this function for releasing a webside !!!!!

Hi @pollyplummer. You have basically got the right idea, but there are a few problems.

First, your check for usermeta is not formatted correctly. See https://codex.wordpress.org/Function_Reference/get_usermeta for get_usermeta syntax. In any case, get_usermeta gets stuff from the wp_usermeta table, and I used it as an example in my code to give you a sense of the kind of check you’d want to do. But that’ll only work if you’re checking against a piece of data that is stored using update_usermeta. BP xprofile fields are not. If the “114” information is stored in a bp xprofile field, you will probably have to do some magic with xprofile_get_field() to get it to work. The following will check for a field called “Type” and check to see if the current user’s Type value is 114:

$field_id = xprofile_get_field_id_from_name( 'Type' );
$field = xprofile_get_field( $field_id );
$value = $field->data->value;

if ( bp_the_profile_group_name() == 'awesome' && $value == '114' ) {

There’s probably a slicker way to do this, but it works. Again, this is only relevant if you’re storing the salient data in the xprofile tables.

The second problem is that you don’t want to repeat the bp_has_profile etc stuff inside of the if statement. If you want to feed a profile_group_id argument to bp_has_profile, you should do it in the initial loop.

Then make sure that you include the markup inside of the conditional if statement. In edit.php, that means everything, including the

See a similar discussion here https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/how-to-manage-users-their-extended-profiles/

not ideal… but may help for the time being (at least get to the buddypress profile page to perform the edits)

this will add a ‘view bp’ link to the buddypress profile when viewing the user list within the dashboard
http://blog.etiviti.com/2010/02/add-a-view-buddypress-profile-link-in-wp-admin-users/

Inside of the while( bp_profile_groups() ) loop for each member, check to see if bp_the_profile_group_name() is one that should be displayed to that particular user. In other words, put the template markup inside of a big conditional:

if ( bp_the_profile_group_name() == 'awesome' && get_usermeta( $bp->loggedin_user->id, 'awesome_user' ) ) {
// Show the profile fields in the 'awesome' group only for those users with the usermeta 'awesome_user'
}


Do that for each user type and each profile field group. Only the right stuff will be displayed; groups not meeting the criteria will be hidden.

@bofw Ah, there you are. Was wondering when I’d find your username on here.

Sarah – are you trying to hide particular fields, or field groups, on the ‘edit profile’ page?

@grosbouff For the purpose of your plugin, bp_profile_group_has_fields gets in the way. The purpose of bp_profile_group_has_fields in the default theme, is that it will skip over any group of fields that have no values filled in when inside the profile loop.

I think what you want to use is bp_field_has_data().

I also don’t think that this is a bug. All of those functions are doing exactly what is expected.

Can you explain in more detail what you need these functions to do?

Without a lot of custom coding, I don’t think you’re going to be able to make this work with xprofile fields. Those fields can only store data when they have been defined in the wp_bp_xprofile_fields table, but if they’re dynamically generated, that’ll be hard to do. It might be more straightforward to save the data as usermeta.

I guess I’m assuming that you want to save the field data in the bp database tables. Or are you just hoping to display the checkboxes on the profile page, and have them handled by another script?

In either case, as long as you can add fields to the profile page (which you could do either by hardcoding or hooking to the edit screen at bp_after_profile_field_content), you should be able to grab the $_POST data after xprofile edits are saved (at xprofile_screen_edit_profile) and then do whatever you want with it.

I would like to know as well.

@stwc and everyone else.

I’ve been experiencing problems with spammers constantly, I would get about 11 a day, (at the minimum). I’ve tried several things, reCaptcha, email activation, email domain blocking, etc etc and nothing seemed to help with the bot spammers.

All they were doing was creating users with a few profile fields filled out, so there was no big issue, it was just annoying seeing so many fake users on the site.

So all I did out of the suggestions here was enter the code provided for the .htaccess file :

# BEGIN ANTISPAMBLOG REGISTRATION
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .yourbpsignupslug*
RewriteCond %{HTTP_REFERER} !.*yourhomedomain.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://die-spammers.com/ [R=301,L]
# END ANTISPAMBLOG REGISTRATION

And it seemed to have worked. For the signup slug, I used wp-signup.php. And so far, for about a day and a half now I’ve only found 1 bot spammer. Drastically reduced, but not quite fixed.

But we’ll see. I’ll post back if there is any change, or after a few days of no spammers.

I was also having this problem in clean installs of WP 2.9.2 + BP 1.2.3. I finally tracked the cause down to this: https://trac.buddypress.org/changeset/2882/trunk. Basically there’s a defect in the script that inserts the initial row into the xprofile fields table (wp_bp_xprofile_fields). A workaround (if you have SQL access) is to run these 2 statements:

ALTER TABLE wp_bp_xprofile_fields modify order_by varchar(15) not null default ”;
INSERT INTO wp_bp_xprofile_fields (id, group_id, parent_id, type, name, description, is_required, can_delete)
VALUES (1, 1, 0, ‘textbox’, ‘Name’, ”, 1, 0);

After I executed those statements, it shows my group members.
Note that the changeset also added a default for order_by, so I’m guessing that caused problems as well.