I have a regular (non-modal) drupal form... when the user hits "submit," I want to open a modal dialog...
I've set up a ctools modal callback, and it's working correctly:
$items['download-manager/%ctools_js/download/%'] = array(
'title' => 'Go to the download form for a particular node.',
'page callback' => 'download_manager_wizard',
'page arguments' => array(1, 3), // %ctools_js, %nid
'access callback' => TRUE,
'type' => MENU_CALLBACK,
'file' => 'download_manager_wizard.inc',
);
The modal opens fine using:
ctools_modal_text_button(t('Download'), 'download-manager/nojs/download/' . $nid, t('Download this asset'), 'download-button');
But from within my form this does not work:
$form['#action'] = url('download-manager/ajax/download/122');
That just gets me an ajax waterfall dump... what should I be doing to open the modal from form submit?
Comments
Comment #1
jordanmagnuson commentedI've also tried adding the "ctools-use-modal" class to my form's submit button, but no luck. A modal begins to popup, but instant error messages:
Comment #2
merlinofchaos commentedHmm. That really ought to work. Perhaps there's a bug.
Have you tried with CTools -dev?
Comment #3
jordanmagnuson commentedThanks a lot for the reply Merlin! I really appreciate your willingness to help.
Okay, just tried the dev, and still having the same issue. If you want to scan my code, here are github links to download_manager.module and download_manager_wizard.inc.
Or for limited reference, here's my complete form callback:
And here's my modal wizard callback that the form's action links to:
I'm using this call to render the form:
print drupal_render(drupal_get_form('download_manager_download_form', $node->nid));And like I said, I've tried ctools_modal_text_button, and that works fine to generate the modal:
Comment #4
jordanmagnuson commentedHere's a screenshot of the error I'm getting (attached).
Comment #5
jordanmagnuson commentedOops... realized that I left in the form_submit callback code for the error screenshot I attached previously (not sure if that really matters or not). Removed the submit callback, and the AJAX HTTP error message now reads as follows (looks like it's basically just spitting out the page content):
Comment #6
jordanmagnuson commentedAny chance of getting further help on this?
Comment #7
Tony Stratton commentedI'm running into the same issue. I need to pass data from a form into a modal dialog, I took the same approach as you and getting the same error.
Any success yet?
Comment #8
jordanmagnuson commentedI got somewhat sidetracked from this issue, but no, still no luck. I'll post back here if I have an update, and would be grateful if you would do the same :)
Comment #9
alduya commentedI encountered this issue while making a form, in which the email address is given, that opens another form in a modal, with the previously entered email already entered.
I found that in the file modal.js, in Drupal.behaviors.ZZCToolsModal, on line 224 findURL is used to get the url to use for the modal based on the button of the form.
This button however doesn't have the url information.
I don't know if this is the correct sollution, but if I add this check, that gets the action value of the parent form if no url was found. Patch is attached.
I also found a possible workaround. findURL tries to get a url based on the name of the item it is given. I added a hidden field to the form with a specific class and the url as value.
My submit butten name is submit, so the extra hidden field must have a class of edit-submit-url.
Comment #10
alduya commentedComment #11
jordanmagnuson commentedThank you very much Sander for the extremely helpful reply--both of your solutions worked for me!
Regarding the patch:
So my version reads:
Comment #12
jordanmagnuson commentedHey Sander, this is slightly off topic, but can you tell me how you managed to pass data from your form to the modal (you say you passed an email address)?
Comment #13
jordanmagnuson commentedComment #14
jordanmagnuson commentedAny chance on getting further help with this? alduya, are you still there?
Comment #15
jordanmagnuson commentedHave been using #11 for some time without any problems. Any chance of getting this patched in dev?
Comment #16
andypost+1 to commit, really annoing
Comment #17
merlinofchaos commentedI'm a little unsure about this patch. While it will AJAX to the form action, is it actually going to properly submit anything? Since it's acting on 'click' and not 'submit' I don't think it's going to submit form values, is it?
Plus, it's not RTBC if the actually attached patch isn't the patch that's been reviewed.
Comment #18
jordanmagnuson commentedMerlin: that's a good question about the form actually submitting anything. I've just been using this to pass values from a form to an ajax modal (just grabbing the values from $_POST)... haven't actually needed to submit the form, per say.
Comment #19
andrewbelcher commentedHere is the patch from #11 as a patch. It solves the problem for me where we're submitting a VBO form, so I think it is find for submission, but wouldn't hurt to have some more testing...
Comment #20
andypostAlso there's a question to properly process when form submission ends with redirect
Comment #21
andrewbelcher commentedYes, it varies depending on what's happening, so we deal with that in the submit handlers using the various core/ctools ajax commands.
Comment #22
jordanmagnuson commentedIf the form is being submitted properly, then I think this is RTBC, as that's the only question that was holding it back...
Comment #23
podarok#19 looks good
assigning it to @merlinofchaos
RTBC
Comment #24
andrewbelcher commentedTurns out there was one other thing missing, if you have multiple submit buttons, the triggering element doesn't get recognised as
opisn't sent. This is simply a case of tellingDrupal.ajaxto set the op based off the clicked element. I've updated the patch for it.Comment #25
HarshalDhumal commentedYou can open modal on form submit by converting that form submit into ajax submit.
Comment #26
jordanmagnuson commented@HarshalDhumal: thanks for the example. Using your method, how do we degrade gracefully if javascript is not enabled?
Much appreciated if you could provide an example with graceful degradation.
Comment #27
jordanmagnuson commentedTo answer my own question, I think the best way to handle graceful degradation for the method in #25 is to do something similar to the method used in the ajax graceful degradation example module: have two submit buttons on the form, one for ajax, one for non-ajax (with its own non-ajax submit callback), and then use css and js to hide/show the appropriate button depending on whether the user has js enabled or not. Then you can react to each situation independently (e.g. open a modal for the js user, send the non-js user to a form page via drupal_goto).
Comment #28
japerryLooks good to me, I'm including it with the ctools 1.4 sandbox for testing.
Comment #29
japerryTested, fixed, and committed:
http://drupalcode.org/project/ctools.git/commit/bc26d0afb2a322d323d4cf17...
Comment #30
japerry