BuddyPress.org

<?php xprofile_get_field_data( $field_name_or_id, $user_id ) ?>

A great plugin would be a profile badge widget, anyone care to write that using the template tags?

Me too! An privacy option is very important. This http://devbox.computec.de/2009/06/buddypress-xprofile-privacy-plugin/ does not work with 1.1

Edit: it does work! But user must select before. But privacy fields like birthday etc. should never be visible for guest. Maybe with an click to activate, but at the moment thats not good.

This is a little risky for a non-programmer, but here is some code that would replace the profile-loop.php file in the skeleton member theme. Note that this theme is deprecated in the new parent-child theme setup. It is also not a sophisticated privacy component like the one Jeff is working on. It simply omits everything except the base profile fieldset when a non-member views the profile.

This is from my own installation, but I have removed some pieces (mostly formatting) to simplify things a bit. I haven’t tested it in the simplified form.

It assumes that “Base” is the base profile group name you specified in the BP dashboard settings.

<?php

/*

* /profile/profile-loop.php

* This file loops through the profile field groups, and then each profile field to

* display the profile information that a user has entered.

*

* Loaded by: 'profile/index.php' (via the xprofile_get_profile() template tag)

*/

?>

<?php if ( bp_has_profile() ) : ?>



<?php while ( bp_profile_groups() ) : bp_the_profile_group(); ?>



<?php if ( (bp_get_the_profile_group_name() == "Base") || ( is_user_logged_in() ) ) : ?>

<div class="info-group">



<?php if ( bp_group_has_fields() ) : ?>



<h4><?php bp_the_profile_group_name() ?></h4>



<table class="profile-fields">

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



<?php if ( bp_field_has_data() ) : ?>



<tr<?php bp_field_css_class() ?>>

<td class="label">

<?php bp_the_profile_field_name() ?>

</td>

<td class="data">

<?php bp_the_profile_field_value() ?>

</td>

</tr>



<?php endif; ?>



<?php endwhile; ?>

</table>



<?php else : ?>



<h4><?php bp_the_profile_group_name() ?></h4>



No info yet.



<?php endif; ?>



</div>



<?php endif; ?>



<?php endwhile; ?>



<?php if ( !is_user_logged_in() ) : ?>

<p class="not-a-member">You need to log in to see full member profiles.</p>

<?php endif; ?>



<?php else: ?>



<div id="message" class="info">

<p><?php _e( 'Sorry, this person does not have a public profile.', 'buddypress' ) ?></p>

</div>



<?php endif;?>

With BuddyPress1.1, you can also recreate a custom registration page to include only the fields you specifically want them to have on sign-up, put it in your child theme, and let it do the dirty work.

Just don’t put the fields in the “base/first” profile field group. Only the fields in that group will show on the signup page.

In BP1.1 it would be easiest to make a custom theme file to do this inside the member-loop.php. You could check the field name and if it = the name of your field, then you can grab the next field, format it the way you want, and continue.

What BP version are you using?

That would be wp_users, but isn’t that ID used as a key (?) elsewhere in the database? Would it get “altered” automatically throughout the system?

No, in WPMU DBs, changing the auto increment field, or any other linked field, does not automatically propagate the changes throughout. The technical term for what you are referring to is referential integrity, with the specific subset of that called cascading changes.

With the MySQL engine, cascading changes (update or delete) throughout the DB only can occur if the tables in the DB have been set up as type InnoDB and the appropriate foreign keys applied. WPMU’s tables are set up as type MyISAM. Before assuming that this was/is a bad choice, when it comes to MySQL, there are pros and cons with each table type. A conscious decision went into selecting MyISAM table types for WPMU’s DB.

Now, with regards to the specific issue you are facing:

Although all the tables in WPMU’s DB have an ID field that is set to auto_increment, the ID field in wp_users is used to assign a unique ID to each registered member of your site. That ID field ties into the other tables in the DB, where necessary, by mapping to an appropriate field–but not to the auto incremented ID field of the other tables.

So, for example, the wp_user ID field forms a relationship in the wp_bp_friends table in two places–with the initiator_user_id and friend_user_id fields. Or as a specific example, wp_user ID field = 7 would form a relationship with the field in wp_bp_xprofile_data where the value of its user_id field equaled 7.

You are on the verge of potentially causing a very big, possibly fatal problem for your MySQL DB. Before doing anything, back up your DB and be prepared for the very-real possibility that you are going to alter the table relationships (break them) to such a point that your DB will not function anymore. You will then have to delete all the data in the DB tables and then restore the data from your backup.

You might even find yourself in the position of having to actually delete the entire DB and creating a new one from scratch. You’ will then need to restore from the back up. So you should also make sure you have a copy of the DB settings in WPMU’s wp-config.php file as you will have to recreate the new DB exactly to match the settings found in that configuration file.

What you need to do depends on what name is in question. Is it the member’s first, last, or nick name? Is it their full name which is displayed in the profile pane of BuddyPress? The data for those names are stored in two different places.

Also I editted his name from admin dashboard, but the name does not change? Is this a bug?

Since usernames (login names) cannot be changed, you must have tried changing either the first, last, or nick name. Did the questionable name even appear in any of those fields? Did you also select the newly-changed name in the “Display name publicly as” drop down list?

But, based on what you are saying here, I assume that the questionable name is the member’s BuddyPress full name. This can only be changed in the profile pane by the user. Currently the only recourse a Site Admin has is to go into MySQL’s backend and find the questionable field in the wp_bp_xprofile_data table.

Make sure that whatever changes you made to the user’s name in WPMU’s backend, you make in this table as well.

Just to give you a little more background into what is happening:

• When a user updates (changes) their name in the Full Name field in the BuddyPress profile pane, the changes do propagate throughout the MySQL DB. The datum in the following tables are properly updated: wp_bp_xprofile_data, wp_users, and wp_usermeta
• But, if you make changes to a user’s nickname field in WPMU’s backend, the changes are written to wp_usermeta only for that field. The changes are not written to the wp_bp_xprofile_data or wp_users table. You can have the changes written to the wp_users table if you select the proper value from the “Display name publicly as” drop down list. But, they are never written to the corresponding BuddyPress table.
• Finally, and this is even more confusing, changes to the nickname field are not written to the first name or last name meta values in the wp_usermeta table. Conversly, if you change the first name and/or last name fields, they are not combined and also written to the nickname field in wp_usermeta

So, there could be improvements in the way WPMU handles user name changes. But, it is a WPMU issue since changes at the Site Admin level in the backend are controlled by WPMU and not BuddyPress.

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.

This used to be possible with CSV files, but the code was old and not that great so I’ve removed it for now.

There’s plugin that helps users to join certain groups on signup. But not based on profile fields.