Posted by mongolito404 on January 26, 2011 at 12:56pm
16 followers
| Project: | Views |
| Version: | 6.x-2.16 |
| Component: | Code |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
When the query used to retrieve terms to build the value form for a "Taxonomy: Term ID" filter is rewritten, only a single term is returned in the options.
The rewritten query use SELECT * and when it is rewritten to contains a LEFT JOIN (for instance, by the Private Taxonomy module), the columns of the additional tables are added to the results. In this case, this cause the tid of the terms object returned by db_fetch_object to be null. So at the end, only the last DB result will be present in the build $options array.
Comments
#1
The attached patch fix this by restricting the results to the columns from the
term_datatable.#2
thank you, this fixed my problem too.
#3
In general a critical bug is a big which breaks a site with a WSOD.
This then should exist for many users.
Here we have a critical issue with just two users. Anyway this still makes sense.
Could you check whether there is a change needed for 7.x-3.x?
#4
7.x-3.x code uses the new DB API, so there is no change needed.
#5
I can confirm this now works, but a refresh is required and it took a few minutes to take hold.
I'd ask for this to be committed to the trunk because it really borked a lot of features I had on our production site and I'd hate to lose this fix in the next update.
#6
Patch looks fine
Commited to 6.x-3.x
#7
Automatically closed -- issue fixed for 2 weeks with no activity.
#8
Reopening this issue as it is also apparent in views 6.x-2.x (at least 2.14 upwards) - I noticed it happening when using Forum Access and my exposed filters stopped working for anonymous users.
I have created a patch for v6.x-2.16. It's my very first patch and I had to use a Windows box, so please be gentle.
#9
I actually thought that this patch is only worth for 6.x-3.x, but i think now it's important for 6.x-2.x as well.
So just used the previous patch. Thanks for providing the patch!
#10
Automatically closed -- issue fixed for 2 weeks with no activity.
#11
I had a similar problem, posted here: http://drupal.org/node/1361044 . No one replied, then fortunately I found this issue. I applied the patch and my problem is now fixed also - using Views 6.x-2.16. The problem was introduced with Views 6.x-2.14.
What's the procedure to request that this patch be included in the next release of Views?
#12
Has this patch been committed to the 6.x-2.x series?
#13
Our server has 2.16 on it, and we had the "Illegal choice detected" on our panels pane views with TID passed as an exposed filter. I needed to manually apply the patch in #8 to get rid of the message...
So either our FTP messed up when I updated Views, or this patch has not yet made it to a proper release. In either case I'm re-opening this for clarity's sake.
Thanks.
#14
You either have to download views 2.x-dev or wait for a future views 6.x-2.17
#15
Automatically closed -- issue fixed for 2 weeks with no activity.
#16
Reopening as the previously mentioned dev branch is now not available (don't know when it disappeared or why) and no sign of 6.x-2.17 yet.
Can we add this patch and release at least a 2.x-dev?
#17
Yeah, we really need a working solution for this nasty bug, because a lot of sites still using Views 2.x version.
#19
#8 has been committed allright.
The problem is #14:
No 6.x-2.17 has ever been created and the -dev version has been hidden. We're left with a buggy 6.x-2.16 and no upgrade path.
#20
#8: views-1040744-8.patch queued for re-testing.
#21
Still nobody can approve this trivial two-char patch?!
#22
It is approved and committed, but there is no release package (not even the -dev package) fresh enough to contain the fix.