First off, let me take this opportunity once again to thank Coleman for this fantastic module! It almost makes setting up CiviCRM fun.

Almost.

OK - here's the deal... and I think I've narrowed it down pretty well:

I've applied the patch from http://issues.civicrm.org/jira/browse/CRM-8608 to get subscription confirmations to work - I have a webform (let's call it #1) with First Name, Last Name, Email, Zip Code and Phone number - and it works fine. The email is sent out and the confirmation process goes smoothly. Great!

I have another webform in the same site that I've exposed as a nodeblock - for this small webform, I'm requesting Email and Zip Code only, as well as subscribing to a public group. Let's call this webform #2. In this case, upon submission I get a message that says "Email unable to be sent. Contact the site administrator" (or somesuch) and the process fails.

Both records are accepted into the Civi DB, but with #2, the name field is blank, instead of having the email as the name.

In the case of #2, I'm doing one of those cute little enewsletter signup boxes in the top banner of the site, so asking for any additional information would blow it.

This looks like a Civi thing, and not a Webform Civi thing, but insofar as Coleman has done so much terrific work in this area, I thought I'd ask here: Is the process failing because Civi wants more information for a double opt-in? I would think this would be a pretty standard use case.

This is with the latest versions of everything - Drupal 7.12, Civi 4.0.8 and OpenPublic beta 5.

My Civi entry is posted at http://forum.civicrm.org/index.php/topic,23420.msg98374.html#msg98374 and I'll cross post this over there as well - any guidance would be most appreciated... thank you!

Comments

bcobin’s picture

bcobin commented

In this case, upon submission I get a message that says "Email unable to be sent. Contact the site administrator" (or somesuch) and the process fails.

This was because the client was changing the email account as I was working! But the basic issue is unchanged, though - there's no longer an error message but the email simply isn't sent in case #2, whereas it is in #1. Thanks!

colemanw’s picture

colemanw commented

I'm a little unclear about what exactly is failing in the double opt-in form #2. Is the contact being created? Is the email being sent? Is the contact added to the group with status "pending"?

bcobin’s picture

bcobin commented

Thanks for the response, Coleman!

Yes - the contact is created with status pending (by Email) and the notification email is sent to the site admin. It's the confirmation email that never gets sent. Another anomaly here is that the name field is blank on the Find Contacts page, whereas other contacts with email only use the email in the name field.

I've tried it again and watchdog shows the following error:

Notice: Undefined variable: fieldIDs in CRM_Core_BAO_CustomValueTable::getValues() (line 605 of /[site]/sites/all/modules/civicrm/CRM/Core/BAO/CustomValueTable.php).

Here's the section of code in question (line 605 is the last line):

$values = self::getEntityValues( $params['entityID'],
                                         $type,
                                         $fieldIDs );

It feels like we're close here - perhaps there's a clue in the Civi patch...

colemanw’s picture

colemanw commented

Before I dive into this, try upgrading to the latest version of Civi (4.1) and this module (2.4 which is still in -dev, but get the one I just committed to, which will be dated Feb 17th). You'll need to run update.php as well. It has a new approach to groups and tags which is more flexible and doesn't rely on those dumb hidden fields.
I can't promise the -dev is 100% bug free but I really want to get it released, so another pair of eyes on it would help me, even if it doesn't help with your subscribe problem :)

bcobin’s picture

bcobin commented

Thanks, Coleman - I've upgraded to 4.1 and installed the latest dev.

I'm running into a problem that was there before, but now it's much worse: settings don't seem to "stick." After every change, you must clear caches to see the changes. For example, when I originally created webforms in the "old" version, the Civi fields wouldn't appear - saving seemed to do nothing. I wold then add them again. After clearing caches, you'd see two of each field - once one was deleted things seemed to work.

But now, it's much worse - you really have to clear caches after every change, and even then, it's unclear. The master "Enabled" checkbox stays on even if it's saved as "off," which means preset default fields (e.g., "Home" or "Main") appear on the form regardless. Not soup yet, unfortunately.

If, as I take it, it's necessary to use the dev version for 4.1, we have a problem. Can I roll back? Will that work? Thanks, Coleman...

colemanw’s picture

colemanw commented

Hmm, there was a bug along those lines, but I fixed it yesterday. Are you sure you're using the latest dev? Dated Feb 17?

colemanw’s picture

colemanw commented

And yes, previous versions of this module are not compatible with 4.1. But let's get any outstanding bugs fixed rather than trying to roll back.

bcobin’s picture

bcobin commented
Version: 7.x-2.3 » 7.x-2.x-dev

Yup - downloaded it this morning. Perhaps the change hasn't made it to the dev version yet? Hmmm...

(Also changing the version to dev - change it back if you like...)

bcobin’s picture

bcobin commented
Status: Active » Closed (fixed)

Problem resolved - see http://forum.civicrm.org/index.php?topic=23420.0

Looks like this was a sandbox issue - the site when deployed to IP does, indeed, send out the confirmation email. Marking this as fixed.