Hi!

Since it is possible to force a guest to provide his contact information,
on comment-forms, it would be very useful if the e-mail adress is verified.

This makes especially sense in combination with the Comment Notify module.

Thanks in advance!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dbr’s picture

Status: Active » Needs work

That sounds like a useful feature. I don't have time to look at it now, but if somebody can provide a patch I can review and apply it.

I wonder if there is a hook in the comment code to allow a third-party module like email-verify to check the email. Otherwise it will need modification of the (core) comment module.

jvieille’s picture

Also very useful for Rules
But in general it is important to get the commenter's correct address

dsms’s picture

Sorry, I had no time to prepare a patch, but here is an outline how I would to it:

1. adding an own validate-function to $form['validate'] via hook_form_alter() to the comment form
2. Implement the validate-function in the Email-Verification module
3. set_form_error if email address isn't valid

that should be all ;)

bryancasler’s picture

Subscribe

grafixfarm’s picture

I was also wondering, if this could work with the site-wide Contact Form? Making the email field a required field then having no way of verifying the email seems like a bad thing....but then I am still scouring this website for a solution...I have had spam coming through the contact form. Although Mollom does a great job, when legitimate comment/contacts are made with the contact form, we cannot reply when the user supplies an invalid email either intentionally or otherwise.

Ela’s picture

subscribing

Melissamcewen’s picture

subscribing. I'd also like to help work on this if anyone wants to collaborate.

NancyDru’s picture

Status: Needs work » Active

Check http://drupal.org/project/email_verify. I am going to try to use its code to verify the email. Hopefully I can provide a sample later today.

BTW, "Needs work" means a patch has been supplied but isn't all it should be.

NancyDru’s picture

Status: Active » Needs review

Here you go. Also includes a setting on the node type form.

@Lynnold: Yes, it probably could (easily), but I did not include it in my patch because the site I'm working on doesn't use Contact.

gpk’s picture

Status: Needs review » Active

No patch that I can see ..??

NancyDru’s picture

Status: Active » Needs review
FileSize
2.79 KB

Wierd

gpk’s picture

Yup, can see that one :)

Have done a quick visual review:
- The text "This module verifies that email addresses are valid during account registration or edit" could now say "This module verifies that email addresses are valid during account registration or edit and optionally when an anonymous user posts a comment"
- The email_verify_check_[type] static variables are not used in anger. Suggest adding a test to the case 'comment_form': in the form_alter
- In the validation handler would it be worth logging a message when verification fails, like on the registration form?
- finally a question - is it better to use an element validation handler rather than add one to the form? not sure what best practice is here

Also a question, prompted by #5: is there a way (another module perhaps .. I had a look yesterday but couldn't find one) of making email fields "double up" so that the user has to enter it twice? Would be one way of reducing typos.

gpk’s picture

Status: Needs review » Needs work
NancyDru’s picture

The email_verify_check_[type] static variables are not used in anger. Suggest adding a test to the case 'comment_form': in the form_alter
I'm not getting what you are after here.

would it be worth logging a message
If I'm reading the code and looking at my logs, it is logging a message because it's using the same code.

is it better to use an element validation handler
Maybe, but I have always had difficulty getting error messages to properly render in an element handler.

making email fields "double up"
I could take a look at the user.module and see how they do it (complete with some js). This would have to be an option though because I don't think my customer would want this. We're going to all this trouble to allow anonymous users to comment just to save them the once-a-month trouble of logging in.

gpk’s picture

"The email_verify_check_[type] static variables are not used in anger. Suggest adding a test to the case 'comment_form': in the form_alter"
I'm not getting what you are after here.

If I'm reading it correctly most of the form_alter adds a radio to the node type form letting you specify (per node type) whether the email address entered by an anonymous user should be verified. However this setting is never used (or am I missing something?!). On second thoughts I'm not convinced it's worth specifying this per node type anyway.

Also variable $var_name is never used I think???

"would it be worth logging a message"
If I'm reading the code and looking at my logs, it is logging a message because it's using the same code.

"is it better to use an element validation handler"
Maybe, but I have always had difficulty getting error messages to properly render in an element handler.

OK great, I should have investigated more carefully..

"making email fields "double up""

that one was a bit off-topic, was just idly wondering if anyone had seen a contrib module to do that...

NancyDru’s picture

FileSize
2.95 KB

The setting is checked in the form_alter for "comment_form"

        if (variable_get("email_verify_check_$type", 0)) {
          $form['#validate'][] = 'email_verify_comment_email';
        }

If the option is not selected, the validation handler doesn't get used.

I have concluded that the email verification (couldn't find anything either) is really out of the scope of this module.

NancyDru’s picture

Status: Needs work » Needs review
gpk’s picture

Looks good, not tested yet so leaving at CNR.

NancyDru’s picture

It is on my live high-volume site.

GreenReaper’s picture

This is great! Is there a way to make it work with the AJAX Comments module? Right now comments posted with it seem to bypass this.

NancyDru’s picture

I don't have the time to do that, but maybe someone else can.

doktorrr’s picture

Is this worth for Drupal 5? I want to my anonymous users can't post comments without verified email.

khanz’s picture

Version: 6.x-1.1 » 6.x-1.x-dev

any update??

TheoRichel’s picture

I have applied this patch against version 6.x-1.x-dev of the module, and when I enable the module I get this message:

// Definitions for missing functions in Windows (bah) // See: http://drupal.org/node/508004 // http://www.php.net/manual/fr/function.getmxrr.php#88033 // getmxrr() support for Windows by HM2K function win_getmxrr($hostname, &$mxhosts, &$mxweight=false) { if (strtoupper(substr(PHP_OS, 0, 3)) != 'WIN') return; if (!is_array ($mxhosts) ) $mxhosts = array(); if (empty($hostname)) return; $exec='nslookup -type=MX '.escapeshellarg($hostname); @exec($exec, $output); if (empty($output)) return; $i=-1; foreach ($output as $line) { $i++; if (preg_match("/^$hostname\tMX preference = ([0-9]+), mail exchanger = (.+)$/i", $line, $parts)) { $mxweight[$i] = trim($parts[1]); $mxhosts[$i] = trim($parts[2]); } if (preg_match('/responsible mail addr = (.+)$/i', $line, $parts)) { $mxweight[$i] = $i; $mxhosts[$i] = trim($parts[1]); } } return ($i!=-1); } // Define if (!function_exists('getmxrr')) { function getmxrr($hostname, &$mxhosts, &$mxweight=false) { return win_getmxrr($hostname, $mxhosts, $mxweight); } } // http://www.php.net/manual/fr/function.checkdnsrr.php#82701 if(!function_exists('checkdnsrr')){ function checkdnsrr($host, $type=''){ if(!empty($host)){ $type = (empty($type)) ? 'MX' : $type; exec('nslookup -type='.$type.' '.escapeshellcmd($host), $result); $it = new ArrayIterator($result); foreach(new RegexIterator($it, '~^'.$host.'~', RegexIterator::GET_MATCH) as $result){ if($result){ return true; } } } return false; } } any explanation or suggestions?

DrewMathers’s picture

oadaeh’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

Due to Drupal 6's EOL, I am closing this with "won't fix." If you feel this is still valid for any of the 7.x branches, feel free to re-open and update this issue.