Exposed filters fire "An illegal choice has been detected. Please contact the site administrator." error

Please help us to help you: Therefore read http://drupal.org/node/571990

In general do you do any kind of themeing/hook_form_alter/js/whatever to alter the exposed filters?

I have the sma problem:
- no theme modify, no hook
- 1 views with page and attachment, same exposed filters (nodereference select list)

Does it happen with something else then the nodereference select list?

if no you can move the issue to the reference module, because they probably know better where the problem could be.

The problem appears to be with the selection of allowed options in an exposed form, and can easily be reproduced on my system.

Create a content type, with a list(text) field, allowed values "Yes" and "No".
Create a View with an exposed filter on this field.
To really isolate the problem, start with leaving the "Options" checkboxes completely empty.
Now look at the View, and see that the View works as it should with the filter.

Go back to Views, and in the exposed filter, check "Select all" under options. Save the VIew, go back to it, _and make sure to clear the exposed filter from the URL_. Now, the error message
"An illegal choice has been detected. Please contact the site administrator." will appear, and the exposed filter, set to "" will get a red border.

Ugly and irritating, but hardly a critical issue as VIews doesn't cause a crash. It's barely even a major as there's a workaround, but I leave that to the maintainer to decide.

Actually, it doesn't seem like not having checkboxes is a workaround in all cases. I haven't determined exactly what the difference is, but I built a second slightly more complex View, and there I get the same problem even with all exposed options unselected.

The workaround appears valid for page views, but no content panes.

Forgot to assign.

For anyone who needs a temporary workaround for this problem, you can do something like this

if (!isset($_GET['field_event_category_value'])) {
  $_GET['field_event_category_value'] = 'All';
}

in hook_init

The problem is that this "js-only" form element is still part of the stored value.

This patch removes 'all' from the value if the form is exposed.

Okay, patch in #9 fixed the error (Thank you!), but now the exposed select list starts with the first item in the list, where before it started with "-Any-". Is there any way to get it to default back to "Any"?

subscribe

@Old Man
Can you show an configuration of your view? Did you configured to be optional?

@dereine: Sorry for the delay in responding... here are the configurations of the view, and it's configured to be optional. I changed nothing after applying the patch in #9, so just wonder why it does not default to -Any- instead of the first item in the list, and how to get it to default to -Any- once again to show all items by default.

I'm seeing the same behaviour - without the patch I get the error message and with the patch my exposed filters all default to the first option even though they are optional.

If it's any help, setting the exposed filter option "Limit list to selected items" makes the filters default to "- Any -" as normal.

I am having the same issue with a very simple view. If I expose a filter (in this case by 'node type') I get the error: "An illegal choice has been detected. Please contact the site administrator."

@morbiD

Thanks for the tip... that does help, now I've got my "-Any-" back without much of a workaround. It's still a bug, but usable.

I did not instal the patch, but selected "limit list to selected items" as per #14 and it got rid of the error for me.

Can someone you get's this error please try out this patch?

Selecting "limit list to selected items" is only a workaround.

I am using the patch and it seems to work at getting rid of the error, but needs to be used in combination with the suggestion by -morbiD- above.

I am getting the same error and I have applied the patch and -morbiD- said above. I tried to make each of the values in the content type to a default value.

I am adding an image to this which the page is created by Views 3 when I use Exposed Filter Form.

Which module produced the checkboxes?

I was able to solve my part as I made a tpl.php file for my exposed filter view and I needed to change that to make this work out. The module that I use to make the checkboxes are Better Exposed Filters

I'm getting "&type=AllAll" in the sort headers, causing the crash. This is in Views 2, so I'm not sure if it's the same problem.

This issue may be related to this problem : http://drupal.org/node/1239866

Just mentioning it because it triggers the same message, and as it involves custom code, it may (or may not) help the maintainers narrow down the number of possible debugging paths.

subscribe

though i've been ticking "limit list to selected items" for over a year with drupal 6 (still do) and it's worked like a charm ever since

works fine for drupal 7 too

subscribing just to keep in the loop

Recently i commited a patch which might fix this, could you please checkout the latest 7.x-3.x-dev?

If it's not fixed it would be great if someone could provide a views export which can be used to reproduce the issue.

@drumnjo post #26

This works for me too. If this option in UNCHECKED, then the initial value of 'any' doesn't create the list, instead you get that cryptic error.

