Skip to:

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#5896 closed defect (bug) (fixed)

xprofile field visibility label doesn't change until after saving changes

Reported by: jreeve's profile jreeve Owned by:
Milestone: 2.2 Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords:
Cc: jon.reeve@…


The xprofile field visibility controls say: This field can be seen by: Everyone [Change]. Clicking "change" makes radio buttons visible that allow the user to select "Only Me," "Only Members," etc. But after the user selects a different visibility setting, and then clicks "close," the visibility label hasn't changed to reflect this new setting--it still has the old value, in this case, "Everyone." This leaves the user wondering whether his edit has taken effect.

A solution would be to write some jQuery that changes this value according to the value of the radio button.

Change History (4)

#1 @jreeve
9 years ago

  • Cc jon.reeve@… added

#2 @jreeve
9 years ago

You can fix this with the following jQuery code:

function update_visibility_fields() { 
	/* jQuery hack to make visibility label change
	 * when the user changes it */ 

	$('.field-visibility-settings input[type=radio]').click(function(){ 

I'll submit a patch for this if I can get it to enqueue properly and load when profiles are being viewed.

Also, I'm no expert at jQuery, so if anyone has suggestions for improving this code, please let me know.

#3 @boonebgorges
9 years ago

  • Component changed from Core to XProfile
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 2.2

Marked #4248 as a duplicate, since this one has code attached to it.

One UX consideration here is that by changing the text, we may be suggesting that the change has actually been saved. We need to make sure that we're displaying a browser warning when a user changes a visibility setting and then attempts to leave the page without hitting Save. See

Your patch looks like it'll work, but I would like to make the following suggestions:

  • Too much DOM traversing (parents() and siblings()) that makes it difficult to modify this markup in the future. If you must traverse, use closest() and find().
  • I think it would be a bit more straightforward and flexible if we added the visibility level strings to wp_localize_script(), and then fetched them from that JS variable to replace the text.
  • No need to enqueue a separate file - put this wherever the existing JS for visibility stuff is located (probably in bp-templates/bp-legacy/js/buddypress.js)

#4 @r-a-y
8 years ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from new to closed

Duplicate of #4958. This was fixed in bp-legacy in that ticket.

I've just ported over the latest JS that deals with xprofile visibility from bp-legacy to bp-default here:

This should address the issues for 2.2.

Last edited 8 years ago by r-a-y (previous) (diff)
Note: See TracTickets for help on using tickets.