#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)
Change History (15)
#2
follow-up:
↓ 3
@
6 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.
#3
in reply to:
↑ 2
@
6 years ago
Replying to Venutius:
I've found that this is happening because the function
get_allow_custom_visibility
inbuddypress/bp-xprofile/classes/class-bp-profile-field
is defaulting toallow
for all profile fields where the visibility has not been specifically disabled. this is appropriate for all profile fields exceptName
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
@
6 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
@
6 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
@
6 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
@
6 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!
#8
@
5 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
#9
@
5 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
@
5 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:
↓ 12
@
5 years ago
- Owner set to imath
- Resolution set to fixed
- Status changed from new to closed
In 12390:
#12
in reply to:
↑ 11
@
5 years ago
Replying to imath:
In 12390:
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
@
5 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/
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 toallow
, 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.