Confirming the email receiving.
That said, I’m not sure there’s going to be much I can tell you, as the code above is rather basic.
Best guess I have at the moment is maybe one of the functions isn’t defined quite yet and it’s causing perhaps some ajax errors?
Can you check your browser’s dev tools and the console tab, to see if something is getting displayed/logged there?
jquery-migrate.min.js?ver=1.4.1:2 JQMIGRATE: Migrate is installed, version 1.4.1
(index):1 An invalid form control with name=’field_2′ is not focusable.
(index):1 An invalid form control with name=’field_15′ is not focusable.
(index):1 An invalid form control with name=’field_4′ is not focusable.
(index):1 An invalid form control with name=’field_6′ is not focusable.
(index):1 An invalid form control with name=’field_13′ is not focusable.
(index):1 An invalid form control with name=’field_7′ is not focusable.
(index):1 An invalid form control with name=’field_14′ is not focusable.
(index):1 Unchecked runtime.lastError: The message port closed before a response was received.
I’m not much at coding, but I’m pretty sure the issue is coming from the fact that the approved member type (the one that’s working fine) gets conditional xprofile fields to fill out (which are required, so they’re getting filled in). The member profile not working, which is the basic member type (without those extra xprofile fields), I’m going to guess is somehow expecting those fields based on your code.
Just my guess. Would it make a difference if you tweaked the code to say, if not member-type-X, use member-type-Y. Maybe forcing it in the helps?
Thanks
Pasting here so I can visually reference it easier.
The thing with this code is that we really don’t do much with it. All of the user registration process should already be done at this point. All the xprofile fields saved, etc. What we do do here is simply get the saved member type for the given user, after registration has gone on. If we get a false value out of it, by chance, we just don’t do anything. Then we confirm that we have an array, and then the “type_value” part is meant to be the membership type registered. That would be a detail changed for everyone using this code.
After that, we check if the intended non-moderated member type is in the member types associated with the registering user, set the moderated status to false.
We run on a lower priority as well, meaning most other code meant to run during the registration process, should already be done before we step in.
For the sake of the intent of some member types not being moderated, we shouldn’t need to be doing any membership changes for them.
function bpro_per_member_type_moderation_override( $user_id ) {
$member_type = bp_get_member_type( $user_id );
// No membershipt type found, Let's not do anything.
if ( false === $member_type ) {
return;
}
// Should return an array of member types, even if only one type assigned.
if ( is_array( $member_type ) ) {
if ( in_array( 'type_value', $member_type, true ) ) {
bp_registration_set_moderation_status( $user_id, 'false' );
}
}
}
add_action( 'user_register', 'bpro_per_member_type_moderation_override', 11 );
Then it sounds like BuddyPress submit button may be the issue: https://stackoverflow.com/a/28340579
The error in question may also arise due to a premature validation. Premature validation can occur when you have a <button> input without a set type attribute. Without the type attribute of a button being set to button, Chrome (or any other browser for that matter) performs a validation each time the button is clicked because submit is the default type of buttons. To solve the problem, if you have a button on your page that does something else other than submit or reset, always remember to do this: <button type=”button”>
Not sure where to find this code, but you buy this at all? Or have any last suggestions/direction?
Thanks for your help,
Sam
I honestly doubt those parts are factoring in at all with this. That’s more an HTML markup/accessibility issue rather than some sort of issue with processing the click and everything.
Would I be prompted for membership type if I go to the emailed staging sites? Or is there something specific I’d need to do to get the correct, not-presently-working, member type?
No, it’s really simple. Basic info required, and there’s a radio button with 2 selections. Individual (default) or Service. If you switch radio button to Service, you’ll see 7 additional xprofile fields that will be required. If you switch back to Individual, they get hidden. That’s it. Pretty simple.
Go take a peek!
https://saint-truce.staging.wpmudev.host/register/
I sent the .htpasswd login info to your email.
Thanks,
Sam
replied privately with a followup
Hi Michael – I have tentatively resolved this issue of suppressing the approval process for certain BP member types (again, I use BP Member Types Pro plugin by BuddyDev for member types) in conjunction with a modified version of your snippet (per Brajesh @ BuddyDev). He has updated the plugin (and snippet) to support yours.
Here’s a link to that snippet.
But only tentatively because there’s a weird new plugin behavior, and I want to see if you have any suggestions on resolving this.
The issue is that although the approval process is properly suppressing the specified member type during his/her registration/login process (no pending approval warnings anymore), the plugin is oddly (1) still sending out the “pending membership approval” email to both the user and (2) the admin. And on the admin side, it’s (3) still requesting the actual approval decision, even though the user is fine.
Thoughts?
Thanks,
Sam
The code provided, as well as the modified verson, does not account for the email notification, I must admit and confirm. I would need to dive back in and see what hooks, if any, are available to avoid the admin notification sending.
We do do some caching of details, and I suspect that that’s why it’s still showing some spots. However, I would need to mentally refresh and confirm exactly what parts are involved with the caching.
@beekoff
Apologies for jumping in here. I’ve already started my own thread (https://wordpress.org/support/topic/suppress-emails-2/) re. admin emails getting sent out despite the user not requiring moderation (to which Michael has already kindly responded) but just wondering if you’d found your own workaround for this yet?
Warm regards
Nikki
Hi Nikki – No solution for me (I’ve had to disable the plugin & functionality – though have been recommended Profile Builder plugin that I haven’t tested yet). Really annoying bug, as I’m stuck with it as I don’t code. And if i remember correctly, Profile Builder provides similar approval functionality with the addition of evaluating users’ xprofile fields while making approval/rejection decision (and giving the user rejection/modification feedback/retry option). If I’m right about that functionality, you might want to check it out.
Regards,
Sam
Many thanks for getting back to me Sam and for the alternative suggestion. One of the things I actually like about this plug-in is its relative simplicity and since, in this case at least, it does pretty much everything I need (with the exception of the emails), I’m going to stick with it for now and have a bit more of a dig into the code.
If I come up with anything that might be useful, I’ll be happy to post it here.
Warm regards
Nikki
Hello,
I am also deciding between BuddyPress and Ultimate Member as a solution. I will need a Member types plugin, either BuddyDev or BuddyBoss with this plugin. Can anyone verify that the solution provided here with either plugin has been successful?
Hi @ninsights
It depends exactly what you’re trying to achieve, but yes I have got this working quite well with a combbination of BuddyPress, BP Registration Options and BuddyPress Member Type Generator.
It did take a little custom coding and tweaking of the settings but if your requirements are similar to mine (ie. several different member types with some needing automatic approval and some requiring to be manually authorised), it certainly can be done.
Regards
Nikki
