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?
Comment | File | Size | Author |
---|---|---|---|
#17 | support-webform-4.x-1677236.patch | 3.23 KB | hackwater |
Comments
Comment #1
jerry CreditAttribution: jerry commentedThanks for the patch.
Comment #2
likewhoa CreditAttribution: likewhoa commentedworks for me.
Comment #3
shigeruw CreditAttribution: shigeruw commentedThanks, it works!
Comment #4
erykolryko CreditAttribution: erykolryko commentedThanks 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.
Comment #5
mxwitkowski CreditAttribution: mxwitkowski commentedHi, 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.
Comment #6
jerry CreditAttribution: jerry commentedDid you apply the patch in the issue summary?
Comment #7
mxwitkowski CreditAttribution: mxwitkowski commentedYes, the patch in the issue summary was applied
Comment #8
jerry CreditAttribution: jerry commentedWonder 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.
Comment #9
mxwitkowski CreditAttribution: mxwitkowski commentedHi -- 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 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?
Comment #10
mxwitkowski CreditAttribution: mxwitkowski commentedHi - 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
Comment #11
jerry CreditAttribution: jerry commentedThanks 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.
Comment #12
TolliSysDev CreditAttribution: TolliSysDev commentedHi,
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!
Comment #13
jerry CreditAttribution: jerry commentedI've opened an issue in the main Webform queue regarding this.
Comment #14
trevorleenc CreditAttribution: trevorleenc commentedok, 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,
add this code back in
hope this helps anyone else running into this issue.
Comment #15
lasseitorp CreditAttribution: lasseitorp commentedStill 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!
Comment #16
JordanMagnuson CreditAttribution: JordanMagnuson commentedApplied the patch in #5, but didn't seem to do anything for me (using webform 4.x).
Comment #17
hackwater CreditAttribution: hackwater commentedJordan, 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 oftitle
s per #2221039: Inline elements on the admin page produce confusing markupComment #18
hackwater CreditAttribution: hackwater commentederykolryko, 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.
Comment #19
deggertsen CreditAttribution: deggertsen commentedPatch in #17 works! Thank you.
Comment #20
GiorgosKgreat #17 applies cleanly and works for latest dev version
https://drupal.org/project/webform
can anyone commit this ?
Comment #21
GiorgosKactually the modified version works for 4.x webform
but it does not work for 3.x webform
so it "needs work"
Comment #22
deggertsen CreditAttribution: deggertsen commentedI 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.
Comment #23
hackwater CreditAttribution: hackwater commentedThe 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.
Comment #24
hockey2112 CreditAttribution: hockey2112 commentedThe patch worked for me, thanks!
Comment #26
jerry CreditAttribution: jerry commentedFixed in 7.x-2.0. Thanks, hackwater, and sorry for the delay in posting a new version.
Comment #27
hackwater CreditAttribution: hackwater commentedNo problem, and thank *you*