CHECKING options > 'select all' and also CHECKING the 'Limit list to selected items', the default value in the view filter will be -any- and the list creates just fine. For me anyway, drupal v7.8.

Although it does seem weird why you have to check that box when selecting all isn't really limiting anything.

**EDIT** - not CHECKING any of the options and UNCHECKING 'Limit list to selected items' has exactly the same effect. All options are present unless you select individual ones.

@samwillc post #28 re:

**EDIT** - not CHECKING any of the options and UNCHECKING 'Limit list to selected items' has exactly the same effect. All options are present unless you select individual ones.

Is there any benefit of doing it one way over the other?

thanks

Joe

Hi Joe,

I couldn't say, I find leaving everything unchecked easier but just give both a try. Maybe different variations would have different effects depending on your view. Not sure :)

Just got this error at the very end of my view-- perfect timing especially when it's for a client.

dereine, upgrading to the dev didn't do anything. Can I try the patch you posted in #9? Or was that incorporated into the newest release?

Also: attached is a screenshot of my view

I was able to fix the error by installing rc1 again and simply turning on AJAX.....

Don't ask why, but I'm not going to complain.

The error may have been from the Better Filters module... the URL had some encoding with the + sign to %db something... this could have been the cause of the issue.

My problems : to avoid the "Illegal" … I have to select each item without the Select All.
In that case, in the default view (without having used the filter), there is nothing.
I MUST use then the filters to display something !

If I check Limit to select items (in the Exposed filters options), then when i Add another items, i will never appear in the List selection.

With or Without Patch same issue.

@ samwillc #post 28

This was the solution for me ! Many thanks

I'm using rc1 and the workaround in #26 worked for me too - thanks!

It seems this error is re-appearing with Views-dev 16-nov-2011.
see #1344610: Filtering on content type gives error No valid values found

In my case, this is maybe related to my term reference filter handler settings not actually showing any values to filter by!

I had this same issue and a workaround for me was to have the "Items per page" number match the first number in the "Exposed items per page options".

For example:
Items per page = 50
Exposed items per page options = 50,100,250,500,1000

I am not sure if this workaround applies to all of the different scenarios mentioned, but it worked for me.

Installed version = Views 7.x-3.0

Let's mark this issue as fixed as it's quite clear that it's actually caused by bugs which existed before/doesn't exist anymore etc.

Let's keep things simple and fix all by one

@celticremark
For example this sounds like a valid task. Some sort of validator for the exposed settings would be cool to take care of that error.

@#40 Thanks! that was it.

I had the same issue with with exposed filter in a select list. The way I resolved it was by checking "select all" checkbox and then checking "Limit list to selected items" checkbox in the exposed filter configuration page (after you add the filter and you are promoted to configure it)
This changed the view code after export from
$handler->display->display_options['filters']['status']['expose']['reduce'] = 0;
to:
$handler->display->display_options['filters']['status']['expose']['reduce'] = 1;

Hope this help.

Edit: this is the same as #26 #27 and #28

#44 works for me!

#44 works for me too, but it still seems like an odd workaround ;-)

I have this problem too when I choose "Checkboxes/Radio Buttons" at the BEF Settings, for a filter with Selection Type: "Autocomplete". Switching it to "Dropdown" will solve the problem.

I think works. Thanks.

Just a note to say #44 *didn't* work for me, but #34 did... that's with the Content: Type filter. So seems behaviour is inconsistent? Not quite sure why this issue is marked closed (fixed) as it doesn't seem to be?

Had the same issue. After finding this post I've tried some different settings of my exposed filter.

It worked with:
Remember the last result - checked
Limit list to selected items - checked
Select the values without "Alla selected" and instead click every single one value.

Dont know how to install patches yet so was very happy that this worked :)

#811542: Regression: Required radios throw illegal choice error when none selected is related.

Well all in all it still works.

I was trying to use Radio buttons with a required value (with a pre-selected default value) and had this error.

I narrowed my problem down to being caused by the "Show hierarchy in dropdown" - the radio option doesn't seem to be compatible with this and results in an empty list (therefore causing an error when it tries to find the pre-selected value).

This sounds like a bug unless the radio button option isn't intended to support the "Show in hierarchy" option?

Either way, this is another possible cause for the error message should anyone else be trying to do something similar to the above.

Thank you for the explanation!

It's not an option to set this to any because all off my terms are related to one term.
It makes that my first option to choose from is the only option (it should be default).

I find that kind of ugly and not very user friendly.
The reason I did this is because the taxonomy is a menu.
Like:

Product:
- tables
- type 01
- type 02
- cabinets
- type 01
- type 02
- ...

I only have a problem when I'm changing to another language.
" An illegal choice has been detected. Please contact the site administrator."

When I set my taxonomy dropdown to any, the problem is away. But my filters start with 'product';
and I really would like to start with 'tables / cabinets / ...' .

Isn't there an other way around this? Sow I can limit my list and skip the first option.
I would love some help.

Hi

not sure it is OK to reopen this issue or rather a new one should be created, however I was hitting exactly this problem.

Drupal 7.22
Views 7.x-3.7

Anytime I create an exposed 'grouped filter' with or without 'Allow multiple selections', and select a default value which is not '- Any -', I get a 'An illegal choice has been detected. Please contact the site administrator.' error message. It goes away after first selection, however selection is not 'remembered' if the relevant box is set (i.e. next time view is accessed, here we go again).

I checked the code and it seems to me it nails down to the fact that, during the processing, Views overrides the input coming from the form widgets with some internal logic to prepare the query filter. However these overridden values, being saved to the session variables for 'remembering', no longer conform to the appropriate '#default_value' forms API setting. So when the view is recalled, and the value stored in session fetched for passing to the form element as '#default_value', we get that error (that simply says that the #default_value is not valid').

In the patch attached, the code is 'preserving' a copy of the values returned by the forms API before processing them, so that these are saved to the session variable instead of the post-processed values.

I am new to Views code, so please review carefully.

Patch in #57 is not 'remembering' the selected value if '- Any -' is selected.

Re-roll.

Adjusted issue title

Drupal 7.22
Views 7.x-3.7

I tried the patches on #57 and #58, but still got the same error message.
My view is using three exposed filters: one for list text field, and two for date fields (start and end dates).

The error message is shown when I input +8 days (and more) from now into those two date fields, while I don't have any other date restriction on the view result.

@apprayo: Have you tried to logout and login again, and flushed caches after applying #58? Some data get stored in the $SESSION variable, and just found out that to clean that up you need to close your active session and start a new one. But... my problem was on grouped items filter, not on simple ones.

edit: I remember having also gone through the views UI to recall and reconfirm the filters, and finally saving the view itself

Hi, I have latest dev
In a view I had to expose a multichoice grouped filter "Accessories" which is creatig a checkboxes form with keywords contained in a textarea field_accessories

While selecting at least one of the accessories was working, if none of them are selected the pager results broken.
Looking at the url built for each page i found several query items like
"field_accessories_value[1]=0&field_accessories_value[2]=0"...
These queries should not be present at all if none of the checkboxes are selected, but only those one the user choose.

I solved in this way:
in a custom module implement hook_init and unset all the possible values that you dont need
This is a temporary hack.. I have no idea how to solve

I am having the same problem with grouped filters. When I try to remove the optional and make a default value, i get the error. Tried to apply #58, but still happens. As soon as I make the grouped filter optional, it goes away.

Seems that this bug prevents one from setting a default value for a non-optional filter when dealing with grouped filters. <--- this is the problem!!!

I re-rolled #58 against Views 7.x-3.0-dev dated 2013-Jul-10 after manually patching it.

I have tested this and deployed it to production. It appears to have solved our problems.

Joe

#64 appears to work for me. I had an exposed group filter, logs were complaining about an exposed sort. This in a Search API-based view.

Tried #64 patch and it didn't work for me. Then tried solution listed on #28 from samwillc and it works great now. Thanks.

Retracting my approval in #65, the patch is applied but the problem is back. Not sure what changed, investigating.

Okay, figured it out. The patch above may have well fixed the one problem, I now am dealing with two different views with exposed searches claiming the sort_by query key.

#44 worked for me also!

YES! Number 28 worked for me! Thanks!

Of course, I did do Number 64 changes... and haven't reverted... so maybe a combination of both?

Either or, it works :)

Tried 64. Doesnt work. The sort_by doest work on the second view in a set of views.

If it's any help, the patch #5 in https://drupal.org/node/1986306 solved the issue for me (I am using multi select checkboxes)

#14 worked for me....

#26 works for me too.
I am using Views 7.x-3.7

