This happened with 7.x-3.0-beta3 as well. Anytime I used and exposed filter i get this error "An illegal choice has been detected. Please contact the site administrator." The filters work fine otherwise after that initial page load. From what I have gathered from other sources and my observations is that the field is some how defaulting to a non existent value? I'm sure this has been addressed before somewhere I just could not find it. Thanks for your help.

Members fund testing for the Drupal project. Drupal Association Learn more


dawehner’s picture

Status: Active » Postponed (maintainer needs more info)

Please help us to help you: Therefore read

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

bsztreha’s picture

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

dawehner’s picture

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.

Letharion’s picture

Priority: Critical » Major
Status: Postponed (maintainer needs more info) » Active

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.

Letharion’s picture

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.

Letharion’s picture

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

Letharion’s picture

Assigned: Unassigned » dawehner

Forgot to assign.

Letharion’s picture

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

dawehner’s picture

Status: Active » Needs review
669 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,627 pass(es). View

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.

Old Man’s picture

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"?

mototribe’s picture


dawehner’s picture

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

Old Man’s picture

97.2 KB
101.98 KB

@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.

morbiD’s picture

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.

desierto’s picture

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."

Old Man’s picture


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.

Ross-Hunter’s picture

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.

dawehner’s picture

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

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

desierto’s picture

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.

R13ose’s picture

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.

R13ose’s picture

Status: Needs review » Needs work
519.5 KB

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

dawehner’s picture

Which module produced the checkboxes?

R13ose’s picture

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

colan’s picture

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.

Countzero’s picture

This issue may be related to this problem :

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.

drumnjo’s picture


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

dawehner’s picture

Status: Needs work » Postponed (maintainer needs more info)

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.

samwillc’s picture

@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.

drumnjo’s picture

@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?



samwillc’s picture

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 :)

ownage’s picture

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?

ownage’s picture

72.83 KB

Also: attached is a screenshot of my view

ownage’s picture

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.

amogiz’s picture

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.

amogiz’s picture

@ samwillc #post 28

This was the solution for me ! Many thanks

mototribe’s picture

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

esmerel’s picture

Status: Postponed (maintainer needs more info) » Fixed
johnv’s picture

Status: Fixed » Active

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

joachim’s picture

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

gratefulsk’s picture

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

dawehner’s picture

Status: Active » Fixed

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

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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

davidwhthomas’s picture

@#40 Thanks! that was it.

awm’s picture

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;
$handler->display->display_options['filters']['status']['expose']['reduce'] = 1;

Hope this help.

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

bayousoft’s picture

#44 works for me!

Simon Georges’s picture

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

juanolalla’s picture

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.

linux_enthusiast’s picture

I think works. Thanks.

greg.harvey’s picture

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?

annahelin’s picture

Assigned: dawehner » Unassigned
Priority: Major » Normal
Status: Closed (fixed) » Needs work

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 :)

colan’s picture

dawehner’s picture

Status: Needs work » Fixed

Well all in all it still works.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

JMC’s picture

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.

razkovnik’s picture

Thank you for the explanation!

augustynen’s picture

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.

- 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.

mondrake’s picture

Status: Closed (fixed) » Needs review
3.24 KB
PASSED: [[SimpleTest]]: [MySQL] 1,627 pass(es). View


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.

mondrake’s picture

860 bytes
3.42 KB
PASSED: [[SimpleTest]]: [MySQL] 1,627 pass(es). View

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


mondrake’s picture

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

Adjusted issue title

apprayo’s picture

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.

mondrake’s picture

@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

p4trizio’s picture

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
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

Exploratus’s picture

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!!!

jghyde’s picture

3.46 KB
PASSED: [[SimpleTest]]: [MySQL] 1,652 pass(es). View

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.


Grayside’s picture

#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.

jayhawkfan75’s picture

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

Grayside’s picture

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

Grayside’s picture

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.

ndobromirov’s picture

#44 worked for me also!

JohnnyW’s picture

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 :)

Exploratus’s picture

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

markocall’s picture

If it's any help, the patch #5 in solved the issue for me (I am using multi select checkboxes)

Jochen Wendebaum’s picture

#14 worked for me....

ericwongcm’s picture

Issue summary: View changes

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

digital_dope’s picture

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']['#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...

jomarocas’s picture

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

fjen’s picture

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).

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

chems’s picture

Version: 7.x-3.x-dev » 7.x-3.8


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

Natural sciences <-- parent
-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
{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

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
{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

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

thx for your help.

opened issue :

filipes’s picture

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

-Mania-’s picture

8.15 KB

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.

SAA1973’s picture

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

Alan D.’s picture

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).

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';
rbrownell’s picture

rbrownell’s picture

sch2’s picture

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


mistermoper’s picture

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.

MustangGB’s picture

Version: 7.x-3.8 » 7.x-3.x-dev
Priority: Normal » Major

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.

Reis Quarteu’s picture

#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.

organicwire’s picture

#86 works for me.

fonant’s picture

Patch #64 seems to work for me.

mistermoper’s picture

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.

MustangGB’s picture

flebas’s picture

I have had this error message (from 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)) {

I hope this can help.

GeduR’s picture

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!

dawehner’s picture

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.

GeduR’s picture

mathiasmg’s picture

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

eva.ada’s picture

Version: 7.x-3.x-dev » 8.x-3.x-dev
Assigned: Unassigned » eva.ada
Status: Needs review » Fixed
Issue tags: +views exposed filters

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!

Alan D.’s picture

Version: 8.x-3.x-dev » 7.x-3.x-dev
Assigned: eva.ada » Unassigned
Status: Fixed » Needs review

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

B Boy Breaker’s picture

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

vmkazakoff’s picture

96.33 KB

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.

fiftyz’s picture

None of the patches above is working with grouped filter.

RickZebra’s picture

#86 worked for me as well, thanks mistermoper

ayduns’s picture

[See next comment - problems with uploading patch]

ayduns’s picture

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.

fonant’s picture

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!

beasley’s picture

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.

DamienMcKenna’s picture

DamienMcKenna’s picture

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

caesius’s picture

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.

caesius’s picture

fonant’s picture

Patch #110 works nicely here, thanks caesius!

scott.browne’s picture

#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.

dazweeja’s picture

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.

loze’s picture

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

seanansa’s picture

#97 worked for me

DamienMcKenna’s picture

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

markabur’s picture

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.’s picture

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:

argiepiano’s picture

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