Checking "Must confirm this email address" is not saved and resets to off when saving the field.

Comments

Anonymous’s picture

I should add that I am using Webform 3.1

brunodbo’s picture

StatusFileSize
new637 bytes

Using Drupal 6.19, Webform 6.x-3.2 and the latest dev version of Webform Confirm Email Address.

It seems the structure of the form array has been changed, and _webform_confirm_email_component_submit() is still counting on the former form array structure.

Attached patch fixes this, and the setting is saved. I changed, on line 118:

if ($form_state['values']['must_confirm'])

to

if ($form_state['values']['advanced']['must_confirm'])
brunodbo’s picture

Status: Active » Needs review
quasi’s picture

What are the chances of seeing a version supporting Webform 3.x?

Thank you!

quicksketch’s picture

An alternative to this module is using the very excellent Webform Validation module, though not nearly as straight-forward.

quasi’s picture

Hey quicksketch, would you be so kind and explain how your approach would look like?

quicksketch’s picture

Add two e-mail fields, then use Webform Validation to ensure that the value of the two fields is the same.

quicksketch’s picture

Title: Setting is not saved » Webform 3.x compatibility

Oh sorry I misunderstood what this module did. I thought it "confirmed" the e-mail address just by having the user type it twice. I didn't realize that it actually sent an e-mail for them to confirm. In which case, Webform Validation certainly isn't going to do that.

quasi’s picture

Thank you for your advice anyway!

quasi’s picture

Hey brunodbo,

your approach doesn't work for me, using Webform 6.x-3.2.

letzel’s picture

subscribe

Robin Millette’s picture

I am planning to port it to the current webform version. Just had too many things on my plate up to now but a client is starting to really need it.

Dutchie78’s picture

What version of webform/drupal did you build it on Robin?

Robin Millette’s picture

Assigned: Unassigned » Robin Millette
StatusFileSize
new5.74 KB

Here's what I have, tested with Drupal 6.19, and Webform 6.x-3.4 on PHP 5.2.6.

You're going to have to disable, uninstall and completely remove the old webform_confirm_email if you want to use this right now. See the README in the tarball. I'll wait for a few confirmations that it works as advertised before releasing it officially on drupal.org. This tarball is just a short term solution:

http://rym.waglo.com/code/drupal/webform_confirm_email-6.x-3.x-dev.tar.gz

I've also attached the module, but I may make small changes to the tarball hosted at rym.waglo.com.

This version is a complete rewrite of the previous module. The interface (what little it has) has completely changed, hopefully for the better. The code should also be a little saner, mostly with how I deal with sending confirmation emails.

Dutchie78’s picture

on submit get Fatal error: Cannot use string offset as an array in webform_confirm_email.module on line 19

Looking in the code, the hook webform_confirm_email_mail_alter gets a parameter $message, which is expected to be an array, but is a string 'webform'.

***
*** EDIT: Nm, mime mail 1.0 alpha3 was causing the error
***

Dutchie78’s picture

webform_confirm_email-6.x-3.x-dev works fine on :
Drupal 6.15
Webform 3.4

jonjob’s picture

Drupal 6.16
Webform 3.4
PHP 5.2.5

I can't get the message type to change from 'always'. Every time I select 'confirmation' and save, it reverts back to 'always'. The %confirm_url token isn't working either. The email that gets sent just contains the word '%confirm_url'. The '%confirm_url' token is showing in the available token values correctly.

Robin Millette’s picture

@Dutchie78, fiou, thanks for the report. Regarding mime mail 1.0 alpha3, I didn't test with mimemail at all. I will keep that in mind before I release the module. Did the alpha3 interfere with webform_confirm_email or did the bug have nothing to do with my module?

@jonjob Sounds like the module didn't go through the install process to create its new database table. Make sure you uninstall it http://example.com/admin/build/modules/uninstall and reinstall it properly. This version didn't supply an upgrade path, sorry about that.

jonjob’s picture

I've removed all traces of the old module and tried re-installing but it doesn't work. Installing the module isn't creating the database table. When I tried to uninstall from your advice above it didn't work either. The database table of your older version was still there (it was missing the 'eid' column)

Robin Millette’s picture

