Skip to:
Content

#5352 closed enhancement (fixed)

Move XProfile visibility into Settings extension

Reported by: johnjamesjacoby Owned by:
Milestone: 2.0 Priority: normal
Severity: normal Version: 1.7
Component: Component - XProfile Keywords: 2nd-opinion
Cc:

Description

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

Change History (21)

comment:1 @johnjamesjacoby14 months ago

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

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

comment:2 follow-up: @henry.wright14 months ago

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 :)

comment:3 in reply to: ↑ 2 @sooskriszta14 months ago

I second that, henry.wright

comment:4 @DJPaul14 months ago

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.

comment:5 @boonebgorges14 months ago

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]"

comment:6 @henry.wright14 months ago

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.

comment:7 follow-up: @imath14 months ago

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 ?

comment:8 @ircbot14 months ago

This ticket was mentioned in IRC in #buddypress-dev by jjj. View the logs.

comment:9 follow-up: @johnjamesjacoby13 months ago

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.

comment:10 @boonebgorges13 months ago

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?

comment:11 in reply to: ↑ 7 @johnjamesjacoby13 months ago

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.
Last edited 13 months ago by johnjamesjacoby (previous) (diff)

comment:12 @boonebgorges13 months ago

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.

comment:13 in reply to: ↑ 9 @henry.wright13 months ago

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.

Last edited 13 months ago by henry.wright (previous) (diff)

comment:14 @johnjamesjacoby13 months ago

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...)

comment:15 @ircbot12 months ago

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.

comment:16 @johnjamesjacoby12 months ago

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.

comment:17 @johnjamesjacoby12 months ago

In 8211:

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

comment:18 @johnjamesjacoby12 months ago

In 8214:

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

comment:19 @johnjamesjacoby12 months ago

In 8215:

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

comment:20 @r-a-y12 months ago

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

comment:21 @boonebgorges12 months ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.