Give visual feedback to the user when altering xProfile visibility values

[msteimann]

Hello team,

On the user's profile page, the sub navigation under the Profile tab lets the user alter the visibility settings of his extended (details) profile. The xProfile fields do change to the desired visibility settings, but only AFTER the user clicks the SAVE SETTINGS button.

The user might get confused (at least I was confused) by the fact that BEFORE you hit the save button there is a misleading visual feedback (the visibility term does not alter to the according setting the user has just changed it to, it still displays the same value as before).

Could this please be changed to a more friendly user experience in a future version?

Regards,
Martin

[boonebgorges]

Hi @msteimann - Thanks for the detailed report.

Since [7152], the visible text here ("Dieses Feld ist...") *has* changed when closing the visibility settings. See #4958. It's possible that you are using a theme that doesn't support this feature. Can you give details about your theme?

[msteimann]

Hello @boonebgorges,

Thank you for letting me know! I have now read #4958 and those two described issues exactly match – I lose the registration settings too if a field reports a failure.

I'm using the KLEO theme, of which the developers state it is perfectly designed to work with BuddyPress. Should I alert the developers? Should I try the #4958 patches?

Regards,
Martin

[boonebgorges]

I just tested locally with an old version of Kleo (3.0.10), and the functionality works as expect. In other words, the text DOES update when clicking "close".

So, it seems as if there's something specific about your installation that's causing the problem. A few things to check:

1. It's possible (though I'm unsure how) that this is a problem that arises only on non-English installations. I don't speak German but I did check with a French translation, and I was not able to reproduce your problem.

2. It's possible that there's a JavaScript error elsewhere on the page causing this problem to occur. Please open your JavaScript console and see if any errors are listed.

[msteimann]

Thanks for testing. I recently did a test by disabling all other plugins and even changing the theme to a standard WP theme (2019) with no luck. I then asked the KLEO developers and got this answer:

Hi,

Using KELO having same issue like in your GIF, changed to the default wp theme and it’s no difference between our theme and the default one, it behaves the same.

My wp installation it’s in english.

So it looks like comes from buddypress, as temporary solution i think they may be changed from wp-admin backend

Cheers
R

So could you please investigate further?

Thanks for your effort!

[boonebgorges]

Thanks very much for following up.

It's possible that there's a JavaScript error elsewhere on the page causing this problem to occur. Please open your JavaScript console and see if any errors are listed.

Were you able to look at this? If I were debugging this issue, it'd be the very first thing I'd look at.

Aside from this, I'm afraid there's nothing else that we can investigate, unless we're able to reproduce your issue.

[msteimann]

Thank you for your reply. I've asked a WordPress expert to check on his system, because I don't get any JavaScript errors. Thought it might be a browser or OS related issue. But he couldn't find any errors either.

I have a set up a test account for potential customers to be able to try out the functionality of my network, which went live on March 1st. So if you can find some time please use these credentials to see the error occur live:

www.edelmut.org
Username: Mia Musterfrau
PW: Mias edelmut

Regards,
Martin

[boonebgorges]

Hi Martin - Thanks for sharing the login info. I've confirmed the problem on your site. I have also looked at your markup and at the JavaScript shipped by Kleo on that site ​https://edelmut.org/wp-content/themes/kleo/buddypress/js/buddypress.js?ver=4.2.0, and I can't see any reason why it would not work properly.

Because the feature is working in BuddyPress, I have no choice but to conclude that it's a problem either with Kleo generally or with the specifics of the way that Kleo is implemented on your site (and/or the way that it interacts with other plugins that you're running). As such, there's no reason to believe that this is a BuddyPress bug. If you're able to narrow down the cause in a way that indicates that it is a problem in BP itself, please feel free to reopen this ticket with details.

[msteimann]

Thank you for checking it out! What seriously bothers me is that changing the theme to a standard WordPress theme (2019 for example) does not help. Cleared caches and everything – the bug still exists on my setup. And what‘s even more important – the developers at Seventhqueen report exactly the same issue. I really wonder what‘s going on?

[boonebgorges]

the developers at Seventhqueen report exactly the same issue.

By this I assume you mean that they've found the same thing as *me*, which is to say that they can't reproduce?

Have you reproduced on a site that's running only BuddyPress - no other plugins? It's possible that it's a plugin conflict.

[msteimann]

Sorry for the confusion. I was trying to quote the Seventhqueen response in #4, but quotation failed. Here is their reply again:

Radu March 6, 2019 4:22 pm
Hi,

Using KELO having same issue like in your GIF, changed to the default wp theme and it’s no difference between our theme and the default one, it behaves the same.

My wp installation it’s in english.

So it looks like comes from buddypress, as temporary solution i think they may be changed from wp-admin backend

Cheers
R'

To answer your first question: Developer Radu from Seventhqueen could reproduce my issue.

To answer your second question: Yes, any other plugins disabled – makes no difference.

[boonebgorges]

Thanks for the clarification. My previous reading of the Seventhqueen response was that they could *not* reproduce the issue.

On a hunch, I switched to the Legacy templates and was able to reproduce. This is a regression from [11619], which changed the hierarchy in the DOM.

Thanks for persevering through this ticket.

[boonebgorges]

In 12357:

Legacy: Ensure that profile field visibility text updates after visibility change.

The feature was originally introduced in [7152] and was broken by a change
in the DOM hierarchy in [11619].

Fixes #8044.

[msteimann]

Thank you for sorting this out boonebgorges!

May I add the reminder that my „profile field visibility text updates“-issue in the Legacy template is accompanied by the problem of loosing the registration settings if a field reports a failure, which has been described and solved here: #4958

And maybe this issue could be permanently fixed too: #8042

Thanks again for your support.

[msteimann]

Replying to boonebgorges:

In 12357:

Legacy: Ensure that profile field visibility text updates after visibility change.

The feature was originally introduced in [7152] and was broken by a change
in the DOM hierarchy in [11619].

Fixes #8044.

Hello again,

I am not sure whether your reply meant that I should have to follow changeset 12357, or wait for an official update of the plugin. Anyway, I just did and changed the code in line 1163, but the issue still exists. Am I missing something?

Regards,
Martin

[boonebgorges]

The fix will be part of BuddyPress 5.0.0. This is what the Milestone flag on this ticket refers to.

I believe that Kleo ships its own version of BP's JS files. So it's likely that the Kleo team will have to release a corresponding update. In the meantime, it might be possible to make a similar change in Kleo's JS, but I don't have access to verify this one way or another. You may want to reach out to Seventhqueen.

[msteimann]

Okay, thank you for the clarification.

Should I open a new ticked for these remaining issues, or will they too be fixed in 5.0.0?

1. Legacy Template and #4958

Second, if a user fails to successfully register (if the passwords don't match, or she doesn't fill in a required field), the form 'loses' the user's choices upon reload.

2. Legacy Template and #8042

[boonebgorges]

#8042 already has a ticket open, and as mentioned there, it will be fixed once a contributor has written and tested an acceptable patch.

#4958 is not a new issue, and was marked resolved against a previous release. ​https://buddypress.trac.wordpress.org/changeset/7150 If you are experiencing a similar issue, and can confirm that it's reproducible on a vanilla installation of BuddyPress (using a default WP theme, for example), please open a new ticket where you outline the exact steps to reproduce. Feel free to reference #4958 when and if you open that ticket.