BuddyPress.org

I love the idea of as an admin, creating a relationship between profile fields (not necessarily required ones) and groups. In fact, I was scouring around my new 1.2 install hoping this feature was already live I see it as a good way to get folks involved in their specific demographic while always having the ability to leave the group if they want.

I see this as an option when defining a group, keeping the current public/private options intact, just adding another criteria or ‘group profile rule’.

The name field was previously split into “First Name / Last Name” fields, but this is an issue for internationalization. In future versions it may be possible to apply rules to profile fields that will determine the content allowed.

That is such a silly argument. 90 percent of the civilized world uses firstname + lastname. Why make life difficult for the rest of us just because theoretically a few places in the world use only one name or three names or whatever? Why not let them hack a workaround it?

My issue with this is also not just about that field, but more about what it says about Buddypress’ priorities. If you want to register members in your company or sports club with name, address, phone number, etc. there is no easy way to do it, you’ll have to hack core files and later you’ll have to use custom functions to retrieve the data from several different tables in the database.

Also, BuddyPress will automatically synchronize profile fields with the WP profile fields. Check the function xprofile_sync_wp_profile()

No it doesn’t. Version 1.0 only added first name and last name to wp_usermeta if a user updated his account data after signup. You couldn’t count on the data to be there for every member. I had to write a custom function, based on xprofile_sync_wp_profile, to force that synchronization to happen upon registration.

Also, BuddyPress will automatically synchronize profile fields with the WP profile fields. Check the function xprofile_sync_wp_profile()

The name field was previously split into “First Name / Last Name” fields, but this is an issue for internationalization. In future versions it may be possible to apply rules to profile fields that will determine the content allowed.

To me the biggest barrier to more professional use of Buddypress is the lousy member/user management. Everything is based on username/password. There isn’t even a built-in way to get people to sign up with their real name, first name + last name. There is a required custom field for “Name”, but with the way the sign-up form is structured new users are almost encouraged to enter a garbage name – lowercase, one word anonymous nickname bs.

After lots of painful hacking in core files I now have a form with one Real name field on top. My custom code in the back splits the real name and stores it in various places in the database, so at least I have synchronized data in wp_usermeta etc. Buddypress does none of this out of the box and in general BP developers don’t seem to see this as a problem. But the one field for real name still doesn’t really force new users to enter a full two-part name.

In a previous version of my site I did have separate first name and last name fields. I NEVER had people sign up with cutesy one name names. Sure, you can create custom fields in xprofile, but synchronizing the input with all the other username, nickname, name etc. fields in the datebase and integrating them with other member management scripts businesses will have on their server requires serious database and php programming skills.

Just add the profile fields in the backend.

No worries. Glad I could help

Not exactly what I meant. There are BP profile fields (added through the backend) and then there are usermeta (which you will have to code yourself and is WP core). Stuff that’s in your profile will be displayed publicly on your profile. Usermeta can be displayed, but doesn’t have to necessarilly.

I’d give them the choice during registration, then store that value as usermeta and check for each bp-component for that value and then either display the contents of that component or a nice little reminder with a link to upgrade their account.

Not sure how well roles would work as you can have different roles in different blogs.

rfauster has the right idea.

I wanted to do the same thing as h4x3d and tried his dirty trick which works..

Anyhow here is how I did it (dunno if this is less dirty)

$platforms = xprofile_get_field_data('Plattformen');

$data = xprofile_format_profile_field('checkbox', $platforms);

echo $data;

No need for a plugin… just make your own copy of the registration template in your child theme and delete the optional fields. Or maybe even just use CSS to hide them.

I think I narrowed the problem down:

the output seems to go bust when there are more than one results.

I can query the members for different profile fields, but as soon as there are more than one hit, the function halts (cut off in html when viewing source).

with error reporting on it shows: (sorry for breaking the lines)

Notice: Undefined variable: field_filter_last_users in

/var/www/vhosts/domain.com/httpdocs/wp-content/plugins/bp-filter.php on line 150

Notice: Undefined variable: temp_array in

/var/www/vhosts/domain.com/httpdocs/wp-content/plugins/bp-filter.php on line 170

Catchable fatal error: Object of class stdClass could not be converted to string in

/var/www/vhosts/domain.com/httpdocs/wp-content/plugins/bp-filter.php on line 174

