Benjain - is there a good page that details the differences between 2.x and 3.x for webform? I'm not familiar with it, but am open to programming the ability to use 3.x into the module.
Version 3 of Webform boasts incredibly powerful new features including:
- Webforms can now be attached to multiple content types.
- E-mail templates are now editable by administrators through the UI.
- Conditional field logic in multipage forms.
- Public API for allowing other modules to provide components.
- Public API for interacting with submission save, insert, update, and delete.
- New rendering capabilities for HTML presentation of submissions and e-mails.
Please note that APIs are still subject to change during the beta period.
It sounds like the API could make things more simple to integrate with. I don't think I'm the right person to update the Salesforce Webform module to be compatible with Webform 3.x, but I'll certainly help test patches when they're available.
@courtney - thanks for the additional info; what would be really helpful is a guide to the API itself. I knew an API was coming, but haven't had the time to go digging for the docs as to what it entails.
Most likely, support for 3.x webform would need to go into a 6.x-2.x version branch of this module.
Sorry, I can't find an Webform 2.x to 3.x API upgrade guide of any sort either. Unfortunately the Webform documentation not only has nothing like this but is mostly 2.x anyway.
I think the only documentation on the code will be in the code itself (and usually, by quicksketch, quite well done).
Thanks for posting this. A question since I don't have time to try it out tonight - does the patch render 2.x compatibility useless, or would it work with both 2.x AND 3.x within one version?
Posted by pweinsteinmei on November 5, 2010 at 5:52pm
I'm also trying to use Webform 3.x. The biggest roadblock I've hit is the fact that the "Additional Processing" field is gone but that additional step still needs to happen. Is there any workaround for either 6.x-1.x-dev or 6.x-1.2 that does NOT involve using Webform PHP? The author of that module makes a pretty good case for not using it, and my IT guys also don't want us to use it. I've tried my best to look around for a solution and I'm surprised to see that no one else has discussed this. What do you think?
Thanks!!
Posted by chriscalip on November 5, 2010 at 6:29pm
Several things so far:
1. you can fork webform and add the salesforcewebform code.
2. you can figure out if the webform 3 has an api hook to do additional processing and then do a patch for salesforcewebform.
Posted by GinkgoFJG on November 17, 2010 at 7:14pm
Just wanted to chime in and say that chriscalip's patch in post #11 applied cleanly for me and that everything seems to be in working order with Webform 3. I'd also like to +1 for the patch to be committed so that future upgrades don't cause things to break.
I've applied the patch in #11 and branched the 6.x-1.3 code into a new, 6.x-2.x branch. The code in the 1.x branch will only be compatible with Webform 2.x. The code in the 2.x branch will only be compatible with Webform 3.x. A -dev release will be available the next time the packaging script runs on Drupal.org.
A huge thanks to Chris Calip for the patch. Could anyone interested in 3.x compatibility download & install the -dev version to confirm it before I release a stable 6.x-2.0? It works here for me, but I always like further confirmation.
@amanire - thanks, I thought I had committed the updates to the README, INSTALL, and module .info files that stated the requirements for the 2.x branch. Those documentation updates will show up in the next dev tarball.
Hello,
I hope it is the right place to ask, else please forgive me...
I have a "WSOD" anytime I try to enable Salesforce Fields module. The only way to get Durpal working again is to disable the module by editing the DB system table manually to disable Salesforce Fields.
It used to work previously. I did check that my SFDC login info and Token are right, so I suspect this broke up since there's been an upgrade of the Webform module.
My current webform version is 6.x-3.6
Can you confirm that my issue is linked to an incompatibility between Salesforce webform and version 6.x-3.6 of Webform?
Otherwise, would installing "Webfor PHP module" as mentioned in #15 be a solution?
Posted by chriscalip on January 27, 2011 at 8:48pm
Hi danmed,
Confirmed you have to do the following things:
install webform php module.
install version 2.dev of salesforcewebform found at: http://drupal.org/node/1010090
Hello Chris,
thanks for your answer.
I started gathering resources to do as you indicated, then noticed the warnings on the webform php module page. Quicksketch advices to put code for additional processing in a module, which I am going to try to do.
The code in question is:
Posted by chriscalip on February 1, 2011 at 6:09pm
Hi Danmed,
Quicksketch gave you the right advice and here's how you implement it.
a. Your gonna have to add the code in each webform node that you want the salesforce integration.
For example node 1 is a webform go to the configuration page and click the advanced php processing fieldset and insert the code in Additional processing.
I installed the webforms3 and the current 6.x-2xdeb branch and everything seems to be working.
I removed the webform_php requirement and added a 2nd submit handler to handle the "Additional Processing".
At the top of salesforcewebform.module, right under the ini_set I added the additional submit handler:
ini_set("soap.wsdl_cache_enabled", "0");
//BEGIN NEW CODE // Additional Processing during submit function salesforcewebform_client_submit($form, &$form_state) { $node = node_load($form_state['values']['details']['nid']); $form_state = salesforcewebform_process($node, $form, $form_state); } //END NEW CODE
And modified the first function (salesforcewebform_form_alter) as follows:
/** * Allow for editing webforms with SalesForce connection information and modifying the * each webform to post to SalesForce. */ function salesforcewebform_form_alter(&$form, &$form_state, $form_id) { // handle webform client forms (instances of webforms that are submitted) // webform names client forms with the pattern web_form_client_form_$nid, use this knowledge to // manipulate the forms that webform displays if ( ereg('^webform_client_form_', $form_id) ) {
global $base_url; $node = $form['#parameters'][2];
// only deal with this form if it is supposed to go to SalesForce if ( empty($node->use_salesforce) ) { return ; } // BEGIN NEW CODE // Add the submit handler after the existing Webform submit handler, // but before the second Webform handler. Pop off the first one and add // ours second. $first = array_shift($form['#submit']); array_unshift($form['#submit'], $first, 'salesforcewebform_client_submit'); // END NEW CODE }
...
For brevity, I only included the first If statement in the function.
Basically, if it is a webform, and it is flagged for use_salesforce, it adds the additional submit handler, which is the additional processing from the INSTALL.txt.
Nice idea! on #23 I think we can further improve on the code with having the additional salesforcewebform_client_submit only on salesforce activated webform nodes. Just in case no one has generated a patch for it yet by this weekend; I'll whip up the patch this weekend.
It already has that, it only adds the additional submit on sales force activated webforms.
That's why I added the code after the use_salesforce check:
<?php // only deal with this form if it is supposed to go to SalesForce if ( empty($node->use_salesforce) ) { return ; } ?>
If it's not a sales force form it will return before adding the additional submit.
Thanks for generating the patch :)
Actually, looking at the original code I pasted, it looks like it has a bug in it, it's only checking if it's empty, it should probably be checking if it is empty or set to no, correct?
This is a patch based on #23 suggestion to remove webform_php as a requirement. A few differences between the code above @ comment #23 and the patch. Added function definition of salesforcewebform_client_submit below function salesforcewebform_form_alter. Function salesforcewebform_client_submit takes advantage of the node object already found @
$form['#parameters'][2].
More importantly this a question for Bryan O'Shea/Obsidian Design this patch will now essentially "not" give the form_state processed by salesforce to webform. Is this okay?
Old version has $form_state modified by salesforcewebform to be processed by webform, while this patch does not.
If thats okay.. then please review and improve patch.
Just curious but isn't the form_state being passed by reference? &$form_state? Shouldn't that pass whatever changes salesforcewebform_process makes back to webform?
I've only been playing around with PHP and Drupal for about a week or so, so forgive me if this is a silly question.
Not a silly question at all; I did comment #26 because I also am not really familiar with the webform and salesforcewebform code flow. I just want to prod things along without spending too much time.
But darn it you prove my assertion @ comment # 26 is wrong :P I am glad that I am wrong. Yup form_state is being passed by reference and that will pass whatever changes from salesforcewebform process back to webform. heheh good catch dude!
Also confirmed on a sandbox that the assumption is right.
I added a bug for this same line, should this line also be checking if the value is set to false?
<?php // only deal with this form if it is supposed to go to SalesForce if (!isset($node->use_salesforce) || $node->use_salesforce == null) { ?>
Since we added the extra submit right after this check, I believe if use_salesforce is set to 0 it would pass both the above checks, and would add the salesforcewebform_client_submit.
<?php // only deal with this form if it is supposed to go to SalesForce if (!isset($node->use_salesforce) || $node->use_salesforce == null || $node->use_salesforce == FALSE) { return ; } ?>
I have committed changes to the 6.x-2.x dev branch this evening that bring Webform 3.x compatibility WITHOUT webform_php as an addon module and WITHOUT any extra processing code. It utilizes the webform 3.x hooks to achieve this.
It does not leverage the Salesforce Suite and remains a lightweight alternative. It is near stable, but I want to do some more checks before I create a 2.0 release. There are some other code changes that need to be wrapped in as well to truly meet Webform 3.x standards, but those are coding style changes more than substance changes.
A huge thank you to chriscalip and btlife for starting this and bringing it forward; I built on both of their code changes to make the changes committed tonight.
Comments
#1
Benjain - is there a good page that details the differences between 2.x and 3.x for webform? I'm not familiar with it, but am open to programming the ability to use 3.x into the module.
Bryan O'Shea
Obsidian Design
#2
I definitely need this. Webform 3.x is required for Mollom support, but we also submit to Salesforce.
From the Webform module releases page - http://drupal.org/node/7404/release
It sounds like the API could make things more simple to integrate with. I don't think I'm the right person to update the Salesforce Webform module to be compatible with Webform 3.x, but I'll certainly help test patches when they're available.
#3
@courtney - thanks for the additional info; what would be really helpful is a guide to the API itself. I knew an API was coming, but haven't had the time to go digging for the docs as to what it entails.
Most likely, support for 3.x webform would need to go into a 6.x-2.x version branch of this module.
Bryan O'Shea
Obsidian Design
#4
Sorry, I can't find an Webform 2.x to 3.x API upgrade guide of any sort either. Unfortunately the Webform documentation not only has nothing like this but is mostly 2.x anyway.
I think the only documentation on the code will be in the code itself (and usually, by quicksketch, quite well done).
And yes, we still need this!
#5
Hey,
So I needed this for a project I did in drifire.com
It turned out to be a quick patch to make the module to be webform.3.x compliant
Also you would need to install webform_php
Enjoy folks,
Chris Calip
#6
Hi Chris,
Thanks for posting this. A question since I don't have time to try it out tonight - does the patch render 2.x compatibility useless, or would it work with both 2.x AND 3.x within one version?
Bryan O'Shea
Obsidian Design
#7
I'm also trying to use Webform 3.x. The biggest roadblock I've hit is the fact that the "Additional Processing" field is gone but that additional step still needs to happen. Is there any workaround for either 6.x-1.x-dev or 6.x-1.2 that does NOT involve using Webform PHP? The author of that module makes a pretty good case for not using it, and my IT guys also don't want us to use it. I've tried my best to look around for a solution and I'm surprised to see that no one else has discussed this. What do you think?
Thanks!!
#8
Several things so far:
1. you can fork webform and add the salesforcewebform code.
2. you can figure out if the webform 3 has an api hook to do additional processing and then do a patch for salesforcewebform.
#9
will take a look see this afternoon
#10
Any update? Trying to get this working with webform 3.x for a current project. Thanks!!
#11
Yes the patch I posted a few days ago and this more cleaner patch does not work for webform 2.
#12
Just wanted to chime in and say that chriscalip's patch in post #11 applied cleanly for me and that everything seems to be in working order with Webform 3. I'd also like to +1 for the patch to be committed so that future upgrades don't cause things to break.
Thanks to you both!
-Frank
#13
I might be unclear all my patches are not webform 2 compliant. sorry.
#14
I've applied the patch in #11 and branched the 6.x-1.3 code into a new, 6.x-2.x branch. The code in the 1.x branch will only be compatible with Webform 2.x. The code in the 2.x branch will only be compatible with Webform 3.x. A -dev release will be available the next time the packaging script runs on Drupal.org.
A huge thanks to Chris Calip for the patch. Could anyone interested in 3.x compatibility download & install the -dev version to confirm it before I release a stable 6.x-2.0? It works here for me, but I always like further confirmation.
Bryan O'Shea
Obsidian Design
#15
Is the current 2.x-dev/patch from #11 supposed to require the Webform PHP module and the additional processing snippet described in INSTALL.txt?
It didn't work for me until I installed the module and added the code snippet.
#16
@amanire - thanks, I thought I had committed the updates to the README, INSTALL, and module .info files that stated the requirements for the 2.x branch. Those documentation updates will show up in the next dev tarball.
#17
Hello,
I hope it is the right place to ask, else please forgive me...
I have a "WSOD" anytime I try to enable Salesforce Fields module. The only way to get Durpal working again is to disable the module by editing the DB system table manually to disable Salesforce Fields.
It used to work previously. I did check that my SFDC login info and Token are right, so I suspect this broke up since there's been an upgrade of the Webform module.
My current webform version is 6.x-3.6
Can you confirm that my issue is linked to an incompatibility between Salesforce webform and version 6.x-3.6 of Webform?
Otherwise, would installing "Webfor PHP module" as mentioned in #15 be a solution?
Thanks for your answer.
#18
Hi danmed,
Confirmed you have to do the following things:
install webform php module.
install version 2.dev of salesforcewebform found at: http://drupal.org/node/1010090
kind regards,
Chris Calip
#19
Hello Chris,
thanks for your answer.
I started gathering resources to do as you indicated, then noticed the warnings on the webform php module page. Quicksketch advices to put code for additional processing in a module, which I am going to try to do.
The code in question is:
<?php
require_once(drupal_get_path('module', 'salesforcewebform') . '/salesforcewebform.module');
$form_state = salesforcewebform_process($node, $form, $form_state);
?>
I guess I should try to put it using hook_form_alter (?).
Any input welcome. if I get to a satisfying result I'll share my findings here.
Thanks,
DanMed
#20
Hi Danmed,
Quicksketch gave you the right advice and here's how you implement it.
a. Your gonna have to add the code in each webform node that you want the salesforce integration.
For example node 1 is a webform go to the configuration page and click the advanced php processing fieldset and insert the code in Additional processing.
Here's an example of a configuration url in node 1.
http://www.example.com/node/1/webform/configure
kind regards,
Chris Calip
#21
Hi obsidiandesign,
We also would need the support for v3 of webform. Thanks for all your work so far.
Kind regards,
Greg
#22
FYI, in the INSTALL.txt for 6.x-2.x-dev, it still says
"Under 'Form Settings' when editing the Webform, add the following code for 'Additional Processing':..."
[EDIT] Please disregard, I didn't understand the issue.
#23
I installed the webforms3 and the current 6.x-2xdeb branch and everything seems to be working.
I removed the webform_php requirement and added a 2nd submit handler to handle the "Additional Processing".
Found this article that worked nicely: http://www.drupalcoder.com/blog/additional-processing-in-drupals-webform...
At the top of salesforcewebform.module, right under the ini_set I added the additional submit handler:
ini_set("soap.wsdl_cache_enabled", "0");
//BEGIN NEW CODE
// Additional Processing during submit
function salesforcewebform_client_submit($form, &$form_state) {
$node = node_load($form_state['values']['details']['nid']);
$form_state = salesforcewebform_process($node, $form, $form_state);
}
//END NEW CODE
And modified the first function (salesforcewebform_form_alter) as follows:
/**
* Allow for editing webforms with SalesForce connection information and modifying the
* each webform to post to SalesForce.
*/
function salesforcewebform_form_alter(&$form, &$form_state, $form_id) {
// handle webform client forms (instances of webforms that are submitted)
// webform names client forms with the pattern web_form_client_form_$nid, use this knowledge to
// manipulate the forms that webform displays
if ( ereg('^webform_client_form_', $form_id) ) {
global $base_url;
$node = $form['#parameters'][2];
// only deal with this form if it is supposed to go to SalesForce
if ( empty($node->use_salesforce) ) {
return ;
}
// BEGIN NEW CODE
// Add the submit handler after the existing Webform submit handler,
// but before the second Webform handler. Pop off the first one and add
// ours second.
$first = array_shift($form['#submit']);
array_unshift($form['#submit'], $first, 'salesforcewebform_client_submit');
// END NEW CODE
}
...
For brevity, I only included the first If statement in the function.
Basically, if it is a webform, and it is flagged for use_salesforce, it adds the additional submit handler, which is the additional processing from the INSTALL.txt.
Hope this helps out
#24
Scott,
Nice idea! on #23 I think we can further improve on the code with having the additional salesforcewebform_client_submit only on salesforce activated webform nodes. Just in case no one has generated a patch for it yet by this weekend; I'll whip up the patch this weekend.
Cheers!
Chris Calip
#25
It already has that, it only adds the additional submit on sales force activated webforms.
That's why I added the code after the use_salesforce check:
<?php// only deal with this form if it is supposed to go to SalesForce
if ( empty($node->use_salesforce) ) {
return ;
}
?>
If it's not a sales force form it will return before adding the additional submit.
Thanks for generating the patch :)
Actually, looking at the original code I pasted, it looks like it has a bug in it, it's only checking if it's empty, it should probably be checking if it is empty or set to no, correct?
#26
Scott/btlife you making me work here :P
This is a patch based on #23 suggestion to remove webform_php as a requirement. A few differences between the code above @ comment #23 and the patch. Added function definition of salesforcewebform_client_submit below function salesforcewebform_form_alter. Function salesforcewebform_client_submit takes advantage of the node object already found @
$form['#parameters'][2].
More importantly this a question for Bryan O'Shea/Obsidian Design this patch will now essentially "not" give the form_state processed by salesforce to webform. Is this okay?
$form_state = salesforcewebform_process($node, $form, $form_state);Old version has $form_state modified by salesforcewebform to be processed by webform, while this patch does not.
If thats okay.. then please review and improve patch.
#27
If you guys are ok on the conditions and questions on comment #26 this is a patch that removes webform_php requirement.
#28
Please ignore 772102-Webform_3_x_compatibility-27.patch patch, this is a patch that removes webform_php requirement.
on the 6.x-2.x branch.
#29
Per comment #25 and http://www.zachstronaut.com/posts/2009/02/09/careful-with-php-empty.html
I think this patch will fix that bug.
#30
Just curious but isn't the form_state being passed by reference? &$form_state? Shouldn't that pass whatever changes salesforcewebform_process makes back to webform?
I've only been playing around with PHP and Drupal for about a week or so, so forgive me if this is a silly question.
Thanks
#31
Not a silly question at all; I did comment #26 because I also am not really familiar with the webform and salesforcewebform code flow. I just want to prod things along without spending too much time.
But darn it you prove my assertion @ comment # 26 is wrong :P I am glad that I am wrong. Yup form_state is being passed by reference and that will pass whatever changes from salesforcewebform process back to webform. heheh good catch dude!
Also confirmed on a sandbox that the assumption is right.
#32
Good to know, thanks for creating the patch, and looking into the form_state stuff!
#33
So far, #28 & #29 are working for me, though the patch failed on salesforcefields.info. 6.x-2.x release!
#34
I added a bug for this same line, should this line also be checking if the value is set to false?
<?php// only deal with this form if it is supposed to go to SalesForce
if (!isset($node->use_salesforce) || $node->use_salesforce == null) {
?>
Since we added the extra submit right after this check, I believe if use_salesforce is set to 0 it would pass both the above checks, and would add the salesforcewebform_client_submit.
<?php// only deal with this form if it is supposed to go to SalesForce
if (!isset($node->use_salesforce) || $node->use_salesforce == null || $node->use_salesforce == FALSE) {
return ;
}
?>
#35
Apply the lessons learned from the Salesforce Webform 3.x branch and apply to Salesforce Webform 2.x to make webform 3.x compatible
http://drupal.org/node/1146084
#36
#37
Subscribing
#38
I cant help out in 2.x branch see: http://drupal.org/node/1092344
#39
I have committed changes to the 6.x-2.x dev branch this evening that bring Webform 3.x compatibility WITHOUT webform_php as an addon module and WITHOUT any extra processing code. It utilizes the webform 3.x hooks to achieve this.
It does not leverage the Salesforce Suite and remains a lightweight alternative. It is near stable, but I want to do some more checks before I create a 2.0 release. There are some other code changes that need to be wrapped in as well to truly meet Webform 3.x standards, but those are coding style changes more than substance changes.
A huge thank you to chriscalip and btlife for starting this and bringing it forward; I built on both of their code changes to make the changes committed tonight.
Bryan O'Shea