Skip to:
Content
Pages
Categories
Search
Top
Bottom

“Only Me” Extended Profile Field Visible To All Users


  • warrencat
    Participant

    @warrencat

    In the extended profile fields, I’ve created a field that automatically pulls in data using the process described further below. This field is required and is located in the Base (Primary) group of profile fields.

    The issue I’ve run into is that I’ve configured the field to be visible to “Only Me” and have selected the option to Enforce field visibility, but when I look at the public-facing profile page, this field is still visible to any other logged in user, regardless of role. (I have confirmed this by logging in with a subscriber level account and viewing the profile page.)

    The profile fields data import process:

    I am using the NADI plugin (https://active-directory-wp.com/) to automatically create and sync users and user data from company Active Directory database. This plugin has an add-on tool that will subsequently sync selected data from the user WordPress profile over to the BuddyPress profile.

    Troubleshooting steps I’ve already completed:

    1. I’ve deactivated all plugins other than BuddyPress; the “Only Me” profile is still visible on the public-facing user profile page for any logged in user. It doesn’t appear to be caused by a plugin conflict.
    2. I’ve changed to a default WordPress bundled theme; again, the “Only Me” profile is still visible on the public-facing user profile page for any logged in user. It doesn’t appear to be caused by a theme conflict.

    WP Version: 5.2
    BP Version: 4.3.0
    NADI Plugin Version: 2.1.9 (Up to date)
    NADI Add-on Version: 1.0.4 (Up to date)

    I hope I’ve provided enough information. I’m struggling to determine why this profile field that should only be visible to the person who is logged in and no else is visible to every user. I also hope someone here might have a suggestion or recommendation for what I might try next.

    Thanks.

Viewing 11 replies - 1 through 11 (of 11 total)

  • shanebp
    Moderator

    @shanebp

    Do you have this issue for profile fields that you did create or populate with the NADI plugin?
    If not, use a database tool like phpmyadmin and check the visibility settings for that field id – those settings are in the _bp_xprofile_meta table.


    warrencat
    Participant

    @warrencat

    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.


    warrencat
    Participant

    @warrencat

    A follow-up question: Would it be possible for the Add-on plugin to take into account field visibility and include the appropriate data during the sync process?

    If so, I could work with the plugin developer to see if that is something they may be able to fix on their end, but I don’t want to ask them if it isn’t possible.


    shanebp
    Moderator

    @shanebp

    > Would it be possible …

    Yes, of course. Tell them about the _meta table. There are a few rows re visibility for each field. Have them dump out your test field so they can see the required keys and adjust accordingly.


    warrencat
    Participant

    @warrencat

    Thank you again. I’ll plan to post a follow-up after communicating with the NADI plugin development team.


    warrencat
    Participant

    @warrencat

    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.


    warrencat
    Participant

    @warrencat

    Sorry, @shanebp, I forgot to tag you in my earlier reply.


    warrencat
    Participant

    @warrencat

    Bumping for a response.

    Thanks.


    cl0ne
    Participant

    @cl0ne

    @warrencat,

    I have been hoping for a solution to this since 2017. I had to find excuses to force users to hit the save button. The issues that I’m not even importing some large user database in which this limitation becomes more problematic. I’m talking about brand new installation with new users. There is no reason that a new user should have to do this before visibility settings can be applied. It makes absolutely no sense. It’s ironic since Admins’ settings are subservient to a user’s interaction.

    And I thought this was a sensitive enough issue that it would have been resolved by now. I’m surprised that more people have not made noise. Apparently it has existed since at least 2013 (https://buddypress.org/support/topic/buddypress-x-profile-visibility-doesnt-work/)!

    Then another user brought this up prompting the creation of a ticket in the trac system which can be found here:https://buddypress.trac.wordpress.org/ticket/8093

    This ticket does provide a patch that fixes the issue for the profile details. However, in my case, a user’s last name is supposed to be private but since the last name shows up in more places than in the profile details (i.e. title tag), you are still left with a half-baked solution. But the moment you save, it works flawlessly.

    The issue is set to be fixed in version 7. Let’s pray.


    Paul Ryan
    Participant

    @figureone

    If anyone wants a filter to fix the case where a given user hasn’t edited their profile yet (and thus doesn’t have the bp_xprofile_visibility_levels user meta), resulting in all of their fields being visible:

    // Fix for BuddyPress not respecting the default xProfile field visibility
    // if a user has not yet edited their profile (and thus saving the user meta
    // <code>bp_xprofile_visibility_levels</code> for that user).
    // See: https://buddypress.org/support/topic/only-me-extended-profile-field-visible-to-all-users/
    // See: https://buddypress.trac.wordpress.org/ticket/8093
    add_filter( 'bp_xprofile_get_hidden_fields_for_user', function ( $hidden_fields, $displayed_user_id, $current_user_id ) {
    	if ( empty( $hidden_fields ) ) {
    		// Get the visibilities that should be hidden for the current user pair.
    		$hidden_field_types_for_user = bp_xprofile_get_hidden_field_types_for_user( $displayed_user_id, $current_user_id );
    		// Get the visibility defaults for all xProfile fields.
    		$default_visibility_levels = \BP_XProfile_Group::fetch_default_visibility_levels();
    		// Create the list of field IDs that should be hidden.
    		$hidden_fields = array_keys( array_filter(
    			$default_visibility_levels,
    			function ( $default_visibility_level ) use ( $hidden_field_types_for_user ) {
    				return empty( $default_visibility_level['default'] ) || in_array( $default_visibility_level['default'], $hidden_field_types_for_user, true );
    			}
    		) );
    	}
    
    	return $hidden_fields;
    }, PHP_INT_MAX, 3 );

    daveccampbell
    Participant

    @daveccampbell

    is there a way to have that function executed for every user ensuring that the profile visibility fields are set properly after a new user is imported by a 3rd party tool?

    i just don’t have much wp-programming experience – but have full access to the back-end, so could run a php program from the command-line if necessary.

    i could also come up with a list of the user_ids to run that function against, and of course would be logged in with admin access all the while.

    my alternative is to save the Extended Profile manually in the UI for 950+ users. not fun.

Viewing 11 replies - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.
Skip to toolbar