Skip to:
Content

BuddyPress.org

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#8042 closed defect (bug) (fixed)

visibility options for Name field appear on registration page

Reported by: msteimann Owned by: imath
Milestone: 5.0.0 Priority: high
Severity: normal Version: 4.1.0
Component: Registration Keywords: good-first-bug has-patch 2nd-opinion
Cc:

Description

Hello team,

the „change display name visibility option“ is displayed beneath the name field on the user Registration page. This should not be the case, if the name’s visibility throughout BuddyPress network is mandatory. Settings can even be changed to another value, but the user gets no visual feedback when altering the value.

@venutius provided me with some CSS code as an interim solution to hide the line of text and settings options, but I guess it would be better to handle this bug by adjusting the functions code. Sorry if I used the wrong terms – I have no coding skills at all.

Regards, Martin

https://www.martinifilm.de/download/hide-visibility-option-registration.jpg

https://www.martinifilm.de/download/field_visibilty_options_bug_on_register_page.gif

Attachments (2)

hide-visibility-option-registration.jpg (99.4 KB) - added by msteimann 3 years ago.
8042.patch (3.0 KB) - added by imath 2 years ago.

Download all attachments as: .zip

Change History (15)

#1 @Venutius
3 years ago

From what I can see the problem is that the default Name profile field has been set up with it's allow_custom_visibility set to allow, I've not been able to track down exactly where in the code it's being set.

I've come up with a workaround as follows:

In line 88 of buddypress/xprofile/bp-xprofile-caps

if ( $field_id && $field = xprofile_get_field( $field_id ) ) {
Change this to include a check to rule out field number 1:

if ( $field_id && 1 !== $field_id && $field = xprofile_get_field( $field_id ) ) {

That will stop the button being displayed on the registration form.

#2 follow-up: @Venutius
3 years ago

I've found that this is happening because the function get_allow_custom_visibility in buddypress/bp-xprofile/classes/class-bp-profile-field is defaulting to allow for all profile fields where the visibility has not been specifically disabled. this is appropriate for all profile fields except Name where it should be disabled even if it is not set. my proposed fix is to change line 833 as follows:

if ( 'disabled' === $allow_custom_visibility || 1 === $this->id ) {

This adds an extra check to ensure the Name field returns as disabled, thus fixing the issue with the registration form.

Last edited 3 years ago by Venutius (previous) (diff)

#3 in reply to: ↑ 2 @msteimann
3 years ago

Replying to Venutius:

I've found that this is happening because the function get_allow_custom_visibility in buddypress/bp-xprofile/classes/class-bp-profile-field is defaulting to allow for all profile fields where the visibility has not been specifically disabled. this is appropriate for all profile fields except Name where it should be disabled even if it is not set. my proposed fix is to change line 833 as follows:

if ( 'disabled' === $allow_custom_visibility || 1 === $this->id ) {

This adds an extra check to ensure the Name field returns as disabled, thus fixing the issue with the registration form.

Thank you, works like a charm! Regards, Martin

#4 @boonebgorges
3 years ago

  • Keywords good-first-bug added
  • Milestone changed from Awaiting Review to Awaiting Contributions

Hi all - This seems like something we could probably fix in BP. Let's be sure not to hardcode 1 - let's use bp_xprofile_fullname_field_id().

#5 @msteimann
3 years ago

Hello team,

the bug still exists in BP version 4.2.0, so I switched back to 4.1.0

Any plans for patching it in a future version?

Regards,
Martin

#6 @boonebgorges
3 years ago

Hi @msteimann - As noted above, it's a valid concern, but it was not fixed as part of 4.2.0. However, you should NOT switch back to 4.1.0 as a result, since 4.2.0 was an important security release.

This ticket is currently labeled as Awaiting Contributions. This means that a member of the team, or the broader community, will need to find time to write a patch, and it will need to go through the normal review process.

#7 @msteimann
3 years ago

@boonebgorges - Thank you for your reply. I've just reinstalled 4.2.0 and added the Venutius' patch to line 833. Fortunately the patch still works!

@imath
2 years ago

#8 @imath
2 years ago

  • Keywords has-patch 2nd-opinion added; needs-patch removed
  • Milestone changed from Awaiting Contributions to 5.0.0

Hi everyone,

I've been working on this during the WordCamp Paris contributor day and I suggest another approach. Instead of keeping on checking if the field_id is the one of the fullname field into BP_XProfile_Field->get_allow_custom_visibility(). We can set the allow_custom_visibility profile field meta during the install process and make sure existing BuddyPress installs are updated during the 5.0.0 update routine.

See 8042.patch

Last edited 2 years ago by imath (previous) (diff)

#9 @boonebgorges
2 years ago

Thanks, @imath ! This approach seems fine to me, with the caveat that we don't want administrators to be able to toggle allow_custom_visibility. It looks like this is prevented by the is_default_field() checks in class-bp-xprofile-field.php?

#10 @imath
2 years ago

@boonebgorges Yes, I confirm this function prevents many metaboxes from being displayed including the one to set the custom visibility.

I'm going to run some more tests before committing the patch :)

#11 follow-up: @imath
2 years ago

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

In 12390:

Make sure custom visibility is disabled for the default profile field

props venutius

Fixes #8042

#12 in reply to: ↑ 11 @msteimann
2 years ago

Replying to imath:

In 12390:

Make sure custom visibility is disabled for the default profile field

props venutius

Fixes #8042

Hello @imath

Can you please advise me how to add the patch? I have installed the three php-files from 12390 by overwriting the current files on my system (BuddyPress 4.3.0). After clearing the cache the issue still remains.

Regards,
Martin

#13 @imath
2 years ago

Hello @msteimann

You don't need to apply the patch it's been committed to trunk. If you want to test to check if it's fixing the issue, I advise you to test it *locally* following the developer section of this page: https://buddypress.org/download/

Note: See TracTickets for help on using tickets.