[#5226] Registration Ajax email checker failure

9 years 3 weeks ago - 9 years 3 weeks ago #262120 by edjec
This issue seems to have reared it's head again. We get the message "Could not check this email: Please double-check: Needed for confirmation." on either front or back end registration. In checking for a solution I have disabled Core Fields Ajax, but it will not disable in the front end.

Any ideas?



J2.5.28, CB 1.9.1, CBS 3.0.0

Please Log in to join the conversation.

9 years 3 weeks ago #262130 by nant
Replied by nant on topic Registration Ajax email checker failure

edjec wrote: This issue seems to have reared it's head again. We get the message "Could not check this email: Please double-check: Needed for confirmation." on either front or back end registration. In checking for a solution I have disabled Core Fields Ajax, but it will not disable in the front end.

Any ideas?



J2.5.28, CB 1.9.1, CBS 3.0.0


That is just a warning that the specific email address being tested cannot be verified most likely because the email server driving it does not allow email checks to complete.
The following user(s) said Thank You: edjec

Please Log in to join the conversation.

9 years 3 weeks ago #262251 by edjec
Replied by edjec on topic Registration Ajax email checker failure

That is just a warning that the specific email address being tested cannot be verified most likely because the email server driving it does not allow email checks to complete.


Yes, I am aware of that, but there are several issues when this happens; firstly, all email addresses are receiving this warning, even known good addresses.

Secondly, new registrants are abandoning the registration when they see this message resulting in lost registration sales.

Finally, when I disable the Ajax field plugin, it continues to check all addresses on the front end registration form. Should this not ignore the address check when disabled?

More importantly is why are the addresses not being properly checked? Addresses that are already in the database are being reported as duplicates - so that part of the function works fine. The issue is on all NEW addresses are resulting with this error. It appears as if there is no internet access and the check fails after an extended period of time. But of course access is fine.

Thanks

Please Log in to join the conversation.

9 years 3 weeks ago #262284 by krileon
Replied by krileon on topic Registration Ajax email checker failure

Yes, I am aware of that, but there are several issues when this happens; firstly, all email addresses are receiving this warning, even known good addresses.

It's not whether the email is good or not it's whether the recipient mail server responds to MX Record lookup. Google for example rejects all of these so no gmail address will response to these (unless Google decides to change this for whatever reason).

Secondly, new registrants are abandoning the registration when they see this message resulting in lost registration sales.

I think to avoid this we should just return a success message or nothing at all. I do agree the warning is likely off putting to users. Have added a feature ticket for this.

forge.joomlapolis.com/issues/5226

Finally, when I disable the Ajax field plugin, it continues to check all addresses on the front end registration form. Should this not ignore the address check when disabled?

You need to edit the email field within CB > Field Management and disable its ajax validation within Parameters > Validation.


Kyle (Krileon)
Community Builder Team Member
Before posting on forums: Read FAQ thoroughly + Read our Documentation + Search the forums
CB links: Documentation - Localization - CB Quickstart - CB Paid Subscriptions - Add-Ons - Forge
--
If you are a Professional, Developer, or CB Paid Subscriptions subscriber and have a support issue please always post in your respective support forums for best results!
--
If I've missed your support post with a delay of 3 days or greater and are a Professional, Developer, or CBSubs subscriber please send me a private message with your thread and will reply when possible!
--
Please note I am available Monday - Friday from 8:00 AM CST to 4:00 PM CST. I am away on weekends (Saturday and Sunday) and if I've missed your post on or before a weekend after business hours please wait for the next following business day (Monday) and will get to your issue as soon as possible, thank you.
--
My role here is to provide guidance and assistance. I cannot provide custom code for each custom requirement. Please do not inquire me about custom development.
The following user(s) said Thank You: nant, edjec

Please Log in to join the conversation.

9 years 3 weeks ago #262312 by edjec
Replied by edjec on topic Registration Ajax email checker failure

It's not whether the email is good or not it's whether the recipient mail server responds to MX Record lookup.

I was concerned that the system was not doing the MX lookup. Even known good addresses(my own) are failing here. However, I have done a direct MX lookup on some of the failed addresses and they have returned an error.

Have added a feature ticket for this. forge.joomlapolis.com/issues/5226

Thank you for escalating.

You need to edit the email field within CB > Field Management and disable its ajax validation within Parameters > Validation.

I would like to keep the Ajax function because without it registrations continue and do not fail until finalized if there is a hard error in the email address. This causes the registrant to repeat the registration process. Most will not and abandon.

Here's what I did in the mean-time:
  • Deleted the "Could not check this email: ~" message in default_language.php
  • Commented out <!--span class="cb_result_warning"--> in comprofiler.php and cb_core.php

This way the Ajax check still functions to catch hard errors, but does not return the look-up failure message.

Thanks for your help krileon!
The following user(s) said Thank You: krileon

Please Log in to join the conversation.

Moderators: beatnantkrileon
Time to create page: 0.225 seconds

Facebook Twitter LinkedIn