[@warrencat Participant 5 years, 6 months ago]

I’ve implemented and tested this method and it has finally succeeded in getting my member directory to sort and display by last name. I have a very basic implementation of BP and was confounded as to why the other methods that seemed to work for others would not work at all in my environment.

Thank you again for providing this, @shanebp. It seems this is a more reliable method for achieving the desired results than the other method I was seeing more often while researching solutions.

[@warrencat Participant 5 years, 6 months ago]

Thank you for providing this optional approach, @shanebp. If it exists elsewhere on the forum, I hadn’t yet found it. I’ll test with this and report back.

[@warrencat Participant 5 years, 6 months ago]

Thank you for the clarification.

[@warrencat Participant 5 years, 6 months ago]

Bumping for a response.

Thanks.

[@warrencat Participant 5 years, 7 months ago]

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

[@warrencat Participant 5 years, 7 months ago]

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 5 years, 7 months ago]

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

[@warrencat Participant 5 years, 7 months ago]

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.

[@warrencat Participant 5 years, 7 months ago]

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.