Hi,
I'm having a strange problem with a view, which is obviously caused by a bug. I'm trying to set up a block where I show a list of nodes grouped by its taxonomy term and the term's parent, filtered by the page context (has taxonomy term ID with depth). I created the view step by step and it worked very well until the point where I add the name of the term's parent to the fields. As soon as I add any field coming from the node's relationship with the taxonomy, I get an empty result. I didn't change any filter criteria. So technically it should only affect the SELECT part of the sql query.

An interesting thing is, that I see the correct result in the preview of my view. So there must be a difference between the sql query that is done in the preview mode and the one that is used in "live" mode.

description of my view

I'm showing some fields (title, category - which is a Taxonomy field - and the taxonomy term name derived from the parent relationship, which breaks my view)

The view is filtered by type, status and language.

The view is sorted by the weight of its related parent term, the weight of its related term, an own weight field and its title

I'm using a "has taxnomy term ID (with depth)" page argument.

And I'm using two relationships: first the "taxonomy terms on node" on a specific vocabulary and second a "parent term" relation based on the first relationship.

Narrowing down the problem

I played around a bit and could narrow down the problem to the "Has taxonomy term ID (with depth)" filter. When I use the normal "Has taxonomy term ID" filter, I always get the correct result. As soon as I use the filter with depth - no matter if I use it as a page argument or as static filter - I get an empty result, as soon as I use a taxonomy-related field as described above.

debugging / quick workaround help wanted

In order to be able to make a quick workaround (need it tomorrow urgently!) and also to provide better information here on the bug, it would help me very much, if I could see the generated SQL by the view. I haven't found the right way to get this, when I have the views_plugin_query_default object. Then I could compare this SQL query with the one from the live preview and identify the wrong part. This info would certainly help here in fixing the problem and also me in implementing a quick & dirty hook_views_query_alter().

Many thanks in advance,
Andi

Comments

ultimateboy’s picture

I'm having a similar issue which just started happening after the 7.10->7.12 update. agoradesign, can you confirm you are on 7.12?

agoradesign’s picture

Yes, that's true. I'm on 7.12

Kevin Morse’s picture

Also having a similar problem. Unfortunately I can't confirm whether it was with 7.10 -> 7.12 or Views 3.0 -> 3.1

I have the following Views setup

FIELDS
(term) Sports Icon
News Title
News Text

RELATIONSHIPS
Content: Taxonomy terms on node

This produces a View that shows a bunch of news items with an icon of the news category (basketball, football, etc.) beside it. I still see the View working fine in Auto preview mode in Views UI but on the front page it is now blank!

Removing the (term) Sports Icon causes the view show up again.

dawehner’s picture

In general there might be multiple problems involved here, please test #1427084: $options['group'] defaulted to 1 instead of 0 in views_handler_filter.inc first as this fixes one of the problems

Kevin Morse’s picture

I went in and manually changed this back to 0 with no effect.

I'm attempting to reproduce this on a clean install.

UPDATE: Unable to produce this with a clean install. I went back and recreated the View in as simple of a form as possible and now have the new version working fine.

UPDATE 2: I synchronized the two Views as best as as I could and will include the relevant differences between working and non working below.

$view->name (obviously)
$view->human_name (obviously)

$view->core = 7; (working) 0; (not working)

$handler->display->display_options['fields']['title']['alter']['word_boundary'] = 0; (working) 1; (not working)
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = 0; (working) 1; (not working)

$handler->display->display_options['filters']['language']['group'] = '1'; (working) 1; (not working)

$handler->display->display_options['path'] (obviously)

Looking like it's either the core or the language filter as the ellipsis and word_boundary doesn't seem to be in use anymore.

agoradesign’s picture

Ok, I will try this as soon as I can. As I also have another problem with getting a specific taxonomy view to work, I'm currently doing some ugly hacking in order to get everything up & working within the next few hours for our customer. After this, I can replicate the Drupal installation and try this patch

Kevin Morse’s picture

Over night my working View stopped working. I'm thinking its a caching issue.

Is anyone else running i18n? I suspected that last night due to the difference in code between my working View and my not working View but now that they both don't work I suspect its something due to caching. (In the preview they still work)

Update:
Just looking and I found this issue Taxonomy filter with depth, Drupal 7.12, and views query caching failure I'm going to say these are one and the same. Views that use taxonomy do not cache properly in 3.1.

agoradesign’s picture

I'm also running i18n. So far I didn't have the problem that a working view stopped working.

My problem is/was exactly like the one of soelver in the other issue post (http://drupal.org/node/1430650#comment-5568640).

I haven't tried out the patch as supposed by dereine. I regret that I can't contribute more to this topic at the moment. I did a quick & dirty workaround for my problem yesterday and I'm currently working on a different project under a bit of time pressure. So I'm not sure when I have the time to replicate the mentioned Drupal project into a sandbox and reset the view to its problem state and try the patch(es) :((

torsti’s picture

If you have "Multilingual select" -module (Internationalization) activated, disable it. This solved my problems :-)

Kevin Morse’s picture

torsti: I will try that tonight when the site traffic dies down.

I'm kind of hesitant to blame i18n as the problem still happens when I remove the Content translation: Language filter but it's worth a try. It is definitely suspicious that we're both running i18n. Unfortunately I don't have much time to spend on this either. My news feed works it just sucks there are no pictures :(

Kevin Morse’s picture

Confirmed!

Disabling i18n's Multilingual Select module fixes the problem. Now I just need to know where I should report this.

agoradesign’s picture

Now that I'm back working on the affected project, I can confirm that disabling the i18n Multilingual Select module fixes the problem. Unfortunately I need that module....

I will open an issue in the i18n issue tracker - if there isn't one by now. Should we close this here?

agoradesign’s picture

I have good news :)

After heavy debugging I found out that Views query still was right after manipulation from i18n Select. The problem was in the count query of the view, which caused a PDOException because i18n Select added an unnecessary INNER JOIN on the non-existing 'tid' column of the node table.

This discovery led me to an existing bug report, resulting from a combination of Forum module and i18n Select. They already found the root of the problem: http://drupal.org/node/1437932#comment-5597160

So this here is the evil code, that was introduced to i18n 1.4 and that also introduced this bug:
http://drupalcode.org/project/i18n.git/blobdiff/48d157f376d3bcc0e8d0bcb9...

dawehner’s picture

Kevin Morse’s picture

Sounds like quite a mess.

Thankfully I don't believe I really need the Multilingual Select module so this doesn't effect me. Just for curiosities sake, what exactly does that module do? I didn't notice any change when I turned it off.

robertstaddon’s picture

Thank you so much for reporting this. Disabling Multilingual Select solved the problem for me as well. I hope they can get that module patched soon!

FreekyMage’s picture

Thanks for this, I had a similar problem and it was idd solved by disabling the multilingual select.