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!
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 924646-argument-fix.patch | 2.18 KB | dawehner |
Comments
Comment #1
trevorbradley commented(fixed version)
Comment #2
trevorbradley commentedOK, I've been digging into this one for hours today, and it's far too easy to get caught in the web of code that is views and cck. Here's what I've managed to figure out:
I believe what's happening is that Content Taxonomy's attempt to set the handler to content_taxonomy_handler_filter_many_to_one isn't sticking. When I look at $this->argument with dpm in the build function of view.inc, it claims that the content handler is content_handler_argument_numeric. However if I do a similar test with a view based on numbers instead of content taxonomy (allowing multiple values), it claims the content handler is content_handler_argument_many_to_one.
I notice that the module makes reference to content_taxonomy_handler_filter_many_to_one but not to content_taxonomy_handler_argument_many_to_one... could this be the missing element? I've tried hacking it in alongside the filter and unfortunately it doesn't appear to be doing anything. :(
I feel quite close on this one, any guidance or assistance would be much appreciated!
Comment #3
1kenthomas commentedHmm. It may be that there is an issue with the correct handler; I'm not that familiar with this corner to know.
Historically, views has encountered issues with generating correct JOINs to produce expected results when attempting multiple terms per argument.
One response is to look at the actual, generated SQL code to see what it's doing.
Another is to just write your own queries (take the url, turn it to what you need, db_query ("SELECT..."), etc) and stuff into something like PHP field, if it works.
Good luck!
Comment #4
trevorbradley commentedThe SQL for AND and OR are both identical.. both look like the OR clause.
Here is the SQL for an AND argument in the Content Taxonomy View: 129,131
And here is the SQL for an OR argument in the Content Taxonomy View: 129+131:
By my eye that's identical.
However, if I create another view, this time restricting by a CCK numeric field, the SQL is obviously different.
Here is the SQL for an AND argument in the CCK Numeric View: 10,20
And here is the SQL for the OR argument in the CCK numeric view: 10+20:
As you can see, for content taxonomy everything behaves like an OR (10+20) rather than an and (10,20)... although it uses LEFT JOINs instead of INNER JOINs.. I can't seem to pin down where this is happening.
Somehow this clause in the SQL:
Needs to become:
... and I can verify this does in fact only return the correct results.
Are there good examples for overwriting the where condition in the SQL query? I'm about ready to do this and give up on doing it properly... It just feels like I'm so damned close to figuring it out and breaking through to a new undestanding of views.
EDIT: code tags, clarification on where each of the four queries are generated.
Comment #5
trevorbradley commentedAnother is to just write your own queries (take the url, turn it to what you need, db_query ("SELECT..."), etc) and stuff into something like PHP field, if it works.
Just to verify, you're actually advocating bypassing views all together and just creating a standard PHP page that renders data? I feel a bit sad that views might not be up for the task, but I will have to resort to that if it doesn't work.
Comment #6
dawehnerHere is a first patch file
Comment #7
trevorbradley commentedI've been working with dereine on IRC for about an hour on this one, and can confirm it does in fact work. Thank you so much dereine!
I feel good that I was about 80% of the way there to understanding this problem. Hopefully I'll be able to tackle tough ones like this in the future on my own.
Comment #8
W.M. commentedPlease have a look at my respond here:
http://drupal.org/node/924648#comment-3844962
It can be not a Content Taxonomy module issue at all.
Views core should be documented even better. Note: I have advanced help module turned off.
Comment #9
esmerel commented@8 Then you should turn advanced help on. That *is* how you get to the core documentation. Also, if you think the documentation needs to be better, perhaps you could submit documentation patches.
Comment #10
merlinofchaos commented@geir19: When you make assertions like that, you need to provide evidence, because you are saying something directly opposite of what the experts are saying. Particularly because there's a patch file that is working. So far as I can tell, you're pulling opinions out of thin air and then telling the people who actually know the code you're right. That means we will more or less ignore what you have to say until this changes.
Comment #11
chuckbar77 commentedsubscribing
Comment #12
ianchan commentedsubscribing
Comment #13
trevorbradley commentedI think I understand Geir19's frustration/confusion. We're actually talking about two different things:
http://drupal.org/node/924648#comment-3912034
Just for the record, I am *not* attempting to use "Taxonomy: Term ID" or "Taxonomy: Term ID (with depth)" as an argument. Rather I am using a content_taxonomy CCK field "Content: Field name (field_xyz)". There is an option under Content Types > Manage Fields that allow you to tie changes in the CCK field to the taxonomy of the node. I am not using this, and have it turned off.
Comment #14
YK85 commentedsubscribing