Status: Needs review » Active

@jonjob Strange... I guess that's why there is debugging.

The module should create 3 tables:
webform_confirm_email_code
webform_confirm_email_conditional
webform_confirm_email

It's only luck if the webform_confirm_email table is similar in both versions. I barely peeked at the old code to write this version.

Is there a reason you're using Drupal 6.16? I don't see why, but it could explain the difference. If you can upgrade, I'd be curious to know if that fixes the problem. But don't feel like you have to upgrade, we will figure it out either way.

Do you have the devel module? You could use that to reinstall the webform_confirm_email module. Be careful not to reinstall the wrong module since that will reset all its configuration. Which is exactly what we need to do in this case with webform_confirm_email.

Did you try creating another Webform or did you only try to configure a Webform you had before trying this upgrade? It should work either way, but I'm trying to get as much information as possible. I could also provide you with a tiny custom module that would help me gather the necessary information to debug this problem. But with the above, it might already be solved.

Symphonie’s picture

Hi Robin, I had the same problem as jonjob mentioned earlier.

I am using:
Drupal: 6.19
Webform: 6.x-3.4
Webform Confirm Email Address: 6.x-3.x-dev
PHP: 5.2.13

I have created two 'E-mail to' messages, the first message to be sent to the webadmin email address and the second message to be sent to the submitter's email address.

I tried to set the second message as a 'Confirmation' type message, but the radio button kept defaulting back to 'Always'. Also, as jonjob mentioned, the $confirm_url token in the received email appears as text, i.e. it is not interpreted as a link.

However, when I selected 'Component Value' as 'Email Address' BEFORE creating the submitter's 'E-mail to' message, the 'Confirmation' type radio button would stay on and the $confirm_url token would then display correctly as a link in the confirmation message received by the submitter. Therefore, it seems that the workaround for this problem is to first select the Component Value: Email Address, and then add the submitter's 'E-mail to' message.

Perhaps there should be a warning about this, or the code amended to allow changing the message type of an 'E-mail to' message even after it has been added.

Symphonie’s picture

Another problem I have come across:
I have tried setting the first 'E-mail to' message to the webadmin's email address as a 'Conditional' message type, but the submission email is sent regardless of whether the submitter has verified their email address using the $confirm_url link. I would like the webadmin's email to be sent ONLY IF the submitter has confirmed their email address.

By the way, I have checked the database table 'webform_confirm_email_conditional' but no records have been written to the table. I have two warning messages displayed in the database:

Table 'webform_submitted_data' shows 'PRIMARY and INDEX keys should not both be set for column `nid`'

and

'webform_submissions' shows 'PRIMARY and INDEX keys should not both be set for column `sid`'

Could you tell me if I am missing something in order to get the 'Conditional' message to work as described above?

Also, is there a way of showing whether the submitter has confirmed their email address in the Webform Results Submissions page for each individual submission?

This will be a fabulous and much needed module when these teething problems have been resolved. Thank you, Robin, for putting in all the hard work to make this module available.

Robin Millette’s picture

Hello Suzy,

Your comments are going to be very helpful. I will be looking into it this week-end. First, I need to upgrade my client's install and see if there are any problems there.

I will pay better attention to the upgrade path.

jonjob’s picture

I've now upgraded to drupal 6.19 and went through the process of removing the module and re-installing it.
I'm still not getting the database tables created:

webform_confirm_email_code
webform_confirm_email_conditional
webform_confirm_email

I'm also getting the issue where checkboxes aren't saving the checked state (which was down to the database table non-creation)

Is there a sql file that i could use to manually create them? I'd really like to give the module a try
Thanks

Robin Millette’s picture

Version: 6.x-2.x-dev » 6.x-3.x-dev

New 3.x branch is up: http://drupal.org/node/971748 I was a bit sloppy dealing with the database table prefix it seems. Hopefully, I fixed all that.

jonjob’s picture

Hi Robin,
Still no joy I'm afraid. I removed all traces of older modules and installed 6.x-3.x-dev but the tables are still not being created and I can't get the checkbox to change from 'Always'. I've installed a couple of other modules after upgrading to 6.19 and they went in OK.
Thanks

Symphonie’s picture

