Use entity_label instead of term name for term reference exposed filters

I guess it would be a bit easier to read if we name the variable $term, because we already know the type of entity here.

Changed admin_summary() to reflect this as well.

Patch #2 worked for me.

I've tested it in different languages and I didn't find any issues at all.
Looks pretty clean solution, isn't it?

Upps, I found some notice here, look at line 124 of views_handler_filter_term_node_tid.inc

        if ($tree) {
          foreach ($tree as $term) {
            $term = taxonomy_term_load($term->tid);
            $choice = new stdClass();
            $choice->option = array($term->tid => str_repeat('-', $term->depth) . entity_label('taxonomy_term', $term));
            $options[] = $choice;
          }
        }

Seems like $term variable in the foreach has some more values than $term variable that loads the taxonomy term. Since they have same names, $term->depth will throw a notice because it doesn't exist.

I will try patch in #1, seems like it is taken care of this, and report here later on.

I have made a patch that combines both #1 and #2. I think we should keep $term as is, and add $entity as in #1. But #2 has one more change in line 352 that #1 hasn't, so I added it.

Patch #5 worked for me! Thanks a lot!

Changing status to needs review.

You should be using entity_load_multiple() instead of taxonomy_term_load(): the former should be quite more performant in this case.

Hi plach,
Thanks for the advice. Since entity_load_multiple seems to be available only for D8, I think this one could do the work:
taxonomy_term_load_multiple

As soon as I have something I will post it here.

Yeah, sorry, that will work too. I meant entity_load() :)

Hi all,
I've just follow the @plach comment and have come with an awesome performance improvement.
I have tested it with a 4.000 taxonomy terms vocabulary (didn´t use two languages since I am only testing performance issues between the different code), with a simple view (with and without hierarchy dropdown exposed filters) showing 10 nodes out of 2000.

Using Views "as is"

This means that taxonomy terms won´t be translated. The fastest way.
Executed: 125 quieries in 62,6ms

Using Views with 1651726-entity_label-5.patch

This means that taxonomy terms will be translated, but huge performance issue could come. That's bad.
Executed: 7979 quieries in 1433,54ms

Using Views 1651726-entity_label-11.patch (the one attached here)

This means that taxonomy terms will be translated using taxonomy_term_load_multiple(), but you might expect increase the execution sql time by three. This is the best alternative I've tested by now if I want to have the terms translated.
Executed: 124 quieries in 190ms

I have also tried entity_load(), and it worked as fine as taxonomy_term_load_multiple(), I have used taxonomy function because I think it is more clear, but feel free to modify it too if you think it is better entity_load().

I also think that the code from the patch could be better, so feel free to modify it or comment around this issue.

I have some questions:

1. In this piece of code
   

   -        $result = db_select('taxonomy_term_data', 'td')
   -          ->fields('td')
   -          ->condition('td.tid', $this->value)
   -          ->execute();
   -        foreach ($result as $term) {
   +        $result = taxonomy_term_load_multiple($this->value);
   +        foreach ($result as $entity_term) {
   

   I replaced the db_select for a taxonomy_load_multiple(), do you guys see any problem with this? (I don´t know, security reasons or whatever you can think of)

2. Also, filling the $tids array for taxonomy_load_multiple() function, needs an extra foreach, maybe there is a better php function that could do the work, but I couldn't find it.

Sorry, changing status

Possibly duplicate issue: #1857608: Translation doesn't affect exposed term filters due to bypassing entity system.

Related and should be merged, but there's some differences in what they cover. This issue has more followers, so I'd suggest merging the other issue here.

Hello,
I have red the #1857608: Translation doesn't affect exposed term filters due to bypassing entity system and I added some logic and functionality from there (@Crell patch):
1 - Logic for getting the taxonomy terms entities
2 - Changing db_select for EntityFieldQuery

I have one question in the number 2:
Using EntityFieldQuery we can add $query->addTag('term_access'), so I added it. @Crell or anybody see any problems with it? I know that there is some access problems with views, but I don´t know if adding this tag could cause any problems.

So I have made a new patch adding @crell's functionality and marked #1857608: Translation doesn't affect exposed term filters due to bypassing entity system as duplicated.

Please review, test it, change it or any other things will be very welcome.

Hi, I have applied the patch and it works fine.
The var $tids at line 159 is undefined:

Notice: Undefined variable: tids in views_handler_filter_term_node_tid->value_form() (line 159 of ...\sites\all\modules\views\modules\taxonomy\views_handler_filter_term_node_tid.inc).

I added $tids[] = $term->tid; in the foreach loop just above in line 156;

Thanks for the patch; taxonomy terms are translated correct.

Lines 159-163 are superfluous anyway, they do the same as the foreach loop above. I rerolled patch #15 using taxonomy_term_load_multiple.

Just wondering: What is the reason why we now even use EFQ, thought we did not in #11
Even yeah it's in the same spot, it seems to be that we don't need this convertion here? Afaik there is another issue which does exactly that.

#17: views-entity_label-1651726-17.patch queued for re-testing.

I tested Patch #17 Working fine for me, But I can't test on a large number of terms to check the performance issues.

No feedback on #18 yet :(

See also #1864870: Use entity_label() to display taxonomy terms, which I think is more or less duplicates this, without doing query conversions.

I tested Patch #17 on Views 7.x-3.7 on a web with 3 languages and localized terms.
Working fine at the moment on an exposed filter of 10 terms.
Before this approach i tried the suggested patch on https://drupal.org/node/1864870#comment-7775243 but didn't work.

Re-rolled according to #18.

Just like drupalerocant in#23, I first tried the patch in that link (which didn't work), and then tried the patch here in #24 on my stable version of Views-7x-3.7 and it works beautifully - the terms in my exposed filters are all translated now. I hope that this patch will be included in the next release of Views. Thanks, Stevel!

+++ b/modules/taxonomy/views_handler_filter_term_node_tid.inc
@@ -126,9 +123,15 @@ class views_handler_filter_term_node_tid extends views_handler_filter_many_to_on
+          $entities = taxonomy_term_load_multiple($tids);
+
+          foreach ($tree as $entity_term) {

Loading the terms but then not using the loaded terms, won't do any good... Updated patch.

This obviously needs some tests.

#26 so far working ok

Notice: Undefined property: stdClass::$depth in views_handler_filter_term_node_tid->value_form() (line 134 of /sites/all/modules/views/modules/taxonomy/views_handler_filter_term_node_tid.inc).

Using #17 -> Dosen't work on taxonomy term (translated) fields (generated from i18n views) but only on classic taxonomy term fields

regards
marko

An updated patch. The $depth property is set by taxonomy_get_tree, but not by taxonomy_term_load_multiple. Changed the patch to load entities with taxonomy_get_tree.

Looks good and works as advertised.

Seconding the RTBC. This solves an issue with the title module as well, which I have marked as a duplicate: #1540790: Views exposed filters - is there a way to make translated taxonomy terms display based on page language?

Patch provided in #29 works very well for me.

Can this be committed please?

Thank you very much

Patch provided in #29 it's ok for me too..
(Domain access, Entity translation (without taxonomy i18n).

Thanks soo much !

Hide old versions of the patch.

Hide some even older versions as well.

#29 works very well for me.
Thank you.

Thank you very much. Committed to 7.x-3.x

We might have to do something similar in drupal 8, on which this is clearly a bug.

Close, however, there are o fallbacks. So if there isn't a translated version of a term nothing appears. I've attached a screen grab of switching from English to French where only the first term has been translated.

Guys, this still doesn't work in Drupal 7 if it's used on a Search Index view display.

Using Views 3, and i18nviews dev (but I don't think it's related).

weird, in views preview (backend) extended filters are translated and on the website (frontend) extended filters all empty. aren't there the same functions being called???

I think this is already fixed in D8.
D7
$default .= entity_label('taxonomy_term', $entity_term);
D8
'#default_value' => EntityAutocomplete::getEntityLabels($terms)
D7
$choice->option = array($term->tid => str_repeat('-', $term->depth) . entity_label('taxonomy_term', $term));
D8
$choice->option = array($term->id() => str_repeat('-', $term->depth) . SafeMarkup::checkPlain(\Drupal::entityManager()->getTranslationFromContext($term)->label()));
D7
$options[$entity_term->tid] = entity_label('taxonomy_term', $entity_term);
D8
$options[$term->id()] = SafeMarkup::checkPlain(\Drupal::entityManager()->getTranslationFromContext($term)->label());
D7
$this->value_options[$entity_term->tid] = entity_label('taxonomy_term', $entity_term);
D8
$this->valueOptions[$term->id()] = SafeMarkup::checkPlain(\Drupal::entityManager()->getTranslationFromContext($term)->label());
So moving back to views queue.