Choice checker can be skipped

The #process workaround handles this without a special case.

Let's start from what was this used for "legally". I know it was used in some contrib modules "illegaly" and caused security problems. So what legal code would we brake by removing this. Where is the "update docs" on what to do if this gets removed? (We really need update docs if this gets committed).

I was one of the ones who advocated for that flag.
It was for 4.7, and back then I needed it to AHAH-fill choices in a select based on the entry in a textfield, with too many (1000's, taken from db) possible values to make them all valid.

This use case is now supported by D6 FAPI/AHAH features, right ?

There were two sides to that use case, right? One is that the options where handled with AHAH, the other is that there were thousands of options. For caching would cache the thousands of options in the regular form structure right? I guess that was one thing people tried to avoid with this flag to save some performance.

Note that I am not advocating keeping this security hole possibility here, but I'd not commit the patch without understanding the consequences.

@In that use case, the developer can use #process to inject just the options that were selected into the #options array. He does so by reading in from $edit, which is available to #process functions.

Understood, so committed. Please document this in the update docs. Leaving it code needs work for this reason.

added to update doc.

it would have been nicer if y'all provide a little more information on how to subvert this filter hook.
What is published in this thread, and anywhere else i've looked, isn't enough for the casual form api hacker.
>frustrated<

The 'update doc' (http://drupal.org/node/114774#choice_check) points to this issue as a source of instruction on how to work around the removal of #DANGEROUS_SKIP_CHECK, yet this post provides no code examples on how to do it.

I have an awkward use case where I need to set CCK optionwidgets_select options dynamically. And after several hours trying different things, I cannot avoid the dreaded 'An illegal choice has been detected'.

Could someone provide a concrete, working example of code that alters the default form options safely?

I don't know is my code safely or not, but I hope it can help. My example is based on Ubercart address fields, so some functions can be found in Udercart module.

"Country" field:

  $select = array(
    '#type' => 'select',
    '#title' => $title,
    '#description' => $description,
    '#options' => $options,
    '#default_value' => empty($default) ? uc_store_default_country() : $default,
    '#required' => $required,
    '#ahah' => array(
      'path' => 'ss81/zone_select',
      'wrapper' => 'edit-profile-step5-zone-wrapper',
      'method' => 'replace'
    )
  );

Function, assigned to "ss81/zone_select" path:

function ss81_zone_select() {
  $country_id = intval($_POST['profile_step5_country']) > 0 ? intval($_POST['profile_step5_country']) : uc_store_default_country();

  //get form from cache and store modified place selection
  $form_state = array('values' => $_POST);

  $form = form_get_cache($_POST['form_build_id'], $form_state);

  $form['Personal Information']['profile_step5_zone'] = uc_zone_select('State/Province', NULL, NULL, $country_id);
  $form['Personal Information']['profile_step5_zone']['#default_value'] = '';
  form_set_cache($_POST['form_build_id'], $form, $form_state);

  //rebuild the form.
  $form_state = array('submitted' => FALSE);
  $form = form_builder('user_profile_form', $form, $form_state);

  $output = drupal_render($form['Personal Information']['profile_step5_zone']);

  // Don't call drupal_json(). ahah.js uses an iframe and
  // the header output by drupal_json() causes problems in some browsers.
  print drupal_to_js(array('status' => TRUE, 'data' => $output));
  exit();
}

Really appreciate to author of http://drupal.org/project/weather for examples of code.

I think such posts must be with code examples :)

What if I don't wanna use AHAH? I'm using jquery only to add options to the select. Is there any *simple workaround*?

Check out this post.

http://drupal.org/node/303576

Dear Drupal,

I don't want to learn your crappy AHAH to rewrite the contents of a $%&-ing select box. Especially when I'm allowing for the select box to _become_ a textfield! Um, they can post whatever they %&*^-ing want!

Ok, I'm feeling better now.

SOLUTION: Initiate your select as a textfield. On document load, javascript it into a select. Boom. This is fine because you need to call it via script anyway... no harm, no foul. Plus, if script is turned off, a textfield is much more flexible for the user.

I win!