Robin, thanks for publishing the new release.

I also removed all webform components, removed the previous Webform Confirm Email Module and ran the uninstall process.

I noticed that the three database tables listed above were removed as part of the uninstall process. I installed the latest 6.x-3.x-dev release and the three database tables were created. I set up the webform components again and configured the two 'E-mail to' messages, one as a 'Confirmation' type and one as a 'Conditional' type as described in my earlier post. I checked that both message types were inserted into the webform_confirm_email table shown as message types 1 and 2 respectively.

When testing the form submission, there was no change to the previous process. Both messages were received at the same time and the confirmation type message did not stop the conditional message from being sent. The confirmation type message that was submitted was inserted into the webform_confirm_email_code table with data entries for nid, sid, eid, email address and url token. No data was inserted into the webform_confirm_email_conditional table. I am using MySQL version 5.0.77 and PHP 5.2.13.

The only function I seem to be missing is the confirmation type message to stop the conditional type message from being sent until the confirmation message has been verified by the submitter.

An added bonus would be a flag of some kind in the Drupal Webform results submissions table to show when an email address has been validated by a conditional message.

Many thanks.

cheyer’s picture

I can confirm the behaviour mentioned by Symphonie. I have exactly the same issue. Both mails will always be sent immediately, although I set one mail on confirmation and the other one on conditional.

I also had the issue with the not stored selection of confirmation or conditional values, but only with the existing email configuration. I deleted it and set two new ones and the problem disappeared.

drupalok’s picture

i tried this too... not working for me... so is anyone working on this at the moment?
thanks for your efforts!

sqeph’s picture

I have the same problem – confirmation and conditional mail are both sent out at once.

If there is a confirmation mail and a conditional mail going to the same e-mail address, it seems important that they have different subject lines... Otherwise the function webform_confirm_email_get_email_info() (or rather the database query within) seems unable to distinguish between the two... which in my case (I had left subject to default for both mails) meant that both e-mails received the same $email_type (1) in webform_confirm_email_mail_alter() and nothing would be written to the webform_confirm_email_conditional table.

After changing the subject line, my conditional mail gets written into webform_confirm_email_conditional but because we are using Mimemail the mail is still sent out right away...

On line 272 of webform.submissions.inc (Webform), $message is prepared with drupal_mail() which invokes the hook_mail_alter and changes $message['to'], but then on line 275, mimemail() gets its To-address from the unmodified $adress rather than $message.

Any other ides on how to stop an mail from being sent (from within Webform Confirm Email)?

EDIT: Changing line 275 of webform.submission.inc (Webform module)...

$message = mimemail($email['from'], $address, $message['subject'], $message['body'], !$email['html'], $email['headers'], $email['html'] ? NULL : $message['body'], $attachments, 'webform');

...to...

$message = mimemail($email['from'], $message['to'], $message['subject'], $message['body'], !$email['html'], $email['headers'], $email['html'] ? NULL : $message['body'], $attachments, 'webform');

...does seem to get Webform Confirm E-Mail Address working with Mimemail as well... but maybe there is a prettier solution. Also, not sure yet if there are other implications from this...

matthias_mo’s picture

Hi folks,

Robin gave me co-maintainer rights on this module - I'm currently checking the issue queue.

My focus is currently on the Drupal 7 version only. If D6 issues are still important to you please tell me so, otherwise I'd just close them and provide a 7.x-1.x version and fix all issues there.

So please give me a short feedback.

regards
matthias

Robin Millette’s picture

Assigned: Robin Millette » Unassigned

I'm neither using nor developing this module anymore, but Matthias is taking over.

matthias_mo’s picture

On line 272 of webform.submissions.inc (Webform), $message is prepared with drupal_mail() which invokes the hook_mail_alter and changes $message['to'], but then on line 275, mimemail() gets its To-address from the unmodified $adress rather than $message.

It has nothing to do with the subject line nor the "To" address nor mimemail.

In Drupal 6 you can't stop Drupal from sending an email in hook_mail_alter. What we could do is to delete the mail header but then we'll get error messages in the log.
I'm working on a solution ...

matthias_mo’s picture

Status: Active » Closed (fixed)

please get the latest git version that should fix the problem.