Download & Extend

Views Arguments+Content Taxonomy: Allow multiple terms per argument (1,2,3) AND not working

Project:Views
Version:6.x-2.11
Component:Miscellaneous
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

I wish I knew if this were a Views issue or a Content Taxonomy issue, and I apologise in advance for cross posting.

Here's my setup:

1) Install Views and Content Taxonomy (allows taxonomy terms to be used as CCK fields)
2) Create a taxonomy with (at least) two terms.
3) Create a content type with one Content Taxonomy CCK field, linking to the taxonomy, with multiple values permitted.
4) Create three nodes of that content type: One with term A, one with term B, one with both term A and B.
5) Create a view, with a filter on that node type, and with an argument of the taxonomy term. Allow multiple arguments for the taxonomy term.

Let's say Term A's tid is 129 and Term B's tid is 131.

Node 01: Term A (129)
Node 10: Term B (131)
Node 11: Term A and Term B (129 and 131)

Now what apparently should happen is that if you use commas to delimit the argument terms, there should be an exclusive and:

/myview/129,131 should return ONLY Node 11.

However it's behaving identically to /myview/129+131, returning all three nodes.

I'd be happy to help debug and patch this if I knew where to start looking. Any pointers or hints you could provide would be a great help.

Thanks in advance!

Comments

#1

Status:active» closed (won't fix)

After attending the Pacific Northwest Drupal Summit this weekend and attending some insightful lectures on views, I'm almost certain this is a Content Taxonomy problem and not a Views problem. If anyone finds this looking for a fix, follow this thread instead...

http://drupal.org/node/924646

I'll see if I can work on a patch myself for this. :)

#2

Hi,

I am having the same issue, but I found a note on using multiple arguments

If selected, users can enter multiple arguments in the form of 1+2+3. Due to the number of JOINs it would require, AND will be treated as OR with this argument.

So, this is not a bug but a limitation to this feature.

I am still looking for modules to override this :D

#3

Hey Daniel... sorry I didn't see this earlier...

We managed to work out a patch to the Content Taxonomy module that fixes this. Actually, AND should take less computing power than OR, as it's just a SQL SELECT IN (itemA, itemB, itemC) style list.

Here's that fix: http://drupal.org/node/924646#comment-3653366 . dereine was awesome working with me in IRC to find the fix. It's definitely not a Views issue but rather a Content Taxonomy issue.

#4

Thanks Trevor... I'll take a look.

I also found somewhere, I am not sure where that I should use Taxonomy Term and NOT Taxonomy Term (with depth) in the argument, this way AND is treated as really AND and not OR. And tried this, and it works.

thanks,
daniel

#5

@TrevorBradley

It is not a content taxonomy module issue. It is a Views core issue. I have experienced the same, even though I don't use that module.

@ danielhonrade post # 4

You are an angel. You saved me a lot of work. I think the views people should document that little piece of information in the fields pages.

Worked. Problem solved.

#6

danielhonrade/Geir19, sorry for not getting back to you sooner, I walked away from Drupal over Christmas to try to get a break from coding. :)

I spent a few minutes trying to understand where you were coming from, and I think I understand now.

I am *not* using taxonomy as an argument. I am using a content_taxonomy CCK field as an argument. There is an option to tie the CCK content_taxonomy of a field to the taxonomy of a node: When you are managing the content type's fields, there is an option to "Save values additionally to the core taxonomy system (into the 'term_node' table).". I am not using this. My argument is actually a "Content: Taxonomy Field Name XYZ (field_xyz)" rather than a "Taxonomy: Term id"

If I did attempt to use either taxonomy term or taxonomy term (with depth), no items would come up at all.

#7

Any further discussion should probably be moved into this thread, so that we're not posting in more than one place...

http://drupal.org/node/924646

nobody click here