Hi, I discovered the follow bug:

I have a node based view, with a relation to taxonomy terms from a specific vocabulary.

After adding a (exposed) filter (select or autocomplete) and mandatory based on the term I chose the correct vocabulary for the filter. After saving the filter and returning to it's settings, my selected vocabulary was not saved and the first vocabulary in my list was selected.

It doesn't save the selected option, which causes to break the view, because I have set it to be mandatory and the term does not match it's vocabulary. It causes the following error: No valid values found on filter: Taxonomy term: Term.

This option is probably widely used to create filtered archives for content based on taxonomy terms (that's what i'm using it for) so I marked this major.

I have no idea how to fix this, so unfortunately I can't provide a patch.

Thanks!

CommentFileSizeAuthor
#5 views-taxonomy-filter.jpg251.49 KBericclaeren
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ericclaeren’s picture

Priority: Major » Normal

Putting this priority to normal. Found out 2 things.

The error is caused because there's no term/option selected in the select list, while the option "Limit list to selected items" is not selected. You would expect when you don't select a term from the list and put the filter to mandatory, that it uses the first term. Seems that's not the case here.

Found the reason for the broken vocabulary choice.

In: views\modules\taxonomy\views_handler_filter_term_node_tid.inc on line 47 there's the following statement:

// We only do this when the form is displayed.
if ($this->options['vocabulary'] == 0) {
  $first_vocabulary = reset($vocabularies);
  $this->options['vocabulary'] = $first_vocabulary->machine_name;
}

Although I have set a value, and it's stored, the following returns true, so the value gets overwritten with the first vocabulary. When I change it to

// We only do this when the form is displayed.
if ($this->options['vocabulary'] === 0) {

It works like it suposed to. Does anyone know how this is possible?

Thanks.

dawehner’s picture

Status: Active » Postponed (maintainer needs more info)

What's the content of $this->options['vocabulary'] here for you? This special code should only be runned when a user doesn't have selected a vocabulary yet. Maybe this would help to understand the issue.

ericclaeren’s picture

Thanks for your reply, $this->options['vocabulary'] has contains the machine name of the selected vocabulary, when printed before this function, after the function it resets to the first vocabulary. The first funtion overwrites the existing one.

dawehner’s picture

Sure but how can $this->options['vocabulary'] == 0 if it's 'a random value'?

ericclaeren’s picture

FileSize
251.49 KB

Who spoke about a random value?

This code:

      var_dump($this->options['vocabulary']);
      
      // We only do this when the form is displayed.
      if ($this->options['vocabulary'] == 0) {
        $first_vocabulary = reset($vocabularies);
        $this->options['vocabulary'] = $first_vocabulary->machine_name;
      }
      
      var_dump($this->options['vocabulary']);

Produces this error:

Statustekst: parsererror
Antwoordtekst:
string(5) "uzine"
string(4) "tags"

The first var_dump returns the selected vocabulary, in my case uzine, while the second after $this->options['vocabulary'] == 0 statement returns a different value (the first vocabulary: tags). So after saving and returning to the term filter settings, the selected option is tags, instead of the stored value of uzine.

Quite weird.

My other problem is, after exposing the filter and set it to mandatory (sorry about the partly dutch translation).

Is that the input is not valid which produces the error:

Error:
No valid values found on filter: Taxonomy term: Term.

But the option, "Limit list to selected items" is not selected, so It should use all terms within the vocabulary (that's what I'm expecting) but that's not the case. Because of the error the view can't be saved.

Thanks, I appreciatie your help.

dawehner’s picture

I totally don't get why it's doing this but a check for === 0 makes sense, as the default value is 0

ericclaeren’s picture

Version: 7.x-3.0-rc3 » 7.x-3.0
Priority: Normal » Major

Anybody got an idea why I get this error No valid values found on filter: Taxonomy term: Term. on the exposed filter? It's driving me crazy :)

The view has filter:

Taxonomy Term > Dropdown
- Exposed = TRUE
- Required = TRUE
- Is one of
- LIMIT = FALSE

It should just use the first taxonomy term in the filter, and the preview displays the correct term, but then this error appears.

dawehner’s picture

what happens if you remove it and reconfigure it using a new vocabulary?
It would be kind of cool to have an easy way to reproduce.

ericclaeren’s picture

Hi dereine, unfortunately there is no difference when using a new vocabulary. Neither for both problems.

Problem of the error lies in the fact, that views thinks it has no input, when no item is selected in the list of limited terms of the exposed filter setting when the exposed filter is required.

While the input should be all available items (terms) when it's a required field, and when it's required and limit to.. is true, it should only use limited items instead of all.

esmerel’s picture

Status: Postponed (maintainer needs more info) » Active
cgdrupalkwk’s picture

I have the same problem. Has anyone found a solution?

Taxoman’s picture

Version: 7.x-3.0 » 7.x-3.x-dev
RobNL’s picture

@cgdrupalkwk I had the same problem in Views 7.x.3.7. The solution #1 did the trick for me.

tchurch’s picture

The solution in #1 seems to be redundant now after 7.x.3.7 as those lines were changed.

Does anyone have a solution to this yet?

tchurch’s picture

I did find a workaround.
To select a value in the list of terms allowed but leave "Limit list to selected items" unticked.

It seems to work then but one shouldn't need to select a term from the list.

chrisgross’s picture

Issue summary: View changes

6 years later, this bug still exists in the newest version of views.

fwood’s picture

7 years later it still exists. .. at least for me.