I tried to rewrite a exposed text-field-filter to a dropdown-list with hook_form_alter in my own module.
I also get this error.

I started with:

$form['uid_raw']['#type']='select';
$form['uid_raw']['#size'] = 1;
$form['uid_raw']['#options'] = $usernames;
$form['uid_raw']['#default_value'] = 0;

and added:

$form['uid_raw']['#validated'] = true;

to my hook_form_alter function. That fixed it.

I hope this helps someone...

this option work for me, check Limit list to selected items and works

I had the same problem and after some investigation i realised that the "Select all" option value in the exposed filter settings is all lowercase while the URL parameter after using the form is "All" (title cased).

Steps:
- apply patch
- clear cache (needed?)
- re-select "Select all" in exposed filter settings
- save view

Hello,

I have a views page with exposed grouped filter with multiple selections , parent term group his child :

Natural sciences <-- parent
-Mathematics
-Computer and information sciences
-Earth and related environmental sciences
-Physical sciences
-Chemical sciences
-Biological sciences
-Other natural sciences
Engineering and technology <-- parent
-Civil engineering
-Electrical, Electronic and Information engineering
-Mechanical engineering
-Medical engineering
-Chemical engineering
-Materials engineering

- ETC...

If check more than when parent term no result appear, the query is :

SELECT DISTINCT node.title AS node_title, node.nid AS nid, node.language AS node_language, node.created AS node_created, 'node' AS field_data_field_tech_categ_node_entity_type, 'node' AS field_data_body_node_entity_type
FROM
{node} node
LEFT JOIN {field_data_field_tech_categ} field_data_field_tech_categ ON node.nid = field_data_field_tech_categ.entity_id AND (field_data_field_tech_categ.entity_type = 'node' AND field_data_field_tech_categ.deleted = '0')
WHERE (( (node.status = '1') AND (node.type IN ('offres_techonolgie')) AND (field_data_field_tech_categ.field_tech_categ_target_id IN ('51', '52', '128', '166', '129', '130', '167', '168', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0')) AND (field_data_field_tech_categ.field_tech_categ_target_id IN ('135', '136', '137', '138', '165', '139', '140', '141', '142', '143', '144', '145', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0', '0')) ))
ORDER BY node_created DESC, node_title ASC
LIMIT 10 OFFSET 0

I manualy rewrite the query and Bingooo !

SELECT DISTINCT node.title AS node_title, node.nid AS nid, node.language AS node_language, node.created AS node_created, 'node' AS field_data_field_tech_categ_node_entity_type, 'node' AS field_data_body_node_entity_type
FROM
{node} node
LEFT JOIN {field_data_field_tech_categ} field_data_field_tech_categ ON node.nid = field_data_field_tech_categ.entity_id AND (field_data_field_tech_categ.entity_type = 'node' AND field_data_field_tech_categ.deleted = '0')
WHERE (( (node.status = '1') AND (node.type IN ('offres_techonolgie')) AND (field_data_field_tech_categ.field_tech_categ_target_id IN ('51', '52', '128', '166', '129', '130', '167', '168', '135', '136', '137', '138', '165', '139', '140', '141', '142', '143', '144', '145')) ))
ORDER BY node_created DESC, node_title ASC
LIMIT 10 OFFSET 0

How can i modify the query programmaticly in views !! or there's patch for this issue !

thx for your help.

opened issue : https://www.drupal.org/node/1177882

I am running

Drupal 7.31
Views 7.x-3.8

and I had a problem described in #57.

Fixed it with views_fix-illegal-choice-exposed-group-filters_2292467-02.patch from https://www.drupal.org/node/2292467

I can't seem to get rid of this error! I'm running Drupal 7.31 and Views 7.x-dev, have tried many other views versions and different patches but none have helped thus far. My filters work fine but as soon as I browse to another page and come back, the values reset (although I use 'remember') and the error appears - until I use the filters again.

I know this is silly but in my instance I simply took off the "Select a;;" option on the exposed filter and selected all of the individual filter options.

