Posted by andypost on October 30, 2011 at 8:06pm
18 followers
| Project: | Modal forms (with ctools) |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Introduce a webform module callback
Comments
#1
This 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.
#2
The 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.
#3
Any reason?
+++ b/js/modal_forms_webform.jsundefined@@ -0,0 +1,11 @@
+Drupal.behaviors.initModalFormsWebform = {
I see no reason to replace all webform links with popups
+++ b/js/modal_forms_webform.jsundefined@@ -0,0 +1,11 @@
+ }).addClass('ctools-use-modal ctools-modal-modal-popup-small');
Make all popups small is bad default without ability to override
#4
The 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.
#5
Tried 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.
#6
@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
#7
That'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.
#8
How to rewrite webform nodes to webform/nid from node/nid ?
#9
What 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.#10
I 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
#11
Thanks 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.
#12
Works fine here, thanks a lot!
Anyone tested multistep yet?
#13
I 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!
#14
Nice 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?
#15
I 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.
#16
can 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?
#17
Never mind! I figured it out!
#18
Link should looks like this one:
<a class="ctools-use-modal ctools-modal-modal-popup-large" href="/modal_forms/nojs/webform/[nid]">hyperlink text</a>Second class is optional, you can use one of this:
#19
this patch is awesome! But shouldn't we just close and reload after submission?
$commands = ctools_modal_command_dismiss();$commands[] = ctools_ajax_command_reload();
print ajax_render($commands);
exit();
#20
Tested 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?
#21
RTBC as of #20. Got this patch running too.
#22
Committed to 7-dev. Thanks for working on and testing this addition to the module!
#23
Automatically closed -- issue fixed for 2 weeks with no activity.
#24
how can i use webform conditional ?
#25
Have 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.
#26
Thanks 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.
#27
That's fine for me. Thanks for reacting that fast!
#28
Committed to 7-dev.
#29
Automatically closed -- issue fixed for 2 weeks with no activity.
#30
@tchopshop can you please share how you figured this out?