Move XProfile visibility into Settings extension

[johnjamesjacoby]

Our current iteration of XProfile visibility settings is exactly as it was shipped originally, with each individual field being followed with a hidden list of radio buttons.

I'd like to see us separate field data from field privacy, by moving the visibility into a Settings page.

I wrote a plugin that helps demonstrate how I think this should work in BuddyPress 2.0 and beyond.

​https://github.com/johnjamesjacoby/bp-xprofile-settings

[johnjamesjacoby]

For a live demo, this plugin is already enabled on BuddyPress.org.

Check it out by logging in and visiting: Settings > Profile

[henry.wright]

Settings is the logical place to look when thinking about privacy so completely love this! Can I ask if the screen name Settings > Profile is built in stone?

I was kind of thinking a very slight change to Settings > Privacy might be good. Then, plugins could add their own privacy options to the page (not sure if you already provided a hook?)

e.g. members/username/settings/privacy could look like:

Profile

General
Name
About me
etc

Extras
Company
Job
etc

Then after this 'core' set of options, you could provide a hook, similar to bp_activity_screen_notification_settings, which gives plugins the opportunity to output privacy options related to their plugin (or related to anything for that matter). Maybe hide me from search etc etc... who knows what they'll dream up :)

[sooskriszta]

I second that, henry.wright

[DJPaul]

If we go ahead with this, it's going to overlap on some of the proposed xprofile changes that I'm keen to work on (#5220) -- just noting that here so we can keep things in mind.

[boonebgorges]

Settings > Privacy makes more sense to me too. IMO, calling it "Profile" would cause confusion with the actual profile - why would profile settings not be located near my profile?

The question of whether visibility settings "belong" under Profile or Settings is an aesthetic one, and I'm happy to go with the group if everyone agrees that Settings is better. However, if we move it, I think we should have some sort of marker of such on the profile edit page. Maybe a small link at the top/bottom that says something like: "To limit who can see the parts of your profile, visit [link]"

[henry.wright]

I gave the new feature a run through on buddypress.org - and just to report - there doesn't seem to be a template notice displayed on screen letting you know your update was successful after you've clicked save.

[imath]

I agree that settings is better too. Like boonebgorges, i think a link at the bottom of the profile edit screen might be interesting.

We also must think of the case where the settings component is inactive. if active then subnav to settings component if not then a new subnav to profile ? or use the actual way of setting profile visibility ?

[johnjamesjacoby]

Eventually we could have settings pages for Groups, Friends, Blogs, Messages, Activity, etc...

Keeping "Profile" as the name makes the connection to their profile clear, where as "Privacy" leaves it up to the end user to interpret what Privacy means to them VS what Privacy means to the site -- possibly resulting in them not finding what they are looking for, I.E. "I want my entire profile hidden." or "Hide all of my group memberships."

I'd like to commit this in with "Profile" as the slug and verbiage, and revisit this if there's a strong feeling against it.

[boonebgorges]

I don't feel strongly about the "Profile" label.

How about imath's concern regarding Settings? Do we just say that the Visibility feature is only available when Settings is enabled? What about sites that are currently using Visibility but have Settings disabled? Do we enable Settings manually at upgrade? Or (and there may be a ticket for this somewhere already) do we just turn on Settings all the time? Why is it an optional component?

[johnjamesjacoby]

Replying to imath:

We also must think of the case where the settings component is inactive. if active then subnav to settings component if not then a new subnav to profile ? or use the actual way of setting profile visibility ?

Good call. Currently thinking:

• If settings is not active, no menus or navigation will be registered, and we can retain our existing behavior.
• If settings is active, register menus and navigation, and either short circuit bp_profile_get_visibility_radio_buttons() to return nothing, or edit the templates with conditional checks to bypass it.

[boonebgorges]

IMO it's a bit messy to leave both the old and new techniques in place, especially because the in-profile option requires special javascript and styling. My preference is to make Settings a required component (this is good for other reasons, I think), or maybe to require Settings whenever XProfile is enabled.

[henry.wright]

Replying to johnjamesjacoby:

Eventually we could have settings pages for Groups, Friends, Blogs, Messages, Activity, etc...

My idea did account for these - the idea was for all of them to be included on a single privacy page - akin to Facebook's monolithic privacy settings page.

e.g. the members/username/settings/privacy page could look like:

Profile
General
Name
About me
etc
Extras
Company
Job
etc

Groups
settings for groups go here

Friends
settings for friends go here

...and so on.

---

I don't think it really matters though - both approaches make sense to me.

[johnjamesjacoby]

In 7960:

First pass at Profile Settings for improved profile field visibility UX:

• Adds /members/single/settings/profile.php template to bp-legacy and bp-default.
• Introduces bp-xprofile.settings.php for Settings specific functionality going forward.
• Introduces actions & screens for handling output and saving of profile visibility data.
• Introduces _is_ function for identifying the new component/action URL.
• See #5352. (still more @todo...)

[johnjamesjacoby]

In 8210:

Profile Visibility Settings:

• Rename template functions to match existing functions (profile VS xprofile)
• Allow passing of field_id so they can be used outside of the profile field loop.
• Allow before/after in radio buttons output.
• See #5352.

[johnjamesjacoby]

In 8211:

Clean up bp-legacy styling for visibility settings. See #5352.

[johnjamesjacoby]

In 8214:

Prevent outputting visibility settings table for empty profile field groups. See #5352.

[johnjamesjacoby]

In 8215:

Improve theme compatibility of bp-legacy visibility settings select elements by forcing margin to 0. See #5352.

[r-a-y]

In 8258:

Profile Visibility Settings:

When a user is on their "Settings > Profile" screen, on form
submission, the page tries to redirect to the privacy slug, which
does not exist. (See r7960.)

This commit addresses this by using the correct slug - profile -
for the redirect.

See #5352

[boonebgorges]

Gonna mark this as fixed, as I think we've done as much as can be done for 2.0. If there are other refinements you'd like to make, let's do it against future milestones. Thanks for your work on it.