Skip to:
Content

BuddyPress.org

Opened 21 months ago

Closed 18 months ago

Last modified 17 months 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 21 months ago.
8042.patch (3.0 KB) - added by imath 18 months ago.

Download all attachments as: .zip

Change History (15)

#1 @Venutius
21 months 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
21 months 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 21 months ago by Venutius (previous) (diff)

#3 in reply to: ↑ 2 @msteimann
21 months 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
20 months 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
20 months 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
20 months 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
20 months 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
18 months ago

#8 @imath
18 months 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 18 months ago by imath (previous) (diff)

#9 @boonebgorges
18 months 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
18 months 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
18 months 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
17 months 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
17 months 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.