Not all taxonomy terms showing up in exposed filter

I am getting the same behaviour. I have two taxonomy term filters, each taxonomy has three terms. But, only two of the terms show up in the lists.

I found out that the first term is deleted if the vocab is not required. The attached patch worked for me.

patch worked for me too. thanks yhager!

The patch failed for me but the bugfix worked, so I've rerolled it.

I'm not 100% sure this is the "right" way to do it, but it seems to work. It also seemed to introduce the side effect that my top term was selected, though that filter wasn't enforced.

greggles: No patch attached.

heh

Here's a revised patch, addressing the issue mentioned on comment #5.

Here's a revised patch, addressing the issue mentioned on comment #5.

Here's a revised patch, addressing the issue mentioned on comment #5.

For patchophobic, a temporary bypass can be to use the "Taxonomy: Term" filter which lists all the terms, in a big long list.

The patch works for me with no visible side effects.
Thanks yhager.

Just a quick question... can anyone tell me why the author deletes the first item in the first place?

@nterbogt : the intent here is to remove the ' option that is present in taxonomy selectors for non-required vocabularies, but is not relevant in the views filters context. Then forgetting to check if the vocab actually is required or not is a typo / negligence, I guess :-)

Let's mark this RTBC

Subscribing.

yched meant to say <All> option but his < got eaten. =)

Yes, this patch is RTBC, I just need to get back around to this. Hopefully soon.

I'm having this problem w/ 5.x-1.6-beta5 too. Should the Version of this issue be changed?

It definitely should. This a 1.6 bug only, AFAIK.

also missed the first taxonomy term in my exposed filters (and in views admin forms). But this patch worked for me, many thx!

Solution worked for me. bang it into CVS.

I've test the patch... the first term is still not visibile.

The latest patch fixed my terms not showing up, Thanks

latest patch worked for me

To those of you who are reporting that this patch is not working, try emptying the cache_views table after applying the patch. That worked for me.

Finally committed to -dev. =)

With 5.4, a fix in taxonomy was applied (http://drupal.org/node/180109). This means the first entry for optional filters does not have to be removed anymore. Attached a patch that establishes the wanted result.

Without this patch, the first taxonomy term doesn't show up, which is most definitely undesired behaviour.

This needs to be fixed so that it doesn't store the entire taxonomy tree in the views cache anyway.

I've used 1.6 and first term still won't show in terms list

I'm using 1.6 and the above patch worked for me without any visual side effects. But like merlinofchaos mentions this may not be the right way to do it anyway.

Lots of duplicates of this so changing status back to patch to make it more visible.

Patch from #28 applies cleanly and solves the issue for me.

patch in comment #28 works fine for me

+1 for this being released

This patch is already committed, there just isn't an official release which includes it yet (because the 1.7 release depends on more than just this patch). I marked this back to a patch status to make it easier to find but that seems to be giving the impression that it needs testing/lobbying to get committed - so back to fixed I guess.

[edit: Ignore - I forgot to clear the views cache]

This isn't working for me, not even the patch in #28

I am using views-1.6 and Drupal 5.7

My Taxonomy Term has a space in it -> "Friends Only", would that be the problem?

Regards,
tim

subscribing

The first term of a vocabulary that's not required still doesn't show up in Views. The committed patch didn't fix the problem.
Issue #180109: Only taxonomy term selected by default when there is only one broke the behavior of Views:

unset($form['#options'][0]);

Perfect, it's working fine for me!
But I had to clear the cache once or twice...

Perfect solution!
It even removed the "none" option which I was trying to get rid of for quite a long time. Hopefully this will stay the same in final version.
Thank you.

Hi Im new at this views thing Im getting the same problem with the first
term not displaying in my filter. I see the patch, I have no idea where to
put that code or how to implement that fix!

marcj

The patch in #39 works for me, with no apparent side effects.

@marcj: a good place to start learning about patches is http://drupal.org/patch. There's also a video on how to apply patches here: http://drupal.org/node/132745

marcj: I don't think you should go around patching files if you don't understand this. You will probably get your site into unworkable state sooner or later, and nobody will be able to help you.
These patches are meant for coders to send information to each other about a problem fix.

When a patch is approved and is good and working, it usually goes into the module - so you don't need to patch anything if you need a STABLE system.

Thanks for the link on patches, this is obviously a complex procedure (or not) what are the chances of breaking my website doing this I have weeks of work into this project I would hate to break it at this point in time.

Patch in 39 works for me too.

+1 for patch #39

I searched myself and I made the same patch without looking at this page. This is the right one.

Edit: I found something paradoxical

Original code:

    if (! $vocabulary->required) {
      unset($form['#options']['']);

This code says: if our vocabulary IS NOT required, then we CANNOT filter nodes which don't have any terms. But this is a nonsense, I want to be able to filter my view to display only nodes which does not have any terms of this vocabulary.

Should be:

    if ($vocabulary->required) {
      unset($form['#options']['']);

And this one says: if our vocabulary IS required, then we cannot filter node which don't have any terms. This is perfectly legal because in this case, it's absolutely impossible to have node without any terms (except in incoherent database state).

pounard: Actually, what that piece of code is saying is "If this vocabulary is not required, remove the '' entry that is added by the taxonomy module.

The problem is, as I've said before, this whole piece of code is wrong. Yes, the patch in #39 addresses this symptom of the issue, but it does not address a deeper underlying issue which is that the taxonomy form shouldn't be stored in the Views cache. This is an issue that I'm still waiting for someone to write a proper patch and it's the only reason I have not release a Views 1.7. There will not be a 1.7 until this issue is addressed.

Ok, but does the '-- none selected --' has sense when the 'all' option is there ? In the case where the vocabulary is required, '-- node selected--' and 'all' does the same stuff ? Whatever it is, 'none' with no terms does not exists, so use the 'all' which "disable" the filter, and use the 'none' which disable the filter, or filter the nodes with no terms (which does not exists) is a nonsense.

There is more sense to keep the 'none' and 'all' when taxonomy is not required, and remove the 'none' and keep only the 'all' in case it is required.

If the 'none' says "the user dont want to filter this field", I'm wrong, but in this case the 'all' does exactly the same stuff. But if the 'none' says "the user want the nodes with no terms", then the current code is illogical.

Edit: typo.

I'm sorry, replace all with 'none selected'. There isn't an all, that's exposed filters and it's added later, and my brain was conflating the two. There should definitely not be a 'None' option. That's very specific to the taxonomy selector UI in node editing.

I noticed this, and this is really confusing to have a 'none selected' and 'all' which does the same thing. I think the 'none' has just nonsense when the 'all' is added by the view module.

Patch 39 worked for me. Why hasn't this been committed?

@zcferres, #49 explains why it isn't committed.

@merlin, I didn't realize this was the holdup. I have also been struggling with custom form elements that get 'stuck' in the cache and trying to figure out what to do about them. (In my case I have been trying to add custom date form elements to views).

I think if we narrow the problem down, it only affects filters that use form elements. Those forms (and all their possible options) get cached in the view if the view is cached, which not only fills up the cache but also screws up FAPI processing.

One simple option is to automatically mark views that use filter forms to be uncacheable (as we do for any view with arguments). This would be a pretty simple fix (and it's the way I fixed it for the Date module).

A more complicated fix would be a flag of some kind on views that use filter forms to omit the form from the cached view and to re-create a fresh copy of the form when the view is viewed. That would obviously be more complicated, but would allow you to cache views that have filters.

Does this analysis sound right to you, or am I missing anything? And if I have this right, which way do you prefer to go?

It's not the individual view cache, it's the views data cache. It happens when you get something like this:

  'value' => array('#type' => 'select', '#options' => $options),

FOr taxonomy it's uglier than that since it actually goes and uses taxonomy.module's form widget, which seemed like a good idea at the time but turns out not to be.

Views supports replacing #options with a string which will be a function name to get the options in realtime. That's the recommended way to implement that.

The size of #options is not the only problem -- FAPI validation doesn't work right either and I've just generally had a hard time getting custom form elements to work correctly unless they are so simple that they don't use #process or #validate or any of the other FAPI processes. Try adding a #process function to a filter element -- it only gets triggered when the view is saved, not when the form is displayed, which really limits what you can do with it. I think this is why I could never get the GMap widget working right as an exposed views filter (I set it up so you could click on a map and use the location as the filter for your view, but I had to invalidate the data cache each time or the javascript wouldn't work).

And I know that part of this is getting stuck in the data cache, but other things are stuck in the view cache because some of my form problems go away if I keep the view from being cached. I've gone around and around trying to figure out where my forms were getting broken, I don't pretend that I have all the right answers, I just know fancy forms don't work well as Views filters.

It seems to me that substituting the options is not going to be as robust a solution as keeping the form element out of the cache altogether and generating it at runtime.

But maybe you only want to fix the #options problem since this is Views 1 and we now have Views 2, and that's fair enough, so I can try to roll a patch for that once I figure out how to get the substitutions working.

Data cache? View cache? Views only really has two caches here. There's the hook_views_tables() stuff and related, and there's the query cache. You've got me a little confused, now.

And yes, Fapi 2 doesn't deal at all with $_GET stuff, which is why #process and #validate don't work at all. Nothing to be done about it except use Views 2 instead.

The crux of what I was trying to say is that I can get some very fancy form elements working as Views filters one way or another if I can keep them out of the cache (I can retrieve the $_GET in my #process, or whatever I need to do). When they get stuck in the cache, only the simplest things will work.

But I've drug this issue far enough off track. I'm sorry for going off on a tangent. You only want to fix #options, so we should get back to that. Forget the rest of it.

Hm. Well you probably should be able to create a function that returns the entire fapi gadget. That makes sense.

Can someone please create a summary of this issue that exactly states what has been changed in the meantime, the effects of these changes, and what has to be done now?

The summary as I understand it: (And there's a new issue for this marked 1.7 pre-req #2 or something along those lines):

The gadget for taxonomy selection needs to be completely rewritten so that it does not utilize the taxonomy default select gadget, which is coded very specifically for selecting taxonomy terms on a node. Instead, Views needs to examine the vocabulary and determine if it should present an auto-complete or a select (or maybe even create multiple filters so it can present both, allowing people to choose; this is really valuable for exposed filters).

Then it needs to ensure that the select list is generated when the form gadget is rendered, not when it is embedded into the views data. This can be accomplished wiht '#options' => 'function_name' and function_name() will return the list of taxonomy terms.

The patch wasn't quite right due to a change in Drupal 5.4. Here is what the code should look like:

    $form = taxonomy_form($vocabulary->vid, 0, $vocabulary->help);
    unset($form['#title']);
    unset($form['#description']);
    if (!$vocabulary->multiple || !$vocabulary->required) {
      unset($form['#options']['']);
    }
    unset($form['#default_value']);

It's on line 243 of views_taxonomy.inc in 1.6.

Michelle

Those lines would translate into attached patch - at least I hope so.

Better title.

Patch in #63 works for me.

Subscribing.

Please do not only subscribe, please tell whether you applied the patch, and whether it worked for you, without breaking any other existing views.

Sorry. Actually I previously applied the fix as in #300898: First taxonomy term dropped from select lists and that has been working for me.
However that was recently marked as a duplicate of this issue, and as of # 62 here I see there is a similar but slightly more involved (and hopefully more correct) fix.
I will be trying that fix and see if it works as well or better.
In the meantime I wished to track this issue both for finding it again when I have more info, and for any future updates.
Hopefully that's a little more informative.

Patch in #63 worked for me

Patch in #63 worked for me after clearing views cache.
Thanks sun

Subscribing, will this patch go in please?
greetings, Martijn

Committed, thanks for testing.

@all: If you can, please test some other patches in the queue - thanks.

First term is missing for me as well as of today. All modules and core are up to date. (Drupal 5)

@robomalo - This was committed but hasn't been included into a point release yet: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/views/modul...

Maybe try out the dev version.

Michelle

This patch (#62) works fine, but I would like to retain the -Please select- at the top of my select box. How can I get that back?

Thanks

Glenn

Hi there!

#63 works for me too, marvellous, thanks

glennnz: at the top of mine, it would normally say "- None Selected -", not "- Please Select -". Is None selected what you mean? If you need that feature, just select all items, and then select the "Is None of" Operator.

Also, just to add to this (it wasn't obvious to me): after applying the patch, you need to either truncate your cache_views table, or disable and then re-enable the views modules.

Thanks for the patch!

I am using D7 and now I am experiencing a problem that taxonomy term is not displaying in Filter criteria of view. Please sent solution to solve the issue.

The differences between 5.x and 7.x are so huge I can't imagine it could possibly be the same bug and, besides, this one was fixed. I suggest you start a new issue for your problem and be sure to read the instructions for submitting a new issue.

Michelle