After updating to Drupal 7.12, a few views utilizing the taxonomy with depth contextual filter started failing. After digging in a bit, I've tracked the issue to views query/output cache. Disabling views' caching fixes the issue. I then went on to attempt to reproduce the issue in a simplistic form.

With just core 7.12, views and ctools, create a few terms in a hierarchy. The export for my view is attached, however it's pretty simple: just a node field view (title field only) and a taxonomy term ID (with depth) contextual filter which receives its default from the taxonomy term id from url. I created a block display and placed the block.

If you now create a few nodes, you'll notice the view works as expected, however, all it takes to reproduce the issue is to turn on Time-based caching. The view preview continues to work as expected however no results come through to the block.

Files: 
CommentFileSizeAuthor
#39 views-query_plugin_copy_instead_of_cloning-1430650.patch612 bytesArnaud Meunier
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]
#32 views-has-tax-term-id-w-depth.jpg389.69 KBAHOY
termdepthview.txt5.21 KBultimateboy

Comments

Some observations: All stands and falls with views_plugin_cache::get_results_key and it's way to get the sql query string.

The problem is currently that somehow the palceholders get's mixed up. We had this issue before http://drupal.org/node/1112854

I haven't updated to Drupal 7.12 yet, still have 7.1, and this problem appeared for me yesterday, although I hadn't found the exact reason until I saw this.

I had a couple of views with taxonomi with depth contextual filter added, and those stopped working when I updated to Views 7.x-3.1 (yesterday).
Tried to change one of my views to just use taxonomi (without depth), and it worked again. So perhaps it's views 7.x-3.1, and not the core upgrade?

I believe this is related to the issue I was posting in. Initially I thought it was a 7.10 -> 7.12 problem but I also did the 3.0 -> 3.1 upgrade the same night.

I have a View that pulls out a Node Title, Node Body, and the attached Taxonomy Term Image that stopped working. After I recreated it, it seemed to be working but overnight it stopped working. Obviously anything that worked at one time and then stopped working 8 hours later made me suspect caching.

My issue is posted in adding related taxonomy term to fields when using "Has taxonomy term ID (with depth)" filter leads to empty result

Update: Disabling Views Caching using the Advanced Settings did not seem to fix the problem for me :(

2nd Update: I am using i18n and have the View set to display only the current language or no language.

Mine stopped working too. It worked after I removed the Taxonomi ID with depth, and now it doesn't.

Will try to take a look at the other issue.
Looks like I'll have to patch something though, and I have never done that the right way - only by hand so far, manually editing code from what I have seen in a patch. Will go search for a place to learn something about patching, since this is driving me crazy ;)

Thank you for posting the link, dereine.

Disabling i18n's Multilingual Select module fixed my problem. I'm not sure if it's actually related to this problem though.

@dereine > Added the patch manually today, and it didn't help. Have emptied the site cache.

After reading Kevin's post above, I removed the language filter on one of my 2 views that wasn't working, and that helped me too.

UPDATE: Well, I spoke too fast. Again.
One worked, and all was fine. I then removed language filter on the other, and then that one worked.
I have just checked back on the first one, and it doesn't work anymore.

So, did some more testing. It seems only one of them can work at any given time (and the other days, they have stopped working all together after a while).
I'm so confused.

They both worked before my update to Views 3.1.
But then again, I have updated other modules too, so.. argh.

Did you try disabling the Multilingual Select module? I too had the problem where I thought I fixed it and then overnight it stopped working again. Seems like a combination of problems, one of them being caching.

No, I haven't tried that, since I need the multilingual select module :-S

Hmm.. I rolled back the files from i18n 1.4 to 1.3, but didn't update my database again ( http://drupal.org/node/1430708#comment-5568756 )
So, would it still be the same?

Oh, what a mess. I'm in way over my head on this -__-

You don't have to roll the whole i18n module back. There are just 4 oder 5 lines of codes, which have to be removed (or commented out).

Just look into the directory "i18n_select" for a file named "i18n_select.module" and open it in a text editor. Then search for this code part (should begin at about line 153):

  // Rewrite pager for taxonomy term pages.
  if ($mode && ($table_alias = i18n_select_check_table($query, 'taxonomy_index', 'tid')) && i18n_select_check_query($query, $table_alias)) {
    $query->join('node', 'n', 't.nid = n.nid');
    $query->condition('n.language', i18n_select_langcodes());
    // Mark query as altered
    $query->addTag('i18n_select');
}

Simply remove all of these lines or wrap it in a comment. That's all you need to do

I had another problem with the module, so I rolled back the files right after I had updated, since I couldn't access any adminpages.
Could I update only the i18n_select module to 1.4, and then change those lines as suggested, you think?

Haha.. this is just one big complicated mess :D
Thank you so much for your help already, agoradesign. Much appreciated.

Uiiiiiii that really sounds very complicated....

No, that wouldn't help you. Because I've compared the i18n select versions 1.3 and 1.4. The only change in between was the addition of the code that destroyed the view with taxonomy depth filter. So v 1.3 should be ok.

So when your problem still exists with 1.3, I fear that the root of the problem is a different one, although the problem description sounded similar...

Hmm.. Well, since my problem is not urgent as such, I think I'll wait for the next versions of the involved modules to come out.
I'm not working on a production site with this, and we plan to launch in the fall, so I have time. It's more annoying details, than a real problem for the time being.

I have a more tech savvy friend who's coming over to help out with the site later this month. Maybe he can spot the problem better than me. I'm not too good at debugging, if it's complicated - and this IS complicated, it seems ;) So until then, I think I'll just let it be, and work on other parts of the sites. I would like this problem to be solved of course, so I could finish what I was doing, and check it of my long list, but hey - you can't always get what you want.

I'm really glad that you took the time to look into this, and I think you're on the right track.
I assume, that a new stable version of i18n will come at some point, since 1.4 has a bug, so I'll try to update that again as the first thing, when that happens, and see if I can go from there :)

One more hint for you or your friend: in my case the count query of the view threw an exception. So maybe you should start debugging in hanging into the execute() method of the file views\plugins\views_plugin_query_default.inc, where the "execute_count_query()" is called.. This is currently found at line 1381.

I needed quite a lot of time to find this out...

I wish you good luck with your site!

Thank you once again. Very kind of you :)

