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.

Files: 
CommentFileSizeAuthor
#8 views-1040744-8.patch981 bytesearlofsandwich
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#1 views-1040744.patch1.15 KBpbuyle
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-1040744.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

pbuyle’s picture

StatusFileSize
new1.15 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-1040744.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

The attached patch fix this by restricting the results to the columns from the term_data table.

janis_lv’s picture

thank you, this fixed my problem too.

dawehner’s picture

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?

pbuyle’s picture

Priority:Critical» Major

7.x-3.x code uses the new DB API, so there is no change needed.

rickmanelius’s picture

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.

dawehner’s picture

Status:Needs review» Fixed

Patch looks fine

Commited to 6.x-3.x

Status:Fixed» Closed (fixed)

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

earlofsandwich’s picture

Version:6.x-3.x-dev» 6.x-2.16
Status:Closed (fixed)» Needs review
StatusFileSize
new981 bytes
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

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.

dawehner’s picture

Status:Needs review» Fixed

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!

Status:Fixed» Closed (fixed)

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

scooper’s picture

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?

justindavis’s picture

Has this patch been committed to the 6.x-2.x series?

Jim Kirkpatrick’s picture

Status:Closed (fixed)» Reviewed & tested by the community

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.

dawehner’s picture

Status:Reviewed & tested by the community» Fixed

You either have to download views 2.x-dev or wait for a future views 6.x-2.17

Status:Fixed» Closed (fixed)

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

batdesign’s picture

Status:Closed (fixed)» Needs review

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?

RedRat’s picture

Yeah, we really need a working solution for this nasty bug, because a lot of sites still using Views 2.x version.

salvis’s picture

#8 has been committed allright.

The problem is #14:

You either have to download views 2.x-dev or wait for a future views 6.x-2.17

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.

pcorbett’s picture

#8: views-1040744-8.patch queued for re-testing.

RedRat’s picture

Still nobody can approve this trivial two-char patch?!

salvis’s picture

It is approved and committed, but there is no release package (not even the -dev package) fresh enough to contain the fix.