Add a TOS checkbox for registeration

[mahdiar]

Hi
I think it's necessary to have a TOS ( Terms Of Services) checkbox in the registration page and can be modified in the dashboard.
It's simple but important .
Thanks

[karmatosed]

I feel this is more plugin though as not everyone needs terms and conditions?

[mahdiar]

I think every community has rules and every member should accept the rules .

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/

[imath]

As we'll be working on registration improvement, let's have another look at it ;)

[vapvarun]

Add TOS field

[vapvarun]

Backend display of TOS field

[vapvarun]

TOS field at register page

[vapvarun]

Initial draft

[imath]

Hi @vapvarun thanks a lot for your screenshots and patch I’ll test it asap 👌

[imath]

@vapvarun

Thanks again for this "initial draft" 😁.

I'll start my feedback with some generic advices:

• Please use the --no-prefix option when generating the patch, in particular when there's a new file (it avoids this new file to be located outside of the needed folder (b/src...).
• Let's use strict comparisons === instead of ==.

Then about the feature:

1. The fact the user agreed to the terms of service should be saved into the db. It doesn't seem to be the case (at least when I tested the patch it wasn't saved).
2. There should be an option to disable signup if the checkbox is not checked, just like we're doing for the GDPR checkbox.
3. This field should have a different behavior according to whether the user already agreed or not. If the user agreed, it should only display a mention "You agreed to %s" where %s would link to the page.
4. This field should not support custom visibility neither autolink.
5. This field should only be displayed to the self user
6. I don't see the need for adding a new instance of the WP_Editor: the field description can be used to add some explanations and we should be more restrictive by default and include filters in case people want to customize the output (see next point).
7. We should use a page dropdown to select the TOS page, use the page title and the page link to build the checkbox output eg: sprintf( __( 'I agree to %s', 'buddypress' ), '<a href="' . esc_url( get_permalink( $page_id ) . '">' . get_the_title( $page_id ) . '</a>' )
8. We should think of this new field to be a replacement for how we include the GDPR checkbox into the signup form.

FYI in #7162, the patch is including some improvements to be able to customize/disable some feature like custom visibility and autolink. I will try to commit these improvements and add some others (eg support WP-Admin extended profile, view screen..) so that you'll be able to use them there 😉

You'll find some other tiny improvements into the .2.patch I've quickly built from yours.

Don't hesitate to ping me if I can help 👌

[vapvarun]

@imath Visibility labels for xprofile field do not have a filter to hide it, meta boxes are disabled on the same pattern as wp fields using hide_field_types.

[vapvarun]

updated template files

[vapvarun]

updated template files

[vapvarun]

it will be read only once accepted

[vapvarun]

TOS field will not be visible in view profile mode

[vapvarun]

removed wp_user_key to check field type

[imath]

Hi @vapvarun I was about to test the -5.patch but it looks like the class-bp-xprofile-field-type-checkbox-acceptance.php is not included in it.

Could you do git add -N src/bp-xprofile/classes/class-bp-xprofile-field-type-checkbox-acceptance.php before generating the patch. Or if you work from a specific branch don't forget to commit your changes before doing your branches diff.

Thanks in advance 😉

[vapvarun]

@imath sorry updated again

[vapvarun]

added the missing file

[vapvarun]

added the missing file

[imath]

Thanks a lot @vapvarun 👍 I'm going to test it asap.

[imath]

@vapvarun I've tested the patch. First thanks a lot for the improvements you brought.

I am pretty much concerned about editing the BP Template Packs templates. If Theme authors, or advanced users have overriden the templates, there's a high risk they won't update it even if we communicate early about it.

So I'm suggesting another way to deal with it in ​4747-7.patch. First I've found out there was a bug in [12868]. So I've added a fix into the patch to make sure the $visibiliy property of the field type is applied when saving the field from xProfile Admin.
I've set this visibility property to 'adminsonly' meaning only admins and the concerned user can see the field. I've also added support to allow the "Require" feature to be toggled, because it potentially make this field type more interesting. For instance you could use it to check access to an optional part of a website (eg: a game rules you need to accept before playing an optional game).
I've also added the BP_XProfile_Field_Type_Checkbox_Acceptance->enforce_field_value() method to make sure someone who edited the form source removing readonly/onclick attributes of the checkbox cannot revert an already accepted field. I made some name/string changes to avoid using "tos": we can use this field type for other situation than the terms of service (eg: code of conduct, etc..). Finally I've added some checks to be sure the linked page exists.
I'm fine with committing this version of the patch, what do you think?

[vapvarun]

@imath Thanks

I have checked again, yes we can go with it
Template override is not mandatory I was only trying to remove any visibility message attached with TOS field

[imath]

Awesome @vapvarun I’ll commit it asap 👌

[imath]

In 12881:

xProfile: make sure a Field Type can enforce field visibility

When saving a field having a Field Type where the custom visibility feature is disabled and the visibility property is set, use this visibility to enforce the field visibility. This part was forgotten in #7162 and it is needed by the Checkbox Acceptance field to make sure only the logged in user can see they agreed to the page requiring their acceptance.

Props mahdiar, vapvarun

See #4747

[imath]

In 12882:

xProfile: introduce the Checkbox Acceptance field type

This new field type helps community site administrators get members agreement about specific rules. It can be terms of service, code of conduct, game rules, etc.

When adding such a field, the xProfile field Admin screen will contain a specific metabox to select the WordPress page to use as the linked content needing members agreement.

This field can be required or not, but cannot be updated once members agreed to the WordPress page it relies to.

Props mahdiar, vapvarun

Fixes #4747