Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Introduce a webform module callback
Comment | File | Size | Author |
---|---|---|---|
#26 | modal_forms-1326716-26.patch | 3.36 KB | frjo |
#25 | modal_forms-1326716-25.patch | 3.6 KB | fuerst |
#10 | modal_forms-webform-1326716-10.patch | 3.35 KB | larskleiner |
#2 | modal_forms-1326716-3.patch | 5.34 KB | mathieuhelie |
#1 | 1326716-webform.patch | 3.12 KB | andypost |
Comments
Comment #1
andypostThis patch adds 2 new menu items.
modal_forms/%ctools_js/webform/%node - to show and process webform
modal_forms/%ctools_js/dismiss - to dismiss window (suppose this is really useful addintion to the module
Webforms are changing #action of the form but have a hack for webform_block module.
Comment #2
mathieuhelie CreditAttribution: mathieuhelie commentedThe patch above did not apply properly, I fixed it up and added the missing administration features and javascript.
To use, you must rewrite the paths of your webform nodes to webform/nid from node/nid.
Comment #3
andypostAny reason?
I see no reason to replace all webform links with popups
Make all popups small is bad default without ability to override
Comment #4
mathieuhelie CreditAttribution: mathieuhelie commentedThe link rewriter that adds popups to contact forms or user registration forms detects /contact/ and /user/register/. The problem with webforms is that by default their path is /node/nid, which is true for all nodes, not only webform nodes. You need to set a path that is distinct from other nodes for your webforms to rewrite the links.
I arbitrarily decided it would be /webform/nid.
You don't have to activate the rewriting if you don't see a reason for it. It's a setting like the others. I cloned the rewriting of the contact form, which is why it says small modal.
Comment #5
fuerst CreditAttribution: fuerst commentedTried both patches on 7.x-1.0:
patch -p0
.patch -p1
.If automatic rewriting of Webform paths is optional it is a welcome addition, I think. Would be nice to have Webform node types get detected automatically.
Comment #6
andypost@fuerst I think having variable|table|field for webform to mark ajaxable is out of scope for this patch probably better make a custom module
Comment #7
fuerst CreditAttribution: fuerst commentedThat's right. For this issue I would suggest to go with #1.
Adding arbitrarily URL rewriting as #2 does to catch Webform nodes seems too special.
Comment #8
qoomir CreditAttribution: qoomir commentedHow to rewrite webform nodes to webform/nid from node/nid ?
Comment #9
osopolarWhat about multi step webforms?
I found in the patch the following, so I guess multiple steps (caused by a page break in webform) is not supported yet:
@todo Add support for redirect. Require some magic.
Comment #10
larskleiner CreditAttribution: larskleiner commentedI re-rolled patch #1 with added support for multistep webforms.
I also get a notice with patch #1 after form submits.
This is fixed by the patch here: http://drupal.org/node/1458540
Comment #11
osopolarThanks Lars, for this patch. I guess this is also a very helpful example for others doing forms (like node edit and comment forms with ctools modal), I'll link the ctools issue to this one.
Just one thing, looking at ctools_modal_form_wrapper seems to that we do not need// Fall back if $js is not set. ...
at the beginning of modal_forms_view_webform, but later in$form_state = array(...)
.[edit] I was wrong on this.
Comment #12
rv0 CreditAttribution: rv0 commentedWorks fine here, thanks a lot!
Anyone tested multistep yet?
Comment #13
mradcliffeI tested without multistep forms as well. The dismiss functionality should probably use either the redirect or the confirmation message configured in the webform.
Nicely done on this patch!
Comment #14
alvinlb CreditAttribution: alvinlb commentedNice module, particular;y liked that I don't need to create a custom template with unwanted content stripped out. And many thanks for the Webform and multistep patches!
Conditional fields aren't working in the frame, should they?
Comment #15
mradcliffeI think you would need to load any javascript file on the page that calls the frame to get conditional fields, vertical tabs, etc... to work.
Comment #16
tchopshop CreditAttribution: tchopshop commentedcan someone explain how to get this to work? I added the patch, changed webforms to alias as webform/[nid], then created a link to the webform page as webform/[nid]. It doesn't work for me.
I also tried the link as: modal_forms/%ctools_js/webform/[nid]
is there something I'm missing?
Comment #17
tchopshop CreditAttribution: tchopshop commentedNever mind! I figured it out!
Comment #18
holdmann CreditAttribution: holdmann commentedLink should looks like this one:
Second class is optional, you can use one of this:
Comment #19
muschpusch CreditAttribution: muschpusch commentedthis patch is awesome! But shouldn't we just close and reload after submission?
Comment #20
Weaver CreditAttribution: Weaver commentedTested with following combination:
Drupal 7.15
Chaos Tools 7.x-1.2
Modal forms 7.x-1.0
Webform 7.x-3.18
I have not tested multi step forms, but what I have tested is working perfectly.
Im having problems with recaptcha (captcha module using math captcha works fine) but I suspect this should be raised as an issue against the recaptcha module. Is anyone here able to look at the problem and at least prove where it lies before I raise it as an issue on recaptcha?
This issue seems quite old and despite the above, I would say the fundamental issue has been resolved, can we get this issue closed and commited? Perhaps doing so will get more people using modal forms and will put some weight behind any other issues like multistep or captcha which could be worked on seperately?
Comment #21
fuerst CreditAttribution: fuerst commentedRTBC as of #20. Got this patch running too.
Comment #22
frjo CreditAttribution: frjo commentedCommitted to 7-dev. Thanks for working on and testing this addition to the module!
Comment #24
lexa.mihu CreditAttribution: lexa.mihu commentedhow can i use webform conditional ?
Comment #25
fuerst CreditAttribution: fuerst commentedHave to re-open the issue, sorry!
The patch in #10 calls
ctools_modal_form_wrapper()
two times in case of multi step Webforms. This leads to the unintended behaviour of having some form elements doubled. No big deal, they will not be displayed. But at least the AJAX setting url will be changed from a string to an array containing 2 elements (= url's). This breaks things at Javascript level as described in #1715508: drupal_get_form on Ajax callback returns this javascript error: “TypeError: element_settings.url.replace is not a function”.The attached patch removes the unneccesary part where
ctools_modal_form_wrapper()
got called a second time. This function is getting called once, also in every multi webform step. Since$form_state['rebuild']
seems to be true in every multi webform step it callsctools_modal_form_render()
in turn which AJAXifies the form.Also the patch adds code for displaying a Webform confirmation message or redirects to an URL defined in the Webform settings.
The patch applies to the current 7.x-1.x branch.
Comment #26
frjo CreditAttribution: frjo commentedThanks for taking the time to improve the webform support!
I made some minor changes to the patch, can you test if this works for you?
I replaced "command" with "output" only because that is what is used every where else in the module. I also removed an "exit" statement. This is not necessary and will only stop drupal messages to display since it interrupts Drupals session handling.
Comment #27
fuerst CreditAttribution: fuerst commentedThat's fine for me. Thanks for reacting that fast!
Comment #28
frjo CreditAttribution: frjo commentedCommitted to 7-dev.
Comment #30
yoodame@ci.uchicago.edu CreditAttribution: yoodame@ci.uchicago.edu commented@tchopshop can you please share how you figured this out?