BuddyPress.org

Hello! Thank you!! Now I am working with another server and now if I see the registration page without problems

What I want to do is the following: I want on my page that the moment a new user registers, it is entered in the fields that in the simple selection questions: A and B (which are profile field of Buddypress), if the person has more than 50% of questions A or questions B, this user will be of a specific type or group (for example: Group A or Group B)

I finally have a follow up on this issue.

I’ve been in touch with the NADI Plugin Developer about the “Only Me” fields being visible to anyone viewing a user’s profile page. After explaining the issue and providing some of our user data to them, this was their reply:

The source of this issue resides in buddypress/bp-xprofile/bp-xprofile-functions.php :: bp_xprofile_get_fields_by_visibility_levels(): If the user or administrator has not explicitly saved a profile, the wp_usermeta attribute “bp_xprofile_visibility_levels” is empty. This is the case after a NADI import of a new or already existing user happens.

With the attribute ‘bp_xprofile_visibility_levels‘ being empty, the default visibility an administrator has configured won’t get applied.

These are my argument why BuddyPress should apply the attached fix:

1. From a developer point of view, it is not intuitive that the default visibility settings are not applied if the user’s profile has not been previously saved.
2. From an administrator’s point of view, the current solution allocates unnecessary hard disk space. My integration database contains 10.000 user, which is a realistic user base size for the NADI plug-in. Alone for the unnecessary default visibility settings around 4 Mbyte have to be allocated. To be fair, NADI also uses duplicate data to work with BuddyPress.

From my point of view as a NADI developer:

1. Importing 10.000 users already takes a long time. Explicitly calling BuddyPress’ save methods would result in additional SQL queries which I would like to avoid
2. bp_xprofile_get_fields_by_visibility_levels is not a hook, so I can’t apply the patch in our plug-in

They are recommending this issue be addressed in the core BuddyPress files, specifically in the bp-xprofile-functions.php file. They provided me with a file containing proposed code changes, though this modified file with an attempt to fix did not specifically for me in my environment. I’m not sure how to provide it to you for your consideration/review since there is no attachment facility on this forum.

Got it sorted.

I set up a new search-form.php in my child theme:

<div class="<?php bp_nouveau_search_container_class(); ?> bp-search" data-bp-search="<?php bp_nouveau_search_object_data_attr() ;?>">
<form action="" method="get" class="bp-dir-search-form" id="<?php bp_nouveau_search_selector_id( 'search-form' ); ?>">
<select onchange="this.form.submit()" id="<?php bp_nouveau_search_selector_id( 'search' ); ?>" name="<?php bp_nouveau_search_selector_name(); ?>">
		  <option value="" disabled selected>Filter by Industry</option>
		  <option value="">All</option>
  <?php  $result = $wpdb->get_results ( "SELECT * FROM wp_bp_xprofile_fields WHERE id='2'" );
  foreach ( $result as $print );
  $options = $wpdb->get_results ( "SELECT * FROM wp_bp_xprofile_fields WHERE parent_id='$print->id'" );
      foreach ( $options as $option )   { ;?>
    	
    <option class="<?php echo $option->name;?>" name ="field_<?php echo $print->id;?>_match_any[]"value="<?php echo $option->name;?>"><?php echo $option->name;?></option>
          <?php } ;?> 
		</select>
</form>
</div>

And then Ravi over at BuddyDev figured out how to change what the search applies to:

// Activity Search by Category

function buddydev_filter_activities_query_args( $r ) {

	$searched_category = empty( $r[ 'search_terms' ] ) ? false : $r[ 'search_terms' ];

	if ( ! $searched_category ) {
		return $r;
	}

	$r['search_terms'] = false;

	if ( empty( $r['meta_query'] ) ) {
		$r['meta_query'] = array(
			array(
				'key'     => 'bpcat',
				'value'   => $searched_category,
			)
		);
	} else {
		array_push( $r['meta_query'], array(
			'key'     => 'bpcat',
			'value'   => $searched_category,
		) );
	}

	return $r;
}
add_filter( 'bp_after_has_activities_parse_args', 'buddydev_filter_activities_query_args' );

Thank you for the suggestion. Here is what I did, as well as the results.

All of the current extended profile fields were data being synced using the NADI add-on. I created a new text field to test with in the Base (Primary) field group and configured it the same: Required, “Only Me” visibility and Enforce field visibility selected. I edited an existing user profile, added some text to this new field and saved the profile.

I viewed the profile as an admin and could see both fields – the original and the new test field – that should be hidden. All good there. I switched to a subscriber account and reloaded the profile and both the original and new test fields no longer displayed.

This leads me to think there is an issue with the process of adding data to the extended BuddyPress profile fields using a sync process that somehow ignores the Field Visibility element, but that is corrected when the profile is manually updated.

Regarding PHPMyAdmin, this site is installed on an internal company server and, as such, I don’t have PHPMyAdmin or any similar tool at my disposal to be able to easily look in on the database tables, unfortunately. But knowing which table has this data in it will be helpful as I work with my IT support on any further analysis/diagnosis.

Thanks again. I’ll try that.

I’ve been making some progress and getting closer. Created a new template with a copy of the member directory code, then started manipulating that.

Tried using what’s in the “Filtering by Xprofile fields” section here to guide me:
https://codex.buddypress.org/developer/loops-reference/the-members-loop/

Right now I have a few errors, but I also see a link to just the one member that has a blog field filled in. (Long way to go, but feels like I’m getting to the right track.)