I have the same issue.
When I turn on caching at a View with taxonomies and Has taxonomy term ID (with depth)" filter, I have empty results.

After almost 2 months, with the latest dev versions of views and date, there is still this problem.
I don't have multilingual select activated, just Internationalization, Multilingual content.
Any solution?

Are these the same?
http://drupal.org/node/1430396#comment-5603914
http://drupal.org/node/1430650
http://drupal.org/node/1430396#comment-5603914
http://drupal.org/node/823264 (d6)

Should we escalate this to major?

I've the same issue as #18, no multilingual content. Happy to test a patch against 7.3.3 if one is available.

I have the same issue as #18. Turning of cache shows the content but would obviously be nice to get the caching fixed.

Is this perhaps a special case (duplicate) of #1055616: Query arguments should be replaced before generating cache ID ?

Sign me up for having this problem also. I don't have any Multilingual modules or anything. Views caching works for every other View that doesn't have a Contextual Filter.

Turning on any caching options gives me a page with just the title and then the pager - what's weird, and not sure if this is some sort of clue, but the pager links (the numbers, next, etc) AREN'T for the same taxonomy term.

In other words, the page title will be in sync with the URL. If I go to mysite.com/taxonomy/term/123, the page title will be for the correct title of term 123. The pager, however, will not. It will take me to a completely different taxonomy term page (also blank). I tried to find some sort of pattern - but my coffee hasn't kicked in yet.

Would a live example of this problem help? I have a sandbox version of my site I can open up for a bit.

I'm experiencing this issue as well...
Drupal 7.14
Views 7.x-3.3

Having a taxonomy term filter results in empty output when caching is turned on

Assigned:Unassigned» Jawi
Priority:Normal» Critical

same issue here! When using taxonomie terms with depth caching doesn't work.

Views that we have without caching on have a very pur performance. It is from major importance for us to get our website run with a normal user experience as soon as possible!!

Any sugestions to handle this problem?

If you find the time you should try the patch of #1055616: Query arguments should be replaced before generating cache ID (scroll to comment #65 at the bottom). And please report back.

If that doesn't help: did you try modifying the cache settings of the views? Turning of output caching and using query result caching only served me well for #1055616. It was a good intermediate solution while waiting for the fix.

Thanks allot!

Will check this tomorrow on a dev install

Status:Active» Closed (fixed)

Seeing that this issue dates back very old, I believe that these problems have been addressed, see After upgrade to 3.5 only Views with caching set to 'None' work, and because Jawi has not reported back recently, I believe this issue is already being handled elsewhere by the dev programmers.

Ok, but why close both this issue and the one you refer to?

Status:Closed (fixed)» Active

Issue has a bunch of followers. They should asses, if it's fixed. The issue mentioned at #27 is quite different and is still not solved.

Thanks for the input, giorgio79, on the issue mentioned in #27, After upgrade to 3.5 only views with caching set to 'None' work - Time based caching gives "Page not found" errors.

I had the problem myself in Views 7.x-3.4 but it was completely resolved upon upgrade to 3.5, as it was for the majority of people. My guess is that those who still have caching problems may be experiencing interference with specific Views configurations (such as filters or arguments used) or with other modules that not all Views users have installed. I've updated that issue with several other reference links that may be of help to you and the others looking for a solution.

with latest dev module the problem is still their.
7.x-3.x-dev tar.gz (1.56 MB) | zip (1.79 MB) 2012-Sep-27

This is development and not version 3.5

Let's try that one instead

StatusFileSize
new389.69 KB

I came across this problem in my first attempt at using Has taxonomy term ID (with depth). After coming across this post I disabled caching and that resolved my problem. I'm running Views 7.x-3.5.

