BuddyPress.org

@danbp,

Thanks. I tried inserting your suggested code into my functions.php, but it did not hide the desire fields. Also, I looked at the references in the links you provided for me to read through. Thanks for those too. However, I’m still stuck on how to resolve my problem.

Just to be clear… I think what I specifically need to figure out is how to add a filter to bp_the_profile_group_field_ids(), which apparently creates a list of the expected field names (for the specific group tab that I’m currently on) when I click “Save Changes” button on Profile Edit page. Until I can find a way to filter out my 3 desired “required” fields during the Save Changes button press, I will continue to receive the error message: “Please make sure you fill in all required fields in this profile field group before saving“.

Is there some other type of coding I can try to insert inside functions.php to resolve this?

Correction to my last post. I meant to say…

I was able to successfully hide certain profile fields from being displaying (by modifying profile-loop.php). And I was able to hide the same fields from being displayed when a user goes to edit their profile (by modifying edit.php).

NOTE: Both files are located in: /bp-templates/bp-legacy/buddypress/members/single/

I still need help figuring out how to avoid the above-mentioned “required fields” error message upon clicking the Save Changes button.

Oops… I just found a problem.

The good news is that I was able to successfully hide certain profile fields from being displaying (by modifying profile.php). That part works great. Also, I was able to hide the same fields from being displayed when a user goes to edit their profile.

However, the problem I just discovered is that if any of those fields that I’ve hidden (using the above code changes) are “required” fields, then when a user goes to the Edit Profile page, the following error message appears upon clicking the Save Changes button: “Please make sure you fill in all required fields in this profile field group before saving.”

Even though I’m certain those hidden fields have values in them, that error message appears and there’s no way to save changes.

Any solution to this?

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.

If i hide the bottom tabs and the admin bar, each user can’t modify their profile.

@bphelp. I think I have discovered the culprit to this little mystery.. I have been using the Buddypress Members Import plugin: http://www.youngtechleads.com/buddypress-members-import/

For some reason when I import my database, the plugin does not seem to process the xProfile Field visibility settings properly.. The profile fields are still listed as “Admins Only” But for some reason they are still visible to all users.

Earlier, I manually added some new test profile fields and they worked fine. I also discovered, that if I edit, and re-save a user’s profile field after import, all profile fields for that user will then revert to the proper visibility settings.

I have contacted the plugin author to make him aware of the issue, hopefully he can fix it. If you have any suggestions that might be a quick fix for this I’m all ears! 🙂

@bphelp. Upon a little further research, I wanted to note that I created a new User Profile Group, created a private field seen by Admins Only in that group, and the settings seem to be working fine in that group. In my Base (Primary) group though, all profile fields still remain visible to all users. Does the Base (Primary) group automatically force all fields visibility public by default? If so, is there way to override?

If there is no way to change the visibility in the Base (Primary), I suppose I can just put private info in the other Profile Group, but I’m curious if or how that may effect my database import..

Thanks @bphelp. Info listed below:

1. Which version of WordPress are you running?

3.5.2

2. Did you install WordPress as a directory or subdomain install?

Directory

3. If a directory install, is it in root or in a subdirectory?

root

4. Did you upgrade from a previous version of WordPress? If so, from which version?

3.5

5. Was WordPress functioning properly before installing/upgrading BuddyPress (BP)? e.g. permalinks, creating a new post, commenting.

Wordpress seems to be working fine

6. Which version of BP are you running?

1.7.2

7. Did you upgraded from a previous version of BP? If so, from which version?

1.7

8. Do you have any plugins other than BuddyPress installed and activated? If so, which ones?

Yes, a lot. 🙂

Allow Multiple Accounts
amr users + buddypress
buddypress group email subscription
buddypress member import
buddypress message attachement
Buddypress Toolbar
Buddypress Xprofile custom fields type
comprehensive google map
contact form manager
events manager pro
easy table
form lightbox
GRAND Flash Album Gallery
Lightbox Galleries EWSEL
Mass Messaging in Buddypress
Online Backup for WordPress
Peter’s Login Redirect
SHortcode Widget
User Switching
WP Full Calendar
WP Wunderground

9. Are you using the standard BuddyPress themes or customized themes?

I’m using Razor 1.1.3 from Themeforest/Parallelus

10. Have you modified the core files in any way?

No

11. Do you have any custom functions in bp-custom.php?

No

12. If running bbPress, which version? Or did your BuddyPress install come with a copy of bbPress built-in?

13. Please provide a list of any errors in your server’s log files.

14. Which company provides your hosting?

Network Solutions

15. Is your server running Windows, or if Linux; Apache, nginx or something else?

VPS hosting package

@hnla

Loving the second approach! although not as clean as the first approach, it’ll be much easier to do. jQuery show, hide and toggle could all be used to get the desired effect! i’m going to have a crack at it this weekend…

Just an FYI to anyone curious, here is the solution:

<?php do_action( 'bp_before_profile_loop_content' ); ?>

<?php if ( bp_has_profile('hide_empty_fields=0') ) : ?>

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

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

			<?php do_action( 'bp_before_profile_field_content' ); ?>

			<div class="bp-widget <?php bp_the_profile_group_slug(); ?>">

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

				<table class="profile-fields">

					<?php while ( bp_profile_fields() ) : bp_the_profile_field('hide_empty_fields=0'); ?>

						<?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 elseif ( !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; ?>

				</table>
			</div>

			<?php do_action( 'bp_after_profile_field_content' ); ?>

		<?php endif; ?>

	<?php endwhile; ?>

	<?php do_action( 'bp_profile_field_buttons' ); ?>

<?php endif; ?>

<?php do_action( 'bp_after_profile_loop_content' ); ?>

@chouf1

OK – you’re onto something… And it seems your initial hunch of PBCK was spot on – feeling foolish, but enlightened now!

SO… I had some code in my custom-functions.php file to ‘hide’ the site admin activity (see below). Because we have several users with ‘Administrator’ roles, it seems this particular user was affected. Others MAY have been if they had logged in more often…

Seems this code was not the best to use:
// Don’t record activity by the site admins or show them as recently active
function my_admin_stealth_mode(){
if ( is_site_admin() ) {
global $bp;
remove_action(‘wp_head’,’bp_core_record_activity’);
delete_user_meta($bp->loggedin_user->id, ‘last_activity’);
}
}
add_action(‘init’,’my_admin_stealth_mode’);

SO I’ve removed it in favour of THIS version, specifically masking the activity of INDIVIDUAL users with ‘Administrator’ roles, like our site admin user.

// Don’t record activity for a user or show them as recently active
function my_user_stealth_mode(){
$current_user = wp_get_current_user();
if(is_user_logged_in()) {
if(‘YourUsername’ == $current_user->user_login) {
remove_action(‘wp_head’,’bp_core_record_activity’);
delete_user_meta($current_user->ID, ‘last_activity’);
}
}
}
add_action(‘init’,’my_user_stealth_mode’);

Hope it might be of use to others in future. Thanks for responding to my post. I’m now a LOT more familiar with meta data fields as a result.

p.s. you’re right about # plugins, we do need a lot, but not ALL of those. It’s our dev environment after all. Often a case of playing with different ones to see what fits the bill.

I’m in despair for such a solution right now. So, I think it’s better to have all custom fields mandatory while members can decide whether to hide or show them in public such that they can edit any fields later if they want to. Also, re-register from front end all manually created profiles from dashboard. This is the most plausible solution to me at this time.

Thanks for your time.