Skip to:
Content

BuddyPress.org

Opened 8 weeks ago

Last modified 18 hours ago

#8582 new enhancement

Add site membership requests.

Reported by: dcavins Owned by:
Milestone: 10.0.0 Priority: normal
Severity: normal Version: 9.1.1
Component: Members Keywords: has-patch needs-testing
Cc: dcavins

Description

It would be very useful to be able to screen site members on the way in, rather than dealing with spam users who have registered and gained access to the site immediately.

I've built a first working patch that interrupts the registration flow, so that a site admin must manually intervene to send the activation email to the user. Here's a comparison of the normal registration flow with the proposed request-based flow:

BuddyPress normal sign-up process:
User fills out registration form.
User is created in signups table with active = 0.
User is created in users table with status = 2
BuddyPress sends user an activation email.
User follows link in email to activate account.
User receives welcome email from BP site.
Table updates: signups entry now is active, user status is now 0.

Membership request sign-up process:
Admin disables "Anyone can register" and enables membership requests.
User visits registration form which has been recast as a "Request Membership" form.
Site admins receive email and notifications about the pending request.
Site admin can manage via the "manage signups" interface.
Admin can check the user's registration information via the extended profile view.
Admin approves the user and the activation email is sent.
User follows link in email to activate account.
User receives welcome email from BP site.

Notes:
If an email has been sent, the request is considered to be "approved."
Front-end profiles can also be viewed before the user is activated/validated. Should we change that behavior?
I have added a filter so that when requests are enabled, it is possible to bypass the manual approval process for some users, like if users are using a certain email domain that you know is trustworthy (like your school or organization).

Attachments (27)

8582.1.diff (47.9 KB) - added by dcavins 8 weeks ago.
Add request membership capability. First draft.
1-enable-site-requests.png (102.2 KB) - added by dcavins 8 weeks ago.
Enabling site requests
2-user-request-membership-form.png (99.2 KB) - added by dcavins 8 weeks ago.
Request form
3-user-completes-request-form.png (49.3 KB) - added by dcavins 8 weeks ago.
Form completion
3a-user-prevented-from-logging-in.png (23.5 KB) - added by dcavins 8 weeks ago.
User has a pending account, so can't log in yet.
4-site-admin-receives-email.png (18.0 KB) - added by dcavins 8 weeks ago.
The site admin gets an email about the request
4a-admin-receives-notification.png (57.0 KB) - added by dcavins 8 weeks ago.
Site admins also receive an on-site notification.
5-manage-signup-table.png (115.3 KB) - added by dcavins 8 weeks ago.
Manage signups table
6-manage-single-view.png (106.4 KB) - added by dcavins 8 weeks ago.
Checking a user's submitted info.
7-user-receives-activation-email.png (33.5 KB) - added by dcavins 8 weeks ago.
Once approved, user receives the activation email.
8-manage-signups-after-approval.png (114.3 KB) - added by dcavins 8 weeks ago.
After the approval email has been sent.
9-user-follows-activation-link.png (30.4 KB) - added by dcavins 8 weeks ago.
User follow the activation link.
10-user-activation-success.png (34.0 KB) - added by dcavins 8 weeks ago.
User successfully activates her account!
8582.2.add-links.diff (2.7 KB) - added by dcavins 7 weeks ago.
Add Request Membership links to WP Toolbar, meta widget, wp-login form.
8582.3.diff (59.9 KB) - added by dcavins 4 weeks ago.
New patch.
request-membership-links-wp-login.png (13.0 KB) - added by dcavins 4 weeks ago.
Link added to wp-login screen
request-membership-links-1.png (19.5 KB) - added by dcavins 4 weeks ago.
Links added to widget form.
manage-signups-new-column.png (74.6 KB) - added by dcavins 4 weeks ago.
new column on Manage Signups screen.
manage-signups-xprofile-modal.png (70.6 KB) - added by dcavins 4 weeks ago.
Modal for profile info on manage signups screen.
manage-signups-approval-screen.png (19.3 KB) - added by dcavins 4 weeks ago.
new language on "send approval email" screen
mail-dear-john.png (8.1 KB) - added by dcavins 4 weeks ago.
Sad rejection letter.
8582.4.patch (15.7 KB) - added by imath 3 weeks ago.
8582.5.patch (67.3 KB) - added by dcavins 2 weeks ago.
Updated patch including imath's changes and a few more improvements.
8582.6.patch (71.3 KB) - added by dcavins 9 days ago.
Updated patch.
8582.6-refreshed.patch (64.9 KB) - added by imath 7 days ago.
8582.7.patch (35.1 KB) - added by imath 7 days ago.
8582.8.patch (72.4 KB) - added by imath 18 hours ago.