This removes the error (as it seems to relate directly to the "Select all" option, but still allows for all options to be selected.

This is not a fix but the work around worked for me.

Cheers - SAA

Code search (7.x-3.8) has 40 'all' and 43 'All'. I think fixing one will break others. Maybe a coordinated switch to just use 'all'?

My error was with an exposed boolean filter (boolean field on an entity)

- $form['value']['#options'] = array('All' => $any_label) + $form['value']['#options'];
+ $form['value']['#options'] = array('all' => $any_label) + $form['value']['#options'];

- if ($form_state['values']['options']['value'] == 'All' && !empty($form_state['values']['options']['expose']['required'])) {
+ if ($form_state['values']['options']['value'] == 'all' && !empty($form_state['values']['options']['expose']['required'])) {

then updating the stale view settings (which was still All).

[edit]
And this created another series of issues, fixing one of these broke others, and so forth. This could be an all or nothing thing.

My workaround, sad but effective:

/**
 * Implements hook_init().
 *
 * On the page view "clients", set the exposed filter arguments before
 * these are built to avoid "An illegal choice..." error.
 */
function hook_init() {
  if (arg(0) == 'clients' && !arg(1) && !isset($_GET['gd']) && !isset($_GET['status'])) {
    $_GET['status'] = 'All';
    $_GET['gd'] = 'All';
  }
}

#77 worked nicely without clearing the cache. Just had to reselect the option(s) in view.

Thanks.

I had this problem when the sort by is empty but is filled with the $_GET parameters. I made a patch when i unset the exposed input of the sort by.

This should be fixed in dev.

If the problem is "All" vs "all", then I agree with #82 that we should change to use "all" in every occurrence.

#86 worked for me. Thank you very much! I'll test it in some more situations so that I can confirm that everything is Ok now.

#86 works for me.

Patch #64 seems to work for me.

My patch (#86) maybe skip the errors but don't solve anything.
The problem is due to views add the sort by value in exposed form even if it's not neccesary, when the sort by is passed by $_GET.

I have had this error message (from form.inc) and I think have understood what happened.
I post in this thread because it is the most recent reporting this error and I think it can help.
My site has a search view (DB Search index) with exposed filter in block for search input.
I have several views with exposed filters. The exposed filter is a sort filter on a numeric field, and a similar filter (sort on the same content field) also used on the search view.
When a view page with exposed sort is loaded, Drupal process the exposed filter form, but il also process the form associated with the search view exposed filter (displayed in a block), which also includes a sort. The page has two forms with the same name for sorting results and this produce the error message.

I have written a workaround by implementing hook_form_alter in template.php.

function mytheme_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'views_exposed_form') {
    // search filter block
    if ($form['#id'] == 'views-exposed-form-search-page'
      || $form['#id'] == 'views-exposed-form-search-page-mobile') {
      // remove sort from form if page url != seach results page url
      $path = current_path();
      if (!(strpos($path, "search") === 0 || strpos($path, "mobile/search") === 0)) {
        unset($form['sort_by']);
        unset($form['sort_order']);
      }
    }
  }
}

I hope this can help.

The #9 patch fix the error but the - Any - option is not selected by default, the next option is.

For example given the list: ['all', 'op1', op2']

The patch removes the first option, but the default value is pulled from the array with array_shift: 'op1'

if (empty($this->options['expose']['multiple'])) {
        if (empty($this->options['expose']['required']) && (empty($default_value) || !empty($this->options['expose']['reduce'])) {
          $default_value = 'All';
        }
        elseif (empty($default_value)) {
          $keys = array_keys($options);
          $default_value = array_shift($keys);
        }
        else {
          $copy = $default_value;
          $default_value = array_shift($copy);
        }
      }

I think that changing the $this->value directly is not a good idea, maybe a better approach is to find the 'all' option and match the first if case: set to 'All'

        if (empty($this->options['expose']['required']) && (empty($default_value) || !empty($this->options['expose']['reduce'])) || isset($this->options['value']['all'])) {

Attaching patch, please review

@NOTE: this patch is only for ingroup filters, sort filters could have same problem.

I've discovered this issue after finding the bug in D8, where I should upload the D8 patch? (same fix, different handler file)

Please review!

It would be super nice if we either create an issue for that in the core queue or actually find an issue for that fix in it.
Just committing it to D7 feels a bit of a regression causing problem for me.

Adding the D8 issue relation

You can get rid off this message by selecting some options in the UI:

- Check all the items you want to show up in the filter, but do NOTcheck the "Select all" checkbox.
- Check option "Limit list to selected items"

This works for me on version 7.x-3.13 of Views

Hello,
I want to thank #44 for their help. I use D8 and Exposed filters.

The same problem:

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

"Limit to selected items" has helped me greatly! Thanks a lot!

Still a bug to be fixed in both D7 & 8 :)

i can confirm this problem still on views 7
the patch #94 is working fine and its fixed but you should include it on the next core version

I repear this error by selecting "group filter" and making list of all avalible option by hands (one by one). Without it I can make a select list without "any" option otherwise error displayed. Hope this help to somebody.

None of the patches above is working with grouped filter.

#86 worked for me as well, thanks mistermoper

[See next comment - problems with uploading patch]

There seems to be multiple conditions resulting in this message.

The situation I am facing is with an exposed filter that uses grouped options and where 'remember' is enabled. The problem is that the value retrieved from the session (ie the 'remembered' value) is expected to be the index of the group option (eg 'All', 1, 2) but the valued saved to the session is an array detailing the actual filter parameters. Therefore, when the loading the view the retrieved value (array) does not match any of the expected keys of the group option, resulting in the "illegal choice" error.

The attached patch changes the value stored in the session to be the selected group option index.

I can confirm that the patch in #105 fixes the problem on two of my sites that threw errors with "remember" exposed filters. Thank you ayduns!

I wanted to filter my view with a term reference field. My problem was that I had my term reference field marked as 'required' in the field settings of the content type, and had no default value set. So I got the 'Illegal choice' error.

The fix was to uncheck 'required field' in the field configuration (/admin/structure/types/manage/[content type]/fields/[field name]). Then I set 'Any' as the default value.

I got this from Abstracct's comment here.

Bumping to the next release.

Needs some further consideration, especially if it affects D8 too.

I have combined #9, #94 and #105 into one patch. Together these seem to fix the issue with the "- Any -" filters having a value of lowercase 'all' instead of uppercase 'All' and throwing errors.

Patch #110 works nicely here, thanks caesius!

#107 you pointed me in the right direction although a little different. I ran into this today and it appeared only at loading of the page when using grouped filters. Once I made a choice the issue vanished. I had ticked off optional and remember when setting up group filters and it seemed to cause this error as it ignored the default value.

Not sure why but ticking remember on seems to force it to use the default.

Although this is clearly a bug that should be fixed, I did want to say that #97 solved the problem for me without requiring any patches.

I still get this error with grouped filters using patch #110

#97 worked for me

This doesn't seem like it's quite ready yet.

The situation I am facing is with an exposed filter that uses grouped options and where 'remember' is enabled.

I had the same problem as #105 and that patch fixed it for me.

This helped me resolve my issue, this was only happening when i had the views attachments.
Otherwise the group filter was not giving me this error.

Patches used to resolve my issue:
https://www.drupal.org/files/issues/views-grouped_filters-2224601-4_0.patch
https://www.drupal.org/files/issues/views-fix-exposed-filter-illegal-cho...

Like #118, I had the same problem as #105 and the patch fixed it.

Was having the same issue and unfortunately none of the patches on this thread solved the issue. This is what I did to resolve it:

Create a hook_form_FORM_ID_alter() for the views exposed form, e.g. views_exposed_form. The following snippet is an example of a filter with range options. If your filter has more complex options then add conditionals as needed.

function MODULE_form_views_exposed_form_alter() {
  
  $field = 'FIELD_NAME_value'; // Replace FIELD_NAME with the field you're using to filter the content. It seems the suffix "_value" is needed, double check on that.

  // This condition is only invoked the first time the filter is used to prevent the error and keep track of the option successive uses.
  if (isset($form_state['input'][$field])) { 
    $input = $form_state['input'][$field];
    if (is_array($input)) {
      $range = "{$input['min']} - {$['max']}"; // Build the option as you set it on the view.
      $options = $form[$field]['#options'];

      $index = array_search($range, $options);
      $form_state['input'][$field] = $index;
    }
  }
}

I am experiencing this issue with checkboxes in my exposed form too. Any groups that do not have a checked box (all optional grouped filters with multi-select enabled) are automatically checked in all of the boxes when a sortable table header is clicked. This also triggers the "•An illegal choice has been detected." error.

Examining the url being passed by the sortable header link, I think the problem lies in the fact that the url is trying to pass the value 0 to indicated that the box should be unchecked.

http://10.131.63.20/taxa-test?MAJOR_GROUP_ID%5B1%5D=0&MAJOR_GROUP_ID%5B2%5D=0&MAJOR_GROUP_ID%5B3%5D=0&MAJOR_GROUP_ID%5B4%5D=0

Manually pasting ?MAJOR_GROUP_ID%5B2%5D=0 onto the end of the url results in the same error and checks the box. Changing 0 to 1 checks the box and removes the error. I have tried changing 0 to NULL, FALSE, "", and nothing ?MAJOR_GROUP_ID%5B2%5D= and I get the same checked box and error with each value. I cannot find a value that will result in the box being unchecked.

If I change from radios (checkboxes) to a select list, the problem disappears but I really want to use check boxes.

If anyone has ideas for valid "unchecked" values, or how to force the checkboxes to accept 0 as the unchecked value, or get the table headers to stop trying to write unchecked values to the url, I would love to hear them.

Thanks!

@katlian, I think I have the same issue as you. I have an exposed group filter, using radios, and when I tried to use the clickable headers to sort, all the grouped filters would be checked, I would get no results, and I would get the 'illegal choice' error. This patch resolved it for me: https://www.drupal.org/project/views/issues/1986306

As another solution.
I had a Drupal 7 view with grouped exposed filters on a date field. The view was paged. The error occurred when clicking on next or a page number. Reading some of the comments above I tried setting Ajax as true in the Advanced settings for the view and the issue disappeared.

I hope this helps someone else.

Thanks TechnoTim2010, I had the issue for one particular view and your solution solved the problem.

#44 works for me thanks

I had previously checked Remember last selection and selected a couple of roles. Later I unchecked this setting. It wasn't until I checked and unchecked it again that the error dissapeared.

I had a select list exposed and though the exposed filter worked I had this error message. Selecting "Limit list to selected items " makes the error go away :)

My fix was to change the name of the filter identifier in the MORE drop down:

/admin/structure/views/nojs/config-item///filter/activity_category_3

I change the filter identifier from "activity_category_3" to "activity_category".

The situation I am facing is with an exposed filter that uses grouped options and where 'remember' is enabled.

I had the same problem as #105 and that patch still fixes it for me. Views 3.24, patch applies with some offsets.

Created an issue fork branch based on #105.
https://git.drupalcode.org/issue/views-1177882/-/commit/d2d5afed955bf612...

I couldn't find a need for the first additional line of code from #105, so I didn't include it.

It seems like a lot of cases of the An illegal choice has been detected. Please contact the site administrator. error are being caused by the initial value of exposed grouped filters not being set/determined correctly.

So even if all possible causes are not resolved I think this fix should get committed.

Hello MustangGB,

I believe that this fix won't solve that issue. This solution requires the identifier to be unique. If the same identifier is used in a different View during the same session, that second view will get these values set as well.

This becomes even more complicated if you have 2 views opened in 2 different tabs and manipulate them at the same time...

It's being stored against each view (or actually view display) specifically, you can see that in the above line which is unchanged.
$session = &$_SESSION['views'][$this->view->name][$display_id];

Can someone please describe how to replicate the bug? Test coverage would be even better.

I didn't manage to get a test, but here are some repro steps:

1. Create a content type with a "List (text)" field with allowed values "apple|Apple, banana|Banana, carrot|Carrot"
2. Create a view with a page display
3. Add a filter for the list field:
   • Expose: Ticked
   • Grouped filters: Selected
   • Optional: Unticked
   • Remember: Ticked
   • Group item 1 | Default: Selected, Label: Apple, Operator: Is one of, Value: Apple
   • Group item 2 | Default: Unselected, Label: Banana, Operator: Is one of, Value: Banana
   • Group item 3 | Default: Unselected, Label: Apple or Banana, Operator: Is one of, Value: Apple,Banana
4. Views setting "Use AJAX: Yes"
5. Views exposed form setting "Autosubmit: Ticked" (can probably skip this step)
6. Save view and visit view page
7. Observe error message

After selecting an option from the select filter the error disappears, but logout and login and the error reappears.

Thanks for that. This is a WIP test, it doesn't include the actual test methods yet.

This needs test coverage before I feel comfortable committing it, just to avoid regressions.

Using Drupal8.9 I'm also getting this issue using an _form_views_exposed_form_alter and unset some terms value from the dropdwon exposed filter depending on which node i am. I'm calling my View block (ajax activated) and using 2 tabs I'm getting this error message and can't filter afterwards.