What I did is I changed the form + validation stuff inside the template files to customize my own forms and validation process.
First of all I didn’t like the default validation process that BuddyPress is using where you have to push Submit and then the script checkes if every field is filled correctly, if not it pushes a text_message into the page through an Action.
Result, often the error message shows up at the top of the page where you aren’t looking and not at the form where the problem occurs, and even more important it’s an extra page-load to get this message into the page.
I didn’t like that so I left everything of that untouched as a back-up system and simply used my own ( Zurb’s ) validation JavaScript to check while writing if the fields are correct.
Plus this JavaScript disables the Submit buttons if a form or field is not valid.
This is a screenshot of the Profile Settings page but all forms work the same so you can just diff into the template files and add alter them.
The script I use is part of Zurb’s Foundation Framework so if you don’t like to work with Frameworks like me you have to strip all the needed code out of it.
http://foundation.zurb.com/docs/components/abide.html
There are probably also scripts like this one to be found online.
[resolved] I have installed BP Xprofile Custom fields and the “nobody” option suits me.
Doesn’t sound like you need to edit xprofile fields from within the Dashboard,
but this premium plugin allows you to view, edit and save xprofile field values from a User > Edit screen in the Dashboard:
http://www.philopress.com/products/bp-dashboard-user-profile-edit/
Nice. It would also be interesting to provide this on all timestamps.
One issue ‘tho – in this:
http://docs.taptappress.com/buddypress-add-time-zone-list-profile-field/
I think you’re inserting / updating all those xprofile fields on every page load.
Why not just do it once?
You could write a plugin that uses ‘register_activation_hook’ to run bp_add_custom_timezone_list() once.
And then use the filter hook in:
bp_get_message_thread_last_post_date()
to adjust the timestamp without requiring a template change.
And you could use other hooks to adjust other timestamp displays.
That would be a popular and very handy plugin.
@macpresss
Take a look at this page to see the parameters accepted:
Profile Fields Loop
Perhaps try using profile_group_id:
By default all groups and all fields will be displayed. If you provide the ID of a profile field group, then only the fields in this group will be displayed
So it would be:
if ( bp_has_profile( 'profile_group_id=2' ) ) :
Where 2 is the ID(s) of the group you’d like to include. I think it should take a comma separated list but I haven’t tested.
This plugin: Buddypress Xprofile Custom Fields Type, had a conflicting field that I couldn’t see in my original theme. So I switched over to Twenty Twelve and the extra field popped up. So, I just deleted the (invisible) conflicting field from the profile, which allowed the Registration process to move forward.
this is great help… but how do we do this with the s2member fields when we have s2member set to integrate with buddypress profiles???
You could try looking at https://wordpress.org/plugins/buddypress-xprofile-custom-fields-type/ to see how they do it. I think one of the profile field types is ‘number’ – so that might be the best place to start.
It’s my theme and I code WordPress themes for like 5 years now but I don’t see myself as a Developer it’s more a hobby 🙂
I’m solid at HTML-CSS and can read PHP when I see it happen but I can’t write PHP it out of the box.
This error shows up when I try to hide a complete xProfile-group-ID or just an unique xProfile-field-ID from the loop.
This is what I did.
Inside: my-theme/buddypress/members/single/profile/profile-loop.php
I found the start of the loop
<?php if ( bp_has_profile() ) : ?>
....
My first thought was, maybe there are default options here to control the output of which ID’s will be visible so I started the search how the bp_has_profile() was build and looked into plugins/buddypress/bp-xprofile/bp-xprofile-template.php and found this at line 150:
....
$defaults = array(
'user_id' => bp_displayed_user_id(),
'profile_group_id' => false,
'hide_empty_groups' => true,
'hide_empty_fields' => $hide_empty_fields_default,
'fetch_fields' => true,
'fetch_field_data' => true,
'fetch_visibility_level' => $fetch_visibility_level_default,
'exclude_groups' => false, // Comma-separated list of profile field group IDs to exclude
'exclude_fields' => false // Comma-separated list of profile field IDs to exclude
);
This looks very familiar to bbPress so my first thoughts was lets try to add one of those Array’s to the loop and overwrite the default value.
Just like this.
<?php if ( bp_has_profile( array ( 'exclude_groups' => 1 ) ) ) : ?>
...
This works perfect, it hides all xProfile-fields from the first Base primary Tab (back-end). Just like I wanted it because I didn’t want all the fields to show up front-end, I’ve got a few xProfile-fields that I use for user-customization of the profile-page. Each user can add color-codes to change the default menu-color and add background-images to their profile-page to make each profile a little more unique.
Those field-ID’s are just urls or color-codes and don’t have to be visable to the public, thats why I try to hide them front-end.
This code is just a start, I did not test to see if field groups will break it but you can get an example of spitting out fields as an object array variable on profile load and then using the variable to get the values instead of requesting each time.
put this in bp-custom.php
// creates global object array from profile fields
function bp_profile_fields_array() {
global $fields;
$fields = array();
if ( bp_has_profile() ) :
while ( bp_profile_groups() ) : bp_the_profile_group();
if ( bp_profile_group_has_fields() ) :
while ( bp_profile_fields() ) : bp_the_profile_field();
if ( bp_field_has_data() ) :
$field_name = bp_get_the_profile_field_name();
$field_value = bp_get_the_profile_field_value();
$field = array(
'field_name' => $field_name,
'field_value' => $field_value,
);
$fields[] = $field;
endif;
endwhile;
endif;
endwhile;
endif;
return $fields;
}
add_action( 'bp_before_member_header', 'bp_profile_fields_array' );
// echoes value of field from object array based on param
function bp_get_single_profile_field( $param ) {
global $fields;
foreach ( $fields as $key => $val ) {
if ( $val['field_name'] === $param ) {
echo $val['field_value'];
}
}
}
Then in your member templates:
<?php bp_get_single_profile_field('PROFILE FIELD NAME'); ?>
In the profile-loop.php ( members/single/profile )
Instead of this loop.
<?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 do_action( 'bp_profile_field_item' ); ?>
<?php endwhile; ?>
I know, but what if I duplicated the code above for all 20 profile fields ?
– country
– about
– gender
– age
I would like to know how bad this would be for performance on the site, from my understanding it has something to do with Database Query’s ?
Trying to make a Tab view of the profile info, on the first tab I would like to show all general stuff and on the second tab I would like to show work info + social media options.
Hi @macpresss
What do you mean by ‘export all profile fields by a conditional tag’?
Doing what you’ve done above is good practice because if Country is an optional field and it has not been completed by the member then nothing will be outputted:
<?php if ( $data = bp_get_profile_field_data( 'field=Country ' ) ) : ?>
<!-- do something -->
<?php endif ?>
If you’re doing something with a single profile field then there is no need to loop through them all. It’s basically wasted effort and slower performance.
hi @matt-mcfarland,
i’m not a dev but consider this, to get a user ID:
$user_id = bp_get_member_user_id();
To answer the sql question, here’s a function that doesn’t exist in buddypress, which let you get the xprofile_group name by it’s ID For inspiration…
function bpfr_get_xprofile_group_id_by_name( $name = '' ) {
global $wpdb;
$bp = buddypress();
if( empty( $name ) )
return false;
return $wpdb->get_var( $wpdb->prepare( "SELECT id FROM {$bp->profile->table_name_groups} WHERE name = %s", $name ) );
}
For the output, you have to create another function containing at least:
$user_id = bp_get_member_user_id();
$xprofile_group_id = bpfr_get_xprofile_group_id_by_name( 'the groupe name' );
if( !class_exists( 'BP_XProfile_Group' ) )
return false;
$args = array(
'profile_group_id' => $xprofile_group_id,
'user_id' => $user_id,
'fetch_fields' => true,
'fetch_field_data' => true
);
May this help you !
Hi @noizeburger, glad you finally got this working. I’m sure your tutorial will be helpful to many people too. I especially like the last snippet which shows you how to disable the editing of certain fields on the edit profile screen!
Still no easy solution to this one? It’s odd that BP has been around for so long and more people aren’t having an issue with the extra profile fields not being sent upon registration.
Could for instance add dropdown boxes with categories to users extended profile pages.
Get the value of those profile fields from your home template and use it in a query.
Hi again, @henrywright-1
just wanted to let you know, that I’ve requested some help from the developer of BP Custom xprofile Fields – donmik
I asked him, if it is possible, to use a custom xprofile field (selectbox) to choose the user role and pass it over to wordpress. He gave me this function or – you can say – hint:
function custom_bp_core_signup_user($user_id) {
$user_role = strtolower(xprofile_get_field_data('NAME OF THE XPROFILE FIELD', $user_id));
switch($user_role) {
case "role 1":
$new_role = 'Contributor';
break;
case "role 2":
$new_role = 'Author';
break;
default:
case "role 3":
$new_role = 'Suscriber';
break;
}
wp_update_user(array(
'ID' => $user_id,
'role' => $new_role
));
}
add_action( 'bp_core_signup_user', 'custom_bp_core_signup_user', 10, 1);
I put this code in my bp-custom.php, but it does not work. I think there’s something missing. Maybe you have an idea, or @modemlooper?
>Wow, so basically in order for members to have access to edit all of the fields that they entered while signing up, we have to pay for a custom plugin to get access to those fields?
Let me repeat:
They are accessed on the front-end on a member’s profile page.
your-site.com/members/peteratomic/profile/
If it’s your profile or you are an admin, you will clearly see an ‘Edit’ button.
>Utterly mind-boggling why this functionality isn’t built in to BP.
It is built into BP.
> they’re totally inaccessible afterward
They are accessed on the front-end on a member’s profile page.
your-site.com/members/peteratomic/profile/
>Clicking the “your profile” link in the backend brings up a page
In the Dashboard, that link takes you to the DashBoard > User > Edit screen which is a standard WordPress screen.
If you want to view and edit BuddyPress Extended Profile fields on that screen,
then you might be interested in this premium plugin:
http://www.philopress.com/products/bp-dashboard-user-profile-edit/
P.S. I found profile-wp.php and deleted out the fields in my custom template that I don’t want to display, but they still show up. LOST.
We have a premium plugin that shows xprofile fields on the User > Edit screen in the Dashboard:
http://www.philopress.com/products/bp-dashboard-user-profile-edit/
Thanks @mercime. Am I right in thinking then, that out of the box, the normal functionality is to have buddypress extended-profile-fields, groups, and member-lists shared across the network?
I.e. if an admin deletes a group or profile-field from a child-blog, it effects the entire network?
And, there’s nothing I can do to prevent this without a third party plugin or my own hacks?
No direct way of bulk-editing profile fields; sounds dangerously powerful. If you are a PHP/WordPress developer, or know someone who is, I’d suggest writing a script to make these changes for you.
You could do this by adding a conditional check around the tr markup in the while loop that generates the field name and data while ( bp_profile_fields() ) : bp_the_profile_field();
With that check in place you would then remove the bp_the_profile_field_value() function and replace it with something like echo do_shortcode( '[myshortcode user_id=' . bp_displayed_user_id() '] );