Download all attachments as: .zip

Change History (44)

@dcavins
8 weeks ago

Add request membership capability. First draft.

#1 @dcavins
8 weeks ago

I would appreciate help testing the first patch. There are some things I know still need to be handled, like marking notifications as read when signups are approved or deleted. If you notice anything (in either Legacy or Nouveau) that seems off, please let me know. It is probably not necessary to do a line-by-line review of the patch yet. :) Thanks for your feedback!

I am attaching a series of images showing the basic steps in the process, for easy review.

Last edited 8 weeks ago by dcavins (previous) (diff)

@dcavins
8 weeks ago

Enabling site requests

@dcavins
8 weeks ago

Request form

@dcavins
8 weeks ago

Form completion

@dcavins
8 weeks ago

User has a pending account, so can't log in yet.

@dcavins
8 weeks ago

The site admin gets an email about the request

@dcavins
8 weeks ago

Site admins also receive an on-site notification.

@dcavins
8 weeks ago

Manage signups table

@dcavins
8 weeks ago

Checking a user's submitted info.

@dcavins
8 weeks ago

Once approved, user receives the activation email.

@dcavins
8 weeks ago

After the approval email has been sent.

@dcavins
8 weeks ago

User follow the activation link.

@dcavins
8 weeks ago

User successfully activates her account!

#2 @imath
8 weeks ago

Waou !! This looks really promising !! Thanks a lot for your work on this ticket, the patch and the screenshots. I’ll test the patch asap and will provide more feedbacks soon 👍

#3 follow-up: @imath
8 weeks ago

Here are my first feedbacks @dcavins. For now I haven't reviewed the patch in detail to focus on the feature's (needed imho) improvements.

Thanks a lot for this first pass about the feature. It's already very promising and it should work great when the registration process creates a User, but...

1) About the BuddyPress/WordPress signup process

There is only 1 case where a user is created once they submit the registration form: when WordPress is not multisite and when the BP_SIGNUPS_SKIP_USER_CREATION is not defined or false.

As a result, I strongly discourage you to use data from the wp_users table for this feature.

2) About the setting:

Would it be better to name the feature "site membership requests" instead of "network membership requests" if WordPress is not multisite or if BuddyPress is not network activated?

  • The checkbox should be readonly until the required signup option matches the need for disabling public registration.
  • We should probably include a link to where to turn public registration off.
  • This setting can't be 1 or 0 imho because of Multisite registration possibilities (account, account + blog).

3) What's the strategy to add the link to request a membership?

Should we include a link to the wp-login.php form at the minimum?

4) Testing the patch:

PS: On purpose (I knew doing so I'll get some errors 😆) I've set the BP_SIGNUPS_SKIP_USER_CREATION constant to true.

4.1) Once I submit the form I got a success message but also a notice error:

Undefined variable $item_id in /path-to/buddypress/src/bp-members/bp-members-membership-requests.php on line 119

You should probably use $signup->id instead.

4.2) If i go to the Manage signups screen, the request is listed but:

Warning: Attempt to read property "ID" on bool in /path-to/buddypress/src/bp-members/bp-members-notifications.php on line 85

That's because as I've explained above: the user wasn't created, because I've set the BP_SIGNUPS_SKIP_USER_CREATION constant to true.

I don't get the Extended link for the user requesting a site membership. See screenshot below:

https://cldup.com/Y1fEPCZIKA.jpg

If I click on the notification link, nothing happens unlike what the 6-manage-single-view.png shows. I stay on the Signup list. That's because of the BP_SIGNUPS_SKIP_USER_CREATION constant, but it would also be the case for Multisite configs. Using the Extended Profile is an interesting idea, but I believe we need more work to use a UI that is available for any WordPress/BuddyPress configs.

4.3) Possible improvements/questions :
  • Could we have like it's the case for pending comments a specific yellow background applied to the row?
  • What about a row action to reject with an email message the request?
  • When clicking on the Activate row action in this case, how is the requesting user informed their account has been activated?
  • The approve request row Action should lead to an adapted "Resend Activation Emails" screen:
    • page title = "Approve request(s)"
    • description = "You are about to approve the following request(s)"

