Make max_input_vars check optional

Argh.

What *is* present with modal forms? I'm wondering if the absence of all of op, form_id, and form_build_id would work. op is missing from ajax. form_build_id is missing from some cached forms. And apparently form_id is missing from modal forms. But are all three ever missing with a proper $_POST?

We've run into the same problem today. I've already looked into modal_forms' code, if they are doing some ugly workarounds in there. But it is written very cleanly. The module heavily depends on Ctools. The following lines are loading the webform (in modal_forms.pages.inc line 282+):

<?php
  $form_state = array(
    'title' => $title,
    'ajax' => TRUE,
  );

  // Prevent webform redirect.
  $GLOBALS['conf']['webform_blocks']['client-block-' . $node->nid]['pages_block'] = 1;
  $node->webform_block = TRUE;

  // Pass required parameters.
  $form_state['build_info']['args'] = array($node, FALSE);

  // Render the Webform.
  $output = ctools_modal_form_wrapper('webform_client_form_' . $node->nid, $form_state);
?>

Before calling ctools_modal_form_wrapper(), the $form_state['input'] is empty, after it is filled with the following keys: 'js', 'ajax_html_ids', 'ajax_page_state'. I've played a bit around, even if you call drupal_build_form() directly, you'd get these keys. Seems their presence is some kind of default when using Ajax calls. I couldn't dig deeper, when and how and why they are added. Is anybody in here with a deeper knowledge of what happens internally, if you ajaxify a form, with or without Ctools?

I would recommend to enhance the webform_input_vars_check() and allow the presence of certain array keys within the $form_state['input']. I'll post a patch which works for us.

Here's my patch

@agoradesign -- please remember to set the status back to active or needs review to let me know it needs attention again!

I went in a slightly different direction. Rather than coding specifically around modal form, I look for a key in the submitted data that, if there, means that the form_id should be too. Could you please try out this patch?

Sorry, it was already the end of a long, busy day...

Thanks for your updated patch. Your approach is definitely smarter. And I've just tested it - works for me :)

Only one question: Is there a specific reason, why you switched from empty() check to !key_exists(). (array_)key_exists() will return TRUE, even if the value of 'form_id' is NULL. Is that intended?

isset() does not return TRUE for array keys that correspond to a NULL value, while array_key_exists() does.

see: http://php.net/manual/en/function.array-key-exists.php

@agoradesign. Yes there is.

empty() is misused to mean "missing", which it doesn't. empty($a[b']) will be true when $b is missing, NULL, 0, '0', and empty array, etc. 99.999% of the time, $a[$b] can't be 0, but on the off chance that it can, I'm mindful when usnig empty.

If the form_id is NULL, I'd say that the form probably still completed, The $_POST would not seem to be truncated.

Thanks for the testing, folks. I'm commit this very soon.

EDIT: ninja

That's what I meant. I wasn't sure, if a NULL value for the form_id would be really valid/complete. I think, you know better. Just wanted to be sure, that this change and its effect was intentional...

Ok, green lights on. Thanks for your quick reaction - looking forward to see this committed :)

#6 committed to 7.x-4.x and 8.x. Thanks, folks.