the fatal line is:

// Remove duplicate user_id's<br />

$temp_array = array_unique( $temp_array );

any clues or tipps?

YAY!! uncommenting that line fixes it!!

… but still… the selectbox issue remains, no select boxes for me with this release!

in bp-filter.php there is a line commented out in regards to selectboxes. when “activating” it,

it returns:

Fatal error: Call to undefined function bp_filter_the_profile_field_options() in /var/www/vhosts/domain.com/httpdocs/wp-content/plugins/bp-filter.php on line 257

– this function is not added yet, correctly?

now the problem is: dropdown boxes work, but when saving profiles the data is not saved when using dropdown boxes (I have to use selectboxes there). when using selectboxes with this filter, the selectboxes are not displayed!

anything I am missing?

thanks

I think to do this correctly, your loop will need a few more logic checks and error traps in the event that all of the info under a tab may be totally empty, or that some of the fields are empty and others are not. This might not be a problem if all of the fields are required, but you’ll need to modify the idea to taste. Example would be taking…

<?php if ( bp_field_has_data() ) : ?> …and displaying something if the field actually is empty. Same with <?php if ( bp_profile_group_has_fields() ) : ?>

I’d also check around the web for a lightweight JavaScript tab library, or do a quick Google for jQuery tabs and use the jQuery library that comes bundled with WP, and then follow the examples. I know there’s a few that just wrap the tabbed content in a container div and use an H3 or some other logical element as the clickable “tab.”

Otherwise the code above should be sufficient to output the profile data into tables, you just need to find the engine to make your tabs go.

For the benefit of anyone who finds this post via Google, you can view the current Roadmap here: https://buddypress.org/about/roadmap/

I figured it out, somehow:

http://paste2.org/p/546483 (dirty)

works

or maybe something with unserialize&stripslashes?

I found this in reference to the code mentioned above:

* xprofile_format_profile_field()<br />

955   *<br />

956   * Formats a profile field according to its type. [ TODO: Should really be moved to filters ]<br />

957   *<br />

958   * @package BuddyPress Core<br />

959   * @param $field_type The type of field: datebox, selectbox, textbox etc<br />

960   * @param $field_value The actual value<br />

961   * @uses bp_format_time() Formats a time value based on the WordPress date format setting<br />

962   * @return $field_value The formatted value<br />

963   */<br />

964  function xprofile_format_profile_field( $field_type, $field_value ) {<br />

965      if ( !isset($field_value) || empty( $field_value ) )<br />

966          return false;<br />

967<br />

968      $field_value = bp_unserialize_profile_field( $field_value );<br />

969<br />

970      if ( 'datebox' == $field_type ) {<br />

971          $field_value = bp_format_time( $field_value, true );<br />

972      } else {<br />

973          $content = $field_value;<br />

974          $content = apply_filters('the_content', $content);<br />

975          $field_value = str_replace(']]>', ']]>', $content);<br />

976      }<br />

977<br />

978      return stripslashes( stripslashes( $field_value ) );<br />

979  }

and this

function bp_unserialize_profile_field( $value ) {

529 }

This works great on single field entries, but for checkboxes it outputs stuff like

a:3:{i:0;s:19:”Beschaffung/Einkauf”;i:1;s:26:”Marketing & -kommunikation”;i:2;s:20:”Strategie/Innovation”;}

where as in the sidebar (random member) it comes through just fine.

How can I fix this?

thanks

the random profile data function does some magic like this:

How can I apply that to James’ code above to fix the output?

Not yet, but this is on the roadmap for probably 1.3.

There’s a plugin in the WP repository to favorite posts (https://wordpress.org/extend/plugins/wp-favorite-posts/). The favorites are stored in the database so they can be retrieved with the user id for the profile. I agree this concept should be expanded to other components (groups, blogs) in BP. I plan to create a custom post type and use this plugin (possibly modified) to show favorites of that post-type on the profile (e.g. favorite bars). For example, Tastykitchen.com could use to track favorite recipes as recipes are just posts with custom fields.

This functionality is needed and if it doesn’t exist when I get to that stage of my project, I’ll add it and shsre. The more people think of WP/BP as a CMS, the more the need for these types of functionalities becomes apparent.