This one took me a while to track down.

Symptoms:
1. sometimes exposed filters only remembered their last settings or would revert to one never selected.
2. sometimes error An illegal choice has been detected. Please contact the site administrator from _form_validate in form.inc
3. works fine in views edit live preview mode

Cause:
Having the same filter identifiers for different views on the same page (such as page+block). The argument will get sent to the unintended view.

Sounds like common sense right not to use the same filter identifier, but it can be very tricky, you may not even know what other identifiers are in use.

Recreate: (I'm pretty sure this is all, I had block caching on aswell)

  • block (I used Calendar block) with a unexposed filter for node type (identifier = type).
  • page with an exposed filter for Taxonomy Term (identifier = tid).
  • change the taxonomy filter identifier to 'type'
  • view page and block simultaneously outside of views edit
  • select taxonomy term

*I had set the label to 'Type' (cause who wants the user to see 'Taxonomy Term') and wanted to match the identifier

I didn't at all consider the block with the unexposed node type filter. When in views edit mode, I never had a problem with the live preview. When I tried the actual page and setting a filter I got errors (listed above).

Resolution:
this is a tricky one I'm not sure heres one option...
include view/form name with arguments by prepending identifiers or by adding an extra parameter

Thanks, Derek
(now i'm off to go change all my identifiers, sigh)

Comments

funkmasterjones’s picture

funkmasterjones commented

Try it with caching enabled on both, I think this was causing arguments to get passed to the wrong view

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (works as designed)

This is not a bug, this is a misconfiguration.

1) Exposed filters are never referred to as arguments, so by using that word you're *really* confusing the issue. It took several readings to really get this. What you are talking about is only true for exposed widgets.

2) There is no way for Views to know that if an exposed filter with the identifier 'type' is destined for your view or a different view.

3) It is actually intended to be able to use the same identifiers to keep two separate exposed filter sets in sync, though this is a rarely used and rather cranky feature.

In short, this is not really a fixable situation. It is definitely not a bug.

merlinofchaos’s picture

merlinofchaos commented
Title: Block steals arguments from page if they have the same filter identifier » Multiple views with the same exposed widget identifier will all use the same input

Retitling to get rid of reference to 'argument' in issue title.

funkmasterjones’s picture

funkmasterjones commented

thanks that's a much better title
I used the word 'arguments' to refer to the url query parameters (but these are not normally referred to as arguments either)

I understand in (3) that someone may want to sync the filters, so perhaps there should be a warning in the views edit form or after pressing the analyze button. Default identifiers like 'tid' will cause filters to sync with unrelated views or when it is not intended which is most of the time.

Of course, this is low priority, but its quite a tricky problem to track down for those not very familiar with views.