5) About the admin email notice content

To learn more about the site, visit: site.url

What are we supposed to learn more, as an Admin I know my site, don't I? I'd remove this part from the email. This may only be interesting for multisite configs.

To view {{requesting-user.name}}'s profile, visit: profile.url

As on multisite or if BP_SIGNUPS_SKIP_USER_CREATION is true : the User is not created: this should fail (I wasn't able to test emails on my config). It should be the link to open the Admin UI made available for any WordPress/BuddyPress configs.

Conclusion:

As I've said it's very promising and you already did some great work about it. But I believe we need some more work to take in account the 2 other signup processes you haven't covered so far 😁

#4 in reply to: ↑ 3 @dcavins
7 weeks ago

Replying to imath:
Thanks for your feedback, imath!
I have a few questions and/or responses:

  • This setting can't be 1 or 0 imho because of Multisite registration possibilities (account, account + blog).

I'm not sure what you mean. Can you explain why enabling request or not would need more than on/off?

3) What's the strategy to add the link to request a membership?

Should we include a link to the wp-login.php form at the minimum?

I've added a link to the BP login form, but sure, it seems like it should be added to the wp-login form as well.

Using the Extended Profile is an interesting idea, but I believe we need more work to use a UI that is available for any WordPress/BuddyPress configs.

Sure. There may be a way to hotwire the extended view for signup IDs. I'll look into it.

  • What about a row action to reject with an email message the request?

I agree that we should probably send a "rejected" email. Poor requester. :)

  • When clicking on the Activate row action in this case, how is the requesting user informed their account has been activated?

They get the welcome email.

Thanks again for taking a look at this!

@dcavins
7 weeks ago

Add Request Membership links to WP Toolbar, meta widget, wp-login form.

#5 @imath
7 weeks ago

You're welcome 😉.

About:

I'm not sure what you mean. Can you explain why enabling request or not would need more than on/off?

Correct me if I misunderstood: to turn on site membership requests. You need to disallow public registration. On a single site config, the WP option 'users_can_register' can be 1 or 0 so I agree with you.

But on multisite, the corresponding WP site meta 'registration' can be 'all', 'blog', 'user' or 'none', so what the admin needs to select to enjoy the site membership requests feature ? 'blog' or 'none' ?

How would we handle the case where only user account can be requested?
How would we handle the case where both user account and site can be requested?

(there's a chance I'm overthinking it! 😅)

Last edited 7 weeks ago by imath (previous) (diff)

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


6 weeks ago

#7 @dcavins
4 weeks ago

Here's an updated version of the patch that makes a few changes. The biggest difference is that instead of trying to use the user pages (in WP-Admin), any submitted extended profile data is available in the "Manage Signups" screen, which relies on the signup data only, and I've removed any code that refers to users. Other changes:

  • Add links to the request membership form to the widget login form, wp-login, and the WP toolbar.
  • Send a rejection email to rejected users. :,(
  • Change the language on the manage signups > resend email screen (rebranded to "send approval emails").

Images and a fresh patch to follow.

@dcavins
4 weeks ago

New patch.

@dcavins
4 weeks ago

Link added to wp-login screen

@dcavins
4 weeks ago

Links added to widget form.

@dcavins
4 weeks ago

new column on Manage Signups screen.

@dcavins
4 weeks ago

Modal for profile info on manage signups screen.

@dcavins
4 weeks ago

new language on "send approval email" screen

@dcavins
4 weeks ago

Sad rejection letter.

#8 @imath
4 weeks ago

Really nice! Thanks a lot for your work on these improvements! I'll test the patch asap.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


4 weeks ago

@imath
3 weeks ago

#10 follow-up: @imath
3 weeks ago

Hi @dcavins

I've tested the patch, and was a bit surprised at the beginning as submitting a membership request was sending an activation email. Then I understood checking your previous patch that one file was missing. So I've used 8582.1.diff to include the missing bp-members-membership-requests.php file into 8582.4.patch to have it work the way it should. You should probably check again my edits about this file 😆. 8582.4.patch also includes some recommandation (eg: escaping some outputs, or displaying a message when there are no profile field to display into the modal).

I have some remarks/questions 😁.

  • I guess the purpose of having a separate bp-members-membership-requests.php is to only include it if Membership requests are allowed, so I've edited this part in the 8582.4 patch. But I see a lot of functions that should be moved into this file... (eg: all the ones that are inside src/bp-members/bp-members-filters.php).
  • Why do we need bp_is_active( 'members', 'invitations' ) for site membership requests? It seems weird to me.
  • Is the Approved column necessary into the WP List Table? I don't see the benefit of it.
  • The "Manage signups" WP Admin Menu item should probably be renamed "Manage Pending members".

Otherwise, thanks a lot for your great progress about the ticket, we're getting closer to the finish line 🏁.

On a side note and to follow up with our latest dev-chat: I've checked how WordPress uses the inline-edit feature and I don't like it. I believe we can do things better now we have the BP REST API and modern JavaScript. I'll explore this in another ticket.

#11 in reply to: ↑ 10 @dcavins
2 weeks ago

Replying to imath:
That's strange about the patch. It sure looks like new file src/bp-members/bp-members-membership-requests.php is included in the attached https://buddypress.trac.wordpress.org/attachment/ticket/8582/8582.3.diff. Maybe when you applied the patch, the new file wasn't created because of permissions or similar?

Regarding file organization, I am in favor or moving filters and actions to the main file bp-members-membership-requests.php. Putting filters in a filters file is how BP is often organized, so I respected that, but personally prefer having files organized by content, not part of speech.

I think the Approved column is useful (it's a renaming of an existing signup column, date activation email sent) because some pending memberships will have been "approved" but not activated by the end user yet. The column tells you at a glance when the approval occurred or if it hasn't yet. You could also use it to sort the "not yet approved" requests up to the top (I will enable sorting on it).

The $64,000 question: What should we do with meta for the 10.0 release? Leave it on the "activate" and "approve" screens? Use a modal, but maybe move the access link to the "actions" cell? I think it would be great to add an inline viewer/editor, but let's not let it hold up anything--it can be a nice improvement later.

Thanks!

#12 @dcavins
2 weeks ago

I'm about to upload a new version of the patch with the following changes:

  • Incorporate @imath's changes (though I had to manually merge changes in bp-members-membership-requests.php so may have missed a new escape addition there).
  • Support bp_is_active( 'members', 'membership_requests' ) so that the functionality can be disabled/hidden via code if desired.
  • Move filters from members-filters into bp-members-membership-requests.php and remove several bp_get_membership_requests_required() checks from those functions since that file is only included when membership requests are enabled.
  • Filter the "Manage Signups" menu item label in WP Admin > Users when requests are enabled.

Thanks!

@dcavins
2 weeks ago

Updated patch including imath's changes and a few more improvements.

#13 @dcavins
2 weeks ago

Another small update to delete associated notifications when a signup is approved, activated or deleted.

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


2 weeks ago

@dcavins
9 days ago

Updated patch.

#15 @dcavins
9 days ago

I've uploaded a new patch that contains the previous updates plus these changes:

  • Manage Pending Memberships screen: move profile info view link into row actions.
  • Manage Pending Memberships screen: Add request-specific help tab content.
  • Update default logic for BP_Signup->count_sent to treat no meta set like an old-style signup.
  • Add email installation upgrade routine.
  • Disable settings checkbox is "anyone can register" is true.

Thanks for your help with testing!

@imath
7 days ago

#16 @imath
7 days ago

Thanks again for the great work you've being doing on this ticket @dcavins. I've tested the patch and it works pretty fine 👏

I've refeshed it (see 8582.6-refreshed.patch) and made sure to remove the src/bp-members/bp-members-membership-requests.php.rej that was in your version and confused me a bit at the beginning.

Once 8582.6-refreshed.patch is applied, you can apply 8582.7.patch. This second patch contains some improvement suggestions:

  • Add more escaping functions
  • Fix missing textdomain
  • Add some code standards/format/inline documentation improvements
  • Limit code duplication into the WP List Tables (see bp_members_admin_preview_signup_profile_info() & bp_members_admin_format_xprofile_field_for_display())

I've also added 2 JavaScript files to make sure the Signup's profile info modal is more inline with the Hello one.

If these are fine with you, the last step (unless you find other improvements) would be to give it a last check on a multisite config as I haven't done so.

I can see the finish line!

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


18 hours ago

@imath
18 hours ago

Note: See TracTickets for help on using tickets.