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.

CommentFileSizeAuthor
#8 views-1040744-8.patch981 bytesearlofsandwich
#1 views-1040744.patch1.15 KBpbuyle

Comments

pbuyle’s picture

pbuyle commented
StatusFileSize
new views-1040744.patch1.15 KB

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

janis_lv’s picture

janis_lv commented

thank you, this fixed my problem too.

dawehner’s picture

dawehner
Primary language German
commented

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

pbuyle commented
Priority: Critical » Major

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

rickmanelius’s picture

rickmanelius commented

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

dawehner
Primary language German
commented
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

earlofsandwich commented
Version: 6.x-3.x-dev » 6.x-2.16
Status: Closed (fixed) » Needs review
StatusFileSize
new views-1040744-8.patch981 bytes

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

dawehner
Primary language German
commented
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

scooper commented

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

justindavis commented

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

jim kirkpatrick’s picture

jim kirkpatrick commented
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

dawehner
Primary language German
commented
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

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

RedRat commented

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

salvis
he/his
commented

#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

pcorbett commented

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

RedRat’s picture

RedRat commented

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

salvis’s picture

salvis
he/his
commented

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

chris matthews’s picture

chris matthews commented
Issue summary: View changes
Status: Needs review » Closed (outdated)

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue