An illegal choice has been detected

What are the steps to reproduce this error?

Ok Thanks.

I recently ran into this problem whilst using entity form. Steps to reproduce:

1. Create an entity form.
2. Add a Text field that uses the "Select or other (list)" widget. Must be required field.
3. Add a Text field. Text widget. Unlimited values.
4. View the form. Try to "Add another item" twice on the text field. It fails when no value has been chosen on the Select or other field.

I tried the same in a content type but could not reproduce the error, so maybe this is an entity form issue.

I can confirm, we're seeing the same issue with an Entityform. We are using Entityform 7.x-2.x-dev dated July 14, 2015, and Select (or other) 7.x-2.22.

We have a text field (Field A) that uses the "Select or other (list)" widget and it is a required field. The error is triggered by another field (Field B) that we have hook_form_alter'ed to have an "#ajax" option.

When Field B changes, our ajax callback fires successfully and we don't immediately see an error. However if the page is then reloaded, we get the following error on the page:

An illegal choice has been detected. Please contact the site administrator.

And we have an error message in watchdog:

Type: form
Date: Saturday, August 1, 2015
User: admin
Location: http://domain.com/system/ajax
Referrer: http://domain.com/eform/submit/new-form
Message: Illegal choice in "Field A" element.
Severity: error
Hostname: 127.0.0.1
Operations:

This error typically happens when a field is attempting to be rebuilt during an ajax call and some components are missing from the widget. I reviewed at the Select (or other) field both before and after and they look the same, but could be a problem occurring somewhere else.

I did notice one difference looking at the before and after $form arrays that I should mention.

When the form is first loaded, the value of the Select (or other) field's #default_value is NULL. However when it is reloaded after the #ajax processing, the value of #default_value is (String, 0 characters).

I wouldn't think this could cause an issue, but maybe it might with how FAPI works.

Just tested a little further and that's it... #default_value is the problem. The $form value for #default_value is getting changed.

I added the following code to our _form_alter function and no longer getting the illegal choice error:

  if ($form['field_select_or_other'][LANGUAGE_NONE]['#default_value'] == '') {
    $form['field_select_or_other'][LANGUAGE_NONE]['#default_value'] = NULL;
  }

So #default_value is being reset to an empty string rather than NULL when the form is processed, causing the issue.

@ron_s,

Have you figured out when/where this change is happening? Is this caused by select_or_other itself? Also, are the notices in the issue summary still relevant?

@legolasbo, I haven't had a chance to investigate exactly what is causing the issue, but it is clear our custom ajax callback is triggering it.

The notices in the issue summary may still be relevant. When ajax callbacks are triggered, they run through any #after_build and #validate functions. The ajax callback is in a module that has custom #after_build and #validate functions, but neither of these are modifying or accessing the select_or_other field.

My initial guess would be that a $form rebuild is being done after the ajax callback is complete, and the Select (or other) module might need an extra bit of code to ensure #default_value is NULL when returning. I've certainly had to do things like this for custom modules in the past to ensure the $form is rendered correctly.

I won't have time to look at this further in the near future, but hopefully soon.

I have a similar issue going on, I hope someone can help. I am using Select or Other field and 'Available options PHP', and that part is working fine. However, when I try to upload a file, or remove a file using File Field, it is producing the same error "An illegal choice has been detected." After doing some research, I found out that the '#options' element becomes empty after AJAX callback.

Surinder P Sachdeva, thank you, it helped me.

This a problem on both the 7.x-2.x and 7.x-3.x branches. If a value is currently selected in the field and then I use ajax to repopulate the options of the field, I get the error 'An illegal choice has been detected. Please contact the site administrator.' This occurs even if the previously selected option exists in the updated dataset. This does not happen with core's default select form element.

In my case, I ran into this error when using another field with Ajax on the same form. The problem occurs when line 94 checks to see if a default value field isset. It's set, but it's empty. With the current code, the select or other module then takes that empty string and assigns it as the default value. However, Form.inc doesn't allow empty strings, so it throws the illegal choice error.

To prevent this error, I've changed the check from isset() to !empty().

Committed and pushed to 7.x-2.x. Thanks.

@chrisgross, you mentioned this is also an issue on 7.x-3.x-dev. Could you verify this is still the case and if so, could you port the patch to 7.x-3.x please?

Problems; after I added the content in the box "Other". It added it to the pulldown menu. Please see images.

Drupal 8
bootstrap 3.x
Thanks,

I don't see how that is related to this issue @vunda.

please explain why it is related or open a new issue.

Sure, I'll open a new issue.
Thanks,
V

Closing as outdated because no activity in a long time and Drupal 7 goes EOL soon. Feel free to re-open if needed.

Drupal 7 won't be EOL for another year and after that it will be in long term support perhaps for a decade. However, this issue is solved in the 2.x branch, so perhaps we can deprecate the 3x branch if we don't have the energy to port fixes from 2x to 3x?

Drupal 7 Will only be in extended support with selected vendors after that. I also didn't close all issues, but only issues that did not have any activity in the last 2 years. This one hadn't been touched in 4 years.

I became a maintainer to get a D9-ready version out and to maintain it from that point on. Whether or not this should be ported to the 7.x-3.x branch is up to those that need it imo.

If you'd like to discuss this further, feel free to reach out over slack e.g.

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.