Support from Acquia helps fund testing for Drupal Acquia logo

Comments

andypost’s picture

Assigned: andypost » Unassigned
Status: Active » Needs review
FileSize
3.12 KB

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.

mathieuhelie’s picture

FileSize
5.34 KB

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.

andypost’s picture

Status: Needs review » Needs work

must rewrite the paths of your webform nodes to webform/nid from node/nid.

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

mathieuhelie’s picture

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.

fuerst’s picture

Tried both patches on 7.x-1.0:

  • Patch in #1 does apply using patch -p0.
  • Patch in #2 does apply using 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.

andypost’s picture

@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

fuerst’s picture

Status: Needs work » Reviewed & tested by the community

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.

qoomir’s picture

How to rewrite webform nodes to webform/nid from node/nid ?

osopolar’s picture

Status: Reviewed & tested by the community » Needs work

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.

larskleiner’s picture

Status: Needs work » Needs review
FileSize
3.35 KB

I re-rolled patch #1 with added support for multistep webforms.

I also get a notice with patch #1 after form submits.

Notice: Undefined index: rebuild in drupal_process_form() (line 927 of /includes/form.inc).

This is fixed by the patch here: http://drupal.org/node/1458540

osopolar’s picture

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.

rv0’s picture

Works fine here, thanks a lot!

Anyone tested multistep yet?

mradcliffe’s picture

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!

alvinlb’s picture

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?

mradcliffe’s picture

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.

tchopshop’s picture

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?

tchopshop’s picture

Never mind! I figured it out!

holdmann’s picture

is there something I'm missing?

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:

  • ctools-modal-modal-popup-small (300x300);
  • ctools-modal-modal-popup-medium (550x450);
  • ctools-modal-modal-popup-large (80%x80%).
muschpusch’s picture

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();
Weaver’s picture

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?

fuerst’s picture

Status: Needs review » Reviewed & tested by the community

RTBC as of #20. Got this patch running too.

frjo’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 7-dev. Thanks for working on and testing this addition to the module!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

lexa.mihu’s picture

how can i use webform conditional ?

fuerst’s picture

Status: Closed (fixed) » Needs review
FileSize
3.6 KB

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 calls ctools_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.

frjo’s picture

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.

fuerst’s picture

That's fine for me. Thanks for reacting that fast!

frjo’s picture

Status: Needs review » Fixed

Committed to 7-dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

yoodame@ci.uchicago.edu’s picture

@tchopshop can you please share how you figured this out?