BuddyPress.org

I also just noticed that buddypress profiles don’t import from wordpress profiles or vice versa. It takes enough tooth pulling to get people to complete one profile. Adding those fields to sign up would be good because required fields would also have some anti-spam benefits.

Finally starting diving into 1.1 on my dev site and encountered a strange issue.

wpmu 2.8.4a, bbPress 1.0

just using plain default theme for now. forums work great. saved all my old posts. all seems ok BUT

on back end no option panel for profile fields. on front end all profile data is gone but name and website. Under My Profile it just has Public (no edit profile or change avatar)

Is this just a butchered install or something else?

If you use custom profile fields in your registration spammers wont effect you.I dont know why but i havent had a spam sign up since i tried this

Have a look at this Codex article.

As a general piece of advice, this is not specifically for the xprofile component, make sure that you check the codebase in the version of trunk that you’re using as there have been a number of changes to functions–some have been renamed, others deprecated, and new ones created. So it is possible that some of the Codex articles on BP loops may be slightly out of date.

I literally have to go to work after this post but:

To fix your site, rename your plugins directory to anything else i.e. ‘aardvark’. Load admin again, it should load up OK. Rename ‘aardvark’ back to plugins. You’ll have to re-activate any existing plugins. Once those have been done, try activating BP site-wide again.

BP v1.0.3 tables are:

wp_bp_activity_sitewide,wp_bp_activity_user_activity,wp_bp_activity_user_activity_cached,wp_bp_friends, wp_bp_groups,wp_bp_groups_groupmeta,wp_bp_groups_members,wp_bp_groups_wire,wp_bp_messages_messages,wp_bp_messages_noticeswp_bp_messages_recipients,wp_bp_messages_threads,wp_bp_notifications,wp_bp_user_blogs,wp_bp_user_blogs_blogmeta, wp_bp_user_blogs_comments,wp_bp_user_blogs_posts,wp_bp_xprofile_data,wp_bp_xprofile_fields,wp_bp_xprofile_groups,wp_bp_xprofile_wire,

Safe to delete as you haven’t used BP yet. Also these records in wp_sitemeta:

Any “meta_key” beginning with “bp-” i.e. bp-core-db-version, bp-friends-db-version.

If you don’t remove those meta_key records, then BP will think it’s already installed and won’t install itself again.

Before you activate BP again, open up your web server error log in a window and see if you get any specific messages when you try to run.

Also, versions of WPMU and BP you are you trying to install here will help us help you.

how do you sort??

I assume your are asking how users can view the other field groupings when they have selected “Edit Profile”. Look at the column heading. There are tabs for each field group. Clicking on a tab takes the user to that field group for editing.

You’ll have to echo that of course.

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

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