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

[jreeve]

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.

[jreeve]

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(){ 
		$(this).parents('.field-visibility-settings').siblings('.field-visibility-settings-toggle').children('.current-visibility-level').html($(this).parent().find('span').text()); 
	}); 
} 

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.

[boonebgorges]

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 ​https://buddypress.trac.wordpress.org/ticket/4248#comment:3

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)

[r-a-y]

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:
​https://github.com/buddypress/BP-Default/commit/07e18f96858b507ade714b65e9a5c184449f9f97

This should address the issues for 2.2.