While we wait for webform_reply_to to be integrated within Webform (see http://drupal.org/node/1462192), I've started rolling out a site that is using the Webform 4.x alpha version (I wanted the Webform Conditional functionality). I noted that the API changes in the way Webform sets up the email edit form broke webform_reply_to, so I cobbled together a quick patch that might be useful for anyone getting Undefined index: node in webform_reply_to_form_alter or similar when trying to get the module to work.

I'm not sure if there are negative implications to grabbing the $node object from the $form variable instead of the $form_state in the webform_reply_to_form_submit function, but it seems to have correctly associated the node with the webform so that the webform_reply_to module can grab the email address component.

The 4.x Webform module no longer assigns a value key to the $submission object's data property array, so I had to modify the webform_format_reply_to_address function; I tried to match the webform module's webform_format_email_address function, since it was clearly the template for the webform_reply_to version, and since it provided an easy way to support more than one reply-to address (technically possible, at least per the RFC's section 4.4.3).

Perhaps we need a branch to support Webform 4.x while integration issues are worked out?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jerry’s picture

Thanks for the patch.

likewhoa’s picture

Status: Active » Reviewed & tested by the community

works for me.

shigeruw’s picture

Thanks, it works!

erykolryko’s picture

Thanks it works for me too however i want to add more than one email in the reply field and that is not being picked up.

mxwitkowski’s picture

Hi, I tried using this module with Webform 7.x-4.0-alpha10 and am unsuccessful. There are no text fields to enter reply-to address information. Screen shot attached.

jerry’s picture

Did you apply the patch in the issue summary?

mxwitkowski’s picture

Yes, the patch in the issue summary was applied

jerry’s picture

Wonder if the patch needs a re-roll against the current Webform 4.x alpha? I don't have that deployed anywhere at the moment; perhaps hackwater can comment.

mxwitkowski’s picture

Hi -- I did some extensive research here and found that the issue was introduced in the Alpha 9 version of the Webform module. Specifically, in the Alpha9 webform.module code, lines 3176 through 3178 were removed:

  if (isset($element['#inline_element'])) {
    $output .= ' ' . $element['#inline_element'] . "\n";
  }

If I add these back into the webform.module code I am able to see the webform_reply_to fields.

So, I am not sure of the next steps and unsure how to modify the webform_reply_to code to accommodate this change or if it is best to re-introduce this code back into the webform module?

Thoughts?

mxwitkowski’s picture

Hi - another update. I verified that the latest webform module 7.x-4.0-beta1 has shifted the code lines a bit -- the code in comment #9 above would now located at line 3348 of webform.module

jerry’s picture

Thanks for the research. Longer-term, it sounds as though we need to open an issue in the Webform queue to get that logic restored. Since you've done the work in tracking it down the problem, you're the logical person to do this. Please post a link to it here for others to follow.

TolliSysDev’s picture

Hi,

Is there a solution for the issues identified in comments #5 and #9? I am using Webform 7.x-4.0-beta1 and the do not have any text fields to enter the Reply To information.

I would really love to get your great module working with Webform 7.x-4.0-beta1.

Thanks!

jerry’s picture

Status: Reviewed & tested by the community » Needs work

I've opened an issue in the main Webform queue regarding this.

trevorleenc’s picture

ok, I've just run into this again...and of course with the changes to webform, the lines given in #10 are once again wrong...so I figured it out...

find this function "function theme_webform_inline_radio($variables) {"

and right towards the end of if, before the following,

$output .= "</div>\n";

  return $output;

add this code back in

  if (isset($element['#inline_element'])) {
    $output .= ' ' . $element['#inline_element'] . "\n";
  }

hope this helps anyone else running into this issue.

lasseitorp’s picture

Still no way to enter Reply-To address using Webform 7.x-4.0-RC1+0-dev & Webform Reply-to 7.x-1.0+3-dev.

Any ideas? Thanks!

JordanMagnuson’s picture

Applied the patch in #5, but didn't seem to do anything for me (using webform 4.x).

hackwater’s picture

Status: Needs work » Needs review
FileSize
3.23 KB

Jordan, I assume you meant the patch in the issue summary. I've re-rolled the patch against webform_reply_to's latest dev, using the RC3 release of Webform 4.x. In limited internal testing, reply-to header is correctly set, but I'd love some additional testing (and patches). Biggest difference in Webform 4.x since Webform Alpha4 (the release against which I created the original parch) that impacts this patch is that the inline_element attributes were removed in favor of titles per #2221039: Inline elements on the admin page produce confusing markup

hackwater’s picture

erykolryko, I believe the webform_reply_to validation function may be the source of the multiple addresses not being picked up, but I haven't had the time to look deeply into this. I suspect adapting the webform module's algorithm for multiple addresses will take care of the problem.

deggertsen’s picture

Patch in #17 works! Thank you.

GiorgosK’s picture

Status: Needs review » Reviewed & tested by the community

great #17 applies cleanly and works for latest dev version
https://drupal.org/project/webform

can anyone commit this ?

GiorgosK’s picture

Status: Reviewed & tested by the community » Needs work

actually the modified version works for 4.x webform
but it does not work for 3.x webform
so it "needs work"

deggertsen’s picture

Category: Support request » Task
Status: Needs work » Needs review

I think the best solution for it not working with 3.x would simply be to create a new 2.x branch and make it clear that 1.x is for webform 3.x and 2.x is for webform 4.x. To try and put in conditionals into the code to determine if you are running webform 3.x or 4.x seems cumbersome and unnecessary. The patch works for webform 4.x so lets create a new branch that works with 4.x instead of scrapping the whole thing simply because it's not backward compatible when we already have a release that works with 3.x.

hackwater’s picture

The whole point of the patch is to provide support for Webform 4.x's API changes (thus the title of the issue). It's a compatibility fix; the existing module works great with Webform 3.x, since there haven't been major API changes there.

I agree that a new 2.x branch (or 4.x, if we want to coordinate with/match whichever Webform branch we're compatible with) would probably be best, but I leave that to the module maintainer.

hockey2112’s picture

The patch worked for me, thanks!

  • jerry committed dfb4183 on 7.x-2.x
    Issue #1677236 by hackwater: Updated for compatibility with Webform 7.x-...
jerry’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Assigned: Unassigned » jerry
Status: Needs review » Closed (fixed)

Fixed in 7.x-2.0. Thanks, hackwater, and sorry for the delay in posting a new version.

hackwater’s picture

No problem, and thank *you*