hey there,

as the title says i want to create a view for a catalog handling multiple arguments using term names.
i really tried 100 different configurations using names. most times only the first arguiment gets recognized, other times the view is stuck in an infinite loop timing out.

i use the validation criteria "Term IDs separated by , or +" with the options allow multiple values.
however if i try to use "Term name converted to Term ID" as criteria i cant use the AND and OR operators anymore.

Any suggestions how to use the operations in conjunction with term names?

** Sidenote pulling in any taxonomy related relationsships didnt help :(((

here is my actual view using term ids, which by the way works like a charm:

$view = new view;
$view->name = 'taxonomy_view';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'taxonomy-view';
$view->core = 7;
$view->api_version = '3.0-alpha1';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['query']['options']['distinct'] = TRUE;
$handler->display->display_options['query']['options']['query_comment'] = FALSE;
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['pager']['options']['items_per_page'] = '10';
$handler->display->display_options['style_plugin'] = 'grid';
$handler->display->display_options['row_plugin'] = 'node';
$handler->display->display_options['row_options']['links'] = FALSE;
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['title']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['title']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 0;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 0;
$handler->display->display_options['fields']['title']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['title']['alter']['trim'] = 0;
$handler->display->display_options['fields']['title']['alter']['html'] = 0;
$handler->display->display_options['fields']['title']['hide_empty'] = 0;
$handler->display->display_options['fields']['title']['empty_zero'] = 0;
$handler->display->display_options['fields']['title']['link_to_node'] = 1;
/* Sort criterion: Content: Post date */
$handler->display->display_options['sorts']['created']['id'] = 'created';
$handler->display->display_options['sorts']['created']['table'] = 'node';
$handler->display->display_options['sorts']['created']['field'] = 'created';
$handler->display->display_options['sorts']['created']['order'] = 'DESC';
/* Contextual filter: Content: Has taxonomy term ID */
$handler->display->display_options['arguments']['tid']['id'] = 'tid';
$handler->display->display_options['arguments']['tid']['table'] = 'taxonomy_index';
$handler->display->display_options['arguments']['tid']['field'] = 'tid';
$handler->display->display_options['arguments']['tid']['default_argument_type'] = 'fixed';
$handler->display->display_options['arguments']['tid']['default_argument_skip_url'] = 0;
$handler->display->display_options['arguments']['tid']['summary']['number_of_records'] = '0';
$handler->display->display_options['arguments']['tid']['summary']['format'] = 'default_summary';
$handler->display->display_options['arguments']['tid']['summary_options']['items_per_page'] = '25';
$handler->display->display_options['arguments']['tid']['specify_validation'] = 1;
$handler->display->display_options['arguments']['tid']['validate']['type'] = 'taxonomy_term';
$handler->display->display_options['arguments']['tid']['validate_options']['vocabularies'] = array(
  'catalog' => 'catalog',
  'tags' => 0,
);
$handler->display->display_options['arguments']['tid']['validate_options']['type'] = 'tids';
$handler->display->display_options['arguments']['tid']['validate_options']['transform'] = 0;
$handler->display->display_options['arguments']['tid']['break_phrase'] = 1;
$handler->display->display_options['arguments']['tid']['add_table'] = 1;
$handler->display->display_options['arguments']['tid']['require_value'] = 0;
$handler->display->display_options['arguments']['tid']['reduce_duplicates'] = 0;
$handler->display->display_options['arguments']['tid']['set_breadcrumb'] = 0;
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 0;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
  'product_display' => 'product_display',
);

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'page');
$handler->display->display_options['path'] = 'taxonomy-view';

/* Display: Feed */
$handler = $view->new_display('feed', 'Feed', 'feed');
$handler->display->display_options['pager']['type'] = 'some';
$handler->display->display_options['style_plugin'] = 'rss';
$handler->display->display_options['row_plugin'] = 'node_rss';
$handler->display->display_options['path'] = 'taxonomy-view.xml';
$handler->display->display_options['displays'] = array(
  'default' => 'default',
  'page' => 'page',
);
$translatables['taxonomy_view'] = array(
  t('Master'),
  t('more'),
  t('Apply'),
  t('Reset'),
  t('Sort by'),
  t('Asc'),
  t('Desc'),
  t('Items per page'),
  t('- All -'),
  t('Offset'),
  t('All'),
  t('Page'),
  t('Feed'),
);

thanks in advance

fooby

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fooby’s picture

FileSize
6.44 KB

i attached a different approach using a relationship to the taxonomy.
the contextual filter (Has taxonomy term ID) is linked to the relationship and validation is using "Term name converted to Term ID", also i enabled "Allow multiple filter values to work together".
As described in my earlier post everything after the first argument gets ignored.

To specify my needs:

the catalog should be able to filter by multiple terms names using contextual filters.
for example:

product1 has taxonomy 1 2
product2 has taxonomy 1 3
product3 has taxonomy 1 2 3
product4 has taxonomy 1 4

example.com/taxonomy-view/1/4 should only show product 4
example.com/taxonomy-view/2/4 should only show nothing
example.com/taxonomy-view/1/2 should only show product 1 and 3
example.com/taxonomy-view/1/3 should only show product 1,2 and 3

wheter this is with "/" using multiple arguments or operators "+" and "," using only 1 argument doesnt matter.
the important thing is to make it work with term names

fooby’s picture

FileSize
5.94 KB

here my first view as attachment

dawehner’s picture

So you are right this is not possible at the moment without custom code.
If you want you could extend modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc to support this.

fooby’s picture

unfortunately im not that into module development yet.
would it be difficult to implement this?

fooby’s picture

i created a patch file and a corresponding view

names are now converted and checked properly, but the AND operator doesnt work.

i could use a review. this patch is for 3.0-rc1

note: there are still some prints while its not finished

dawehner’s picture

Category: support » feature
Status: Active » Needs review

Update status

fooby’s picture

Category: feature » support
Status: Needs review » Active
FileSize
13.86 KB

catalog_test_with_converted_name.txt was not reusable

adding updated version

fooby’s picture

Status: Active » Needs review
wmostrey’s picture

Status: Needs review » Needs work

The patch is still full of dev comments and includes a <pre>. Apart from that, it doesn't work as expected. Entering just one element returns no results, and the operator always seems to be "and", whether "," or "+" is provided.

wmostrey’s picture

There's also an issue with this patch for terms that contain spaces because of views_break_phrase_string().

item 1,item 2 gets rendered correctly into:
[0] => item 1
[1] => item 2

item 1+item 2 however gets rendered into:
[0] => item
[1] => 1
[2] => item
[3] => 2

This causes incorrect results. The views option to turn spaces into dashes doesn't seem to help for this issue.

sokrplare’s picture

Status: Needs work » Needs review
FileSize
4.53 KB

Wrote a patch for this that is working well for me. Decided to start from scratch after reading comments 9 and 10, plus fooby's comment 4 (admirable that you were still willing to take a stab at a patch, fooby!)

Some notes and known issues that I need direction on:

  1. Per comment 10, the views_break_phrase_string() issue - it looks like there is close to a working patch in #1027458: Allow to use multiple arguments with spaces so will probably just wait for that to be finished as it is the proper place to handle spaces
  2. My Drupal $query knowledge is lacking, so wasn't sure how to convert the $query->where("replace(td.name, ' ', '-') = :name", array(':name' => $convert)); line into something that works with IN, so for now this won't work if you have the Transform spaces into URLs option turned on
  3. I found usages of function process_summary_arguments(&$args) in theme\theme.inc, but can't figure out where those would be rendered or what it really does or how to see/test it? I just added in 'convertterms' to run through the same code that was already there for 'convert', but probably not a good idea since I don't know what it does!
  4. Final question is - since I basically took the Term IDs separated by , or + and Term name converted to Term ID options and mushed them together, it is running two queries for effectively the same data. I think we can drop the second and just use the data picked up in the first, however I wasn't sure if that would skip/hurt/mess-up the little $validated_cache section?

Status: Needs review » Needs work

The last submitted patch, 1248300-11-views-taxonomy-multiple-terms-filter.patch, failed testing.

sokrplare’s picture

Status: Needs work » Needs review
FileSize
4.41 KB

Changing directories from /sites/all/modules/contrib to just /sites/all/modules in hopes of making the testbot happy.

Status: Needs review » Needs work

The last submitted patch, 1248300-13-views-taxonomy-multiple-terms-filter.patch, failed testing.

sokrplare’s picture

Ah, apparently needs to be relative to the views directory - better luck this time I'm hoping? Sorry for the thread spam, learning here.

sokrplare’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1248300-15-views-taxonomy-multiple-terms-filter.patch, failed testing.

sokrplare’s picture

Version: 7.x-3.0-rc1 » 7.x-3.3
Status: Needs work » Needs review

Alright, apparently I need some help on getting this patch to apply too! Ah, maybe the Views version as I'm working with 7.x-3.3. Come to think of it, probably need to re-roll this against dev, but going to first see if this will do the trick.

sokrplare’s picture

sokrplare’s picture

Re: views_break_phrase_string() - I tried applying the patch from comment 10 in #1027458: Allow to use multiple arguments with spaces but it didn't do the trick. Seems to come down to this in \includes\handlers.inc:

    // The '+' character in a query string may be parsed as ' '.
    $handler->operator = 'or';
    $handler->value = explode(' ', $str);

I changed this to:

    // The '+' character in a query string may be parsed as ' '.
    $handler->operator = 'or';
    if(!empty($handler->options['use_plus_separator'])) {
      $handler->value = explode('+', $str);
    } else {
      $handler->value = explode(' ', $str);
    }

Then I added that in when it called through like this:

        $terms = new stdClass();
        $terms->value = $argument;
        $terms->options['use_plus_separator'] = TRUE;
        $terms = views_break_phrase_string($argument, $terms);

Did the trick, but not sure it is the best way?

sokrplare’s picture

Found a bug in my patch today, need to check if any terms returned after doing the first query. Will add to new patch file, but need help figuring out why it is failing testing. In the meantime:

        // No terms is not valid so return
        if (count($test) == 0) {
          return FALSE;
        }
tim.plunkett’s picture

Version: 7.x-3.3 » 7.x-3.x-dev
Category: support » feature
Status: Needs review » Needs work

Please reroll the patch against the dev version and reupload it. It will only pass tests against the dev.

sokrplare’s picture

Here we are against dev - fourth try lucky?

sokrplare’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 1248300-22-views-taxonomy-multiple-terms-filter.patch, failed testing.

elliotttf’s picture

The patch looks pretty good and worked for me. One comment, there's a few lines that are commented out:

+        if ($transform) {
+          // TODO - change from WHERE to use IN in a Drupal-ized way
+          //$query->where("replace(td.name, ' ', '-') = :name", array(':name' => $convert));
+        }

Otherwise this looks great and worked for the cases I tested with.

sokrplare’s picture

Thanks for testing - yeah, the commented out lines are what I'm needing some guidance on (see comment 11, item 2 above).

naught101’s picture

Title: how to create a view handling multiple arguments on taxonomy using term names » Contextual filters: Taxonomy filter validation using multiple term names

I think the patch isn't applying with the test bot because it's using windows-style formatting for the file name (the directories are separated by "\\" instead of "/"). I replaced that and the patch applied ok. Also, watch out for excess whitespace.

naught101’s picture

Little hacking. Still needs work. This version treats both "," and "+" as "OR". Not sure where that is dealt with yet.

naught101’s picture

Status: Needs work » Needs review
FileSize
4.41 KB

Um.. so as far as I can work out, there is no AND in views' taxonomy filters:

views_handler_argument_term_node_tid_depth.inc:

 36     $form['break_phrase'] = array(
 37       '#type' => 'checkbox',
 38       '#title' => t('Allow multiple values'),
 39       '#description' => t('If selected, users can enter multiple values in the form of 1+2+3. Due to the number of JOINs it would require,     AND will be treated as OR with this filter.'),

Go figure. I guess this is working for me, aside from that one major problem, which probably should be dealt with as a separate bug.

naught101’s picture

acrollet’s picture

This patch is working well for me, except the logic was inverted when converting hyphens to spaces in term names. Patch attached that corrects that issue and cleans up the comments. I otherwise consider this code RTBC.

acrollet’s picture

Looks like I spoke slightly too soon, this version declares $test as an array before adding elements to it to eliminate a php notice.

mpgeek’s picture

I can confirm that the patch at #34 works as designed. One caveat is that you cannot use placeholders in the path setup for full page views. For example, products/%/%/% as the Path under Page Settings causes a few PHP warnings and a broken view. Removing the placeholders from that setting, i.e. just products allowed a three-vocab view with multiple term names for each contextual filter to work as expected. Further, using %1, %2, and %3 still worked in breadcrumb and title overrides, too.

Nice work @acrollet, ye really saved a show stopper for me.

acrollet’s picture

slightly improved version of the patch attached.

naught101’s picture

Status: Needs review » Reviewed & tested by the community

Code looks good, works for me, with the caveat in #32.

josaku’s picture

My problem is a bit different from the issue here, which "term name converted to term id" returns only one tid even if there are several tids having the same name (for example, in different levels).

For this problem, #36 also works for me.

Maybe, similar patch is required for "term name converted to term id" to make it compatible with multiple tids of one word.

yechuah’s picture

dawehner’s picture

It is great that there are some manual tests!

+++ b/modules/taxonomy/views_plugin_argument_validate_taxonomy_term.incundefined
@@ -189,6 +190,97 @@ class views_plugin_argument_validate_taxonomy_term extends views_plugin_argument
+        $query = db_select('taxonomy_term_data', 'td');
+        $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
+        $query->fields('td');
+        $query->fields('tv', array('machine_name'));
+        if (!empty($vocabularies)) {
+          $query->condition('tv.machine_name', $vocabularies);
+        }
...
+          $query = db_select('taxonomy_term_data', 'td');
+          $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
+          $query->fields('td');
+          $query->fields('tv', array('machine_name'));
+          $query->condition('td.tid', $test);

Won't it be possible to replace these two queries with an entity field query?

yechuah’s picture

Couldn't get #36 to work. Created a rough patch for my needs.

WaPoNe’s picture

Hi,
what is the solution/patch for D6 (View 6.x-3.0-rc3)?

Thanks,
WaPoNe

mikeker’s picture

@WaPoNe, there is no D6 solution at this time. It may be possible to backport once a D7 solution has been settled on.

@yechuah, please don't upload a new patch without setting the issue to "needs review". Also, if you could give us more information about what didn't work about #36 that would be helpful. #36 is working fine for me.

In addition, #41 has several problems including not recognizing the transform option (convert spaces to -) and uses regex's instead of views_break_phrase_string().

Lauren Kelly’s picture

We are running into a problem with this - I've tried #36 and #41 (best results were with #41, #36 only returned a query for the first term name) -has anyone else run into this?

Content managers are supplying a comma separated list of taxonomy terms (apple,orange,banana) for a contextual filter (using Insert View).

We had tested prior to to content being added en masse, but now we are seeing results that are different from what we expected (and most certainly from what the results when we tested in November)

If the manager specifies apple - the view outputs nodes tagged with apple. If the manager specifies orange - the view outputs nodes tagged with orange. If the manager specifies apple,orange (or apple+orange) - the view outputs the nodes tagged with apple If the manager specified orange, apple - the view outputs the nodes tagged with orange.

The query ends up including

WHERE (( (field_data_field_something.field_something_tid = '3903+3904' ) )AND(( (node.status = '1') AND (node.type IN ('content_type')) )))

What we are expecting to see is:

If the manager specifies apple,orange - the view outputs all nodes that are tagged with apple OR orange.

Anyone have any ideas on what might we might try to fix this or on what might have updated between Nov and March that would have changed the behavior on this? We tested apples,oranges and verified that we got posts from both apples and oranges in the results.....

davidsheart02’s picture

Status: Reviewed & tested by the community » Needs work

The patch in #36 is breaking up terms containing spaces because of the call to views_break_phrase_string which will "Determine if the string has 'or' operators (plus signs) or 'and' operators (commas) and split the string accordingly. If we have an 'and' operator, spaces are treated as part of the word being split, but otherwise they are treated the same as a plus sign." Needs more work to ensure taxonomy term names with spaces are able to be passed without being parsed.

davidsheart02’s picture

Status: Needs work » Needs review
FileSize
4.8 KB

Revised the patch from #36 with a temporary replacement of space characters in terms with the pipe character to allow taxonomy term names with spaces to pass through views_break_phrase_string without being parsed.

Just to clarify, this revised patch addresses the issue brought up towards the beginning of the thread. I agree that the proper place for the fix is in the views_break_phrase_string() file... but it looks like there hasn't been any movement on that front in a while. Maybe once that fix is in place, my code could be removed.

ssoulless’s picture

FileSize
31.09 KB

It seems that the patch in #46 has errors take a look to the screenshoot

ssoulless’s picture

I applied the patch in #46 and worked like a charm AWESOME!

Im using Insert view module, and now my editors can pass multiple taxonomy term names separated with + or , as argument. Thank you very very much =)

Just take a look to my previuos comment, the git showed me some warnings.

knalstaaf’s picture

I'm having the exact same issue as described by Lauren Kelly in #44: the view would only show the nodes related to the first term it comes across with, ignoring all the other terms that are checked as well.

In my contextual filter (has taxonomy ID with depth) I checked "Allow multiple values" and "Filter by items that share one of the terms" to broaden the filter, but to no avail.

The patches in both #36 nor #46 resolve this issue.

Mind that the terms (or arguments) are not visible in the url (I don't think they should, because this works for one term without it showing in the url).

If this is a bug, then it's quite a concerning one.

knalstaaf’s picture

I decided to abandon the idea of using taxonomy to serve my purpose, and called in the help of Entity Reference, which seems to do the job quite well.

I'm aware this is not a one-fits-all solution, but here's what I did.

As an example we'll use natural resources that can be used in several sectors.

  1. We're having 3 sectors: construction, car industry and furniture. Whereas this would normally be stuff for taxonomy terms, these will now be nodes of the content type "Sector",
  2. Next we create a content type called "Resource", from which the nodes will be assigned to "sectors",
  3. In the content type "Resource" we add an entity reference field called "Can be used in" (or whatever label you want). The entity (content type) we'll be selecting on the configuration page of that field is "Sector",
  4. Once that's done, we can go over to the creation of a view. Add some fields to your view and then go for the following contextual filter: "Content: Sector" and provide "Content-ID from URL" as the default value,
  5. Make it a block, add this block to a region of choice, and let it display on nodes of the type "Sector".

    You're done.


If you now create a Resource-node (e.g. "Steel") you'll have the option to assign it to one or more Sectors:
  • Steel can be assigned to the sectors car industry and construction
  • Wood can be assigned to the sectors construction and furniture
  • Rubber can be assigned to the sector car industry

After doing this you'll notice that all the related nodes (resources) are displayed correctly in the views block on every node of the content type "Sector". The views block on the node about e.g. construction will show related nodes such as steel ànd wood. On the node about the car industry, steel and rubber will be displayed as related nodes, and so on.

You can add several entity reference fields to one particular content type. It's also possible to check several content types in one entity reference field as well - whatever makes your client comfortable.

MatthewHager’s picture

Status: Needs review » Reviewed & tested by the community

#46 works for us. Thanks!

ladybug_3777’s picture

#46 works somewhat for me. When I use a comma it's acting like an "OR". When I use a plus, it fails validation (giving me a page not found).

I was expecting (Based on the helper text in views) the following:

Allow multiple values
If selected, users can enter multiple values in the form of 1+2+3 (for OR) or 1,2,3 (for AND).

Also, I wasn't expecting the plus sign to fail validation completely.

I'm noticing other reports in other issues for views regarding the workings of plus vs commas. I want to confirm the expected behavior compared to what I see.

mark_fullmer’s picture

In lieu of the Views module incorporating this change, it would be preferable to extend the existing class (thank you, OOP!) rather than patch the file, to avoid re-applying the patch each time you update the Views module. The attached is an example. Just remember that you'll also need to create a mymodule.views.inc file that registers your class, with code as follows:

/**
 * Implements hook_views_plugins().
 */
function mymodule_views_plugins() {
  $plugins = array();
  $plugins['argument validator'] = array(
    'taxonomy_term' => array(
      'title' => t('Taxonomy term'),
      'handler' => 'mymodule_views_plugin_argument_validate_taxonomy_term',
      // Declaring path explicitly not necessary for most modules.
      'path' => drupal_get_path('module', 'mymodule')
    ),
  );

  return array(
    'module' => 'views', // This just tells our themes are elsewhere.
    'argument validator' => array(
      'taxonomy_term' => array(
        'title' => t('Taxonomy term'),
        'handler' => 'views_news_views_plugin_argument_validate_taxonomy_term',
        'path' => drupal_get_path('module', 'mymodule')
      ),
    ),
  );
}

And you'll also need to add both as files[] in the .info file.

See extending a Views plugin.

colan’s picture

We've recently switched our testing from the old qa.drupal.org to DrupalCI. Because of a bug in the new system, #2623840: Views (D7) patches not being tested, older patches must be re-uploaded. On re-uploading the patch, please set the status to "Needs Review" so that the test bot will add it to its queue.

If all tests pass, change the Status back to "Reviewed & tested by the community". We'll most likely commit the patch immediately without having to go through another round of peer review.

We apologize for the trouble, and appreciate your patience.

colan’s picture

Status: Reviewed & tested by the community » Needs work
joelpittet’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
4.8 KB

Re-uploading previously RTBC'd #46 for testing.

colan’s picture

Project: Views (for Drupal 7) » Drupal core
Version: 7.x-3.x-dev » 8.1.x-dev
Component: taxonomy data » views.module
Status: Reviewed & tested by the community » Needs work

Given that the author says there's a better way to do this, and there are reports of it not always working, let's get this done properly in D8 first. We can then backport to D7 afterwards.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

orizonmedia’s picture

For me #56 dont work with any views version (7.3 r 7.3 dev) I see the added line (term name separated with + ,... ) I can make a preview with two term ex: apple+orange that work but didnt work in browser... any have suggestion?

thank you

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

valthebald’s picture

Issue tags: +Needs tests
FileSize
616 bytes

Here's quick proof of concept for 8.x. This issue deserves a test of course, so staying at 'Needs work'.
Validation of multiple values is actually working, it's query() stage when multuple values break. So I am not sure whether this issue still relevant, and the patch actually belongs to #1762770: Contextual filter issues while passing multiple taxonomy selections from node, to pages, to views

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

wrg20’s picture

+1 following

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.