In an attempt to troubleshoot the cause, I tried setting up a very basic view with Content: title as the only field, no filter criteria, no sort criteria, and all other options set to the defaults for content (see attached JPG for screenshot), added the Has taxonomy term ID (with depth) to contextual filters, enabled caching and everything works fine. If I add Content: Published (Yes) for the filter criteria to the view or create another display instance with Content: Published (Yes) the view returns no results. Flushing Drupal's cache doesn't fix the results. If I turn off the view's caching, the view (with Content: Published (Yes) for filter criteria) returns results again. The problem is not specific to the Content: Published (Yes) filter criteria. The problem can be replicated with other filter criteria, e.g. Content: type, but not all filter criteria. I was able to add several other various filter criteria to the view and the view continued to show results with caching enabled.

In all tests, the view's Preview with contextual filters displayed results. The problem exists only in the page or block display and only with caching enabled.

I admittedly have other modules installed so I don't know where the problem lies. I will see if I can get a fresh install of Drupal 7 and try another test but I thought I'd share my first experience using Has taxonomy term ID (with depth).

Priority:Critical» Major

This totally does not meet the definition of critical.

The perfmance of views can be VERY POOR when caching of large and rich views pages can't be done. So your wright that it is not critical in a tecnical way, but having a website that runs terrible slow and used to much server memory can't be a good thing. For allot of users this is a issue with HIGH URGENT!!

@Jawi, did you give #25 a try?

I'm also experiencing this issue using Views 3.5 (but also with the current dev) and Drupal 7.17. I have a view displaying a list of nodes and as soon as I turn on time-based caching, the view returns no results. If I remove the taxonomy with depth filter, the cached view returns results. I'm currently investigating and will post a patch if I find the problem.

edit: also, #25 did not help.

For some reason, the :db_condition_placeholder variables are not being properly set when caching is turned ON. Here is an example of an SQL request generated by a very simple view overwriting the Taxonomy Term path:

SELECT node.created AS node_created, node.nid AS nid
FROM
node node
WHERE (( (node.nid IN (SELECT tn.nid AS nid
FROM
taxonomy_index tn
WHERE ( (tn.tid = :db_condition_placeholder_0_0) ))) )AND(( (node.status = :db_condition_placeholder_0_0) )))
ORDER BY node_created DESC

See how "db_condition_placeholder_0_0" is used both for the "tn.tid" and the "node.status" WHERE comparison? It shouldn't be the case, and this query will not generate any result. If you're experiencing this issue, take a look on the actual SQL query generated by your View, and I bet you'll observe a similar thing. Some experiments that might help figure out the root of this issue:

1) Try to play with grouping if you're using a Taxonomy filter: In "views_handler_argument_term_node_tid_depth.inc" file @ line 134, change the group for "1" instead of "0".

2) Try to play with QueryConditionInterface::compile() (Drupal Core database abstraction - query.inc @ line 1794) around the compile recursive call (adding $queryPlaceholder->nextPlaceholder() right after the call).

Both those hacks fixed this simple view. But none of them is addressing the root of this issue. It would be nice if someone more familiar with Views / Drupal Core DB abstraction could give us a hint.

Quick update after a bit more investigation: Views' Result cache seems to be the cause of this "db_condition_placeholder" problem mentioned above.

On our website, we're only using Rendered Output caching (setting Query Results Caching to "Never cache" for all our views). So we hardcoded $cache = FALSE in the view's query execution function (views.inc file @ line 1143, right after the check for already-cached results block). BTW - The code should properly handle the case where caching is enabled AND Results Caching is disabled.

Adding this line will fix this issue with Rendered Output Caching. If for some reason you cannot use Rendered Output Caching and need to go for Results Caching instead, this will be useless (pretty much the same effect as disabling cache from the UI).

Status:Active» Needs review
StatusFileSize
new612 bytes
PASSED: [[SimpleTest]]: [MySQL] 1,603 pass(es).
[ View ]

We ended up needing Result Caching, and discovered that assigning by reference $query_plugin rather than cloning it (in get_results_key function) fixed our issue (db placeholders get correctly generated). Not sure what's the reasoning behind creating a new instance of $build_info, but hopefully someone familiar with views could help here?

Tested #39 in #1055616-84: Query arguments should be replaced before generating cache ID, and it makes the last bit of that puzzle.
Is this issue perhaps a special case (duplicate) of #1055616 ?

Patch of #39 tested and working great on our production website Internet Agency

Thanks for al the good work. This realy give us a huge performance boost!!

#39 works for me

I confirm that #39 works for me too, It let's me use cache with views and contextual filters with taxonomy term ID with depth. Using Drupal 7.19 and Views 3.5

Thank you, Arnaud! #39 fixed this for me too. Not sure how anyone could think this wasn't critical -- I went from a perfectly functional site to a having either empty section fronts (because cached views returned no results) or 90-100% CPU utilization on an Amazon large instance. With this patch, I was able to turn caching back on, so performance is back to normal and the section fronts have content as they should. Using Views 3.5 and Drupal 7.20.

Agreed, Ken. This nearly crippled our site as well. Now time-based caching is working, though we still can't get Content-based caching to work. I'll take what I can at this point.

Just chiming in to say the patch in #39 fixes views caching for views with exposed filters, and for views using taxonomy term ID with depth for me, in Drupal 7.19 and Views 3.5. Thanks!

Thank you Arnaud Meunier #39
It's work for me