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.


dawehner’s picture

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

soelver’s picture

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?

dawehner’s picture

Kevin Morse’s picture

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.

soelver’s picture

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.

Kevin Morse’s picture

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

soelver’s picture

@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.

Kevin Morse’s picture

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.

soelver’s picture

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

agoradesign’s picture

soelver’s picture

Hmm.. I rolled back the files from i18n 1.4 to 1.3, but didn't update my database again ( )
So, would it still be the same?

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

agoradesign’s picture

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

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

soelver’s picture

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.

agoradesign’s picture

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...

soelver’s picture

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 :)

agoradesign’s picture

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\, 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!

soelver’s picture

Thank you once again. Very kind of you :)

dropbydrop’s picture

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? (d6)

Should we escalate this to major?

mototribe’s picture

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

skruf’s picture

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

johnv’s picture

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

velcrobots’s picture

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, 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.

Chaulky’s picture

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

Jawi’s picture

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?

Shnapoo’s picture

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.

Jawi’s picture

Thanks allot!

Will check this tomorrow on a dev install

couturier’s picture

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.

giorgio79’s picture

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

Shnapoo’s picture

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.

couturier’s picture

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.

Jawi’s picture

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

Christian DeLoach’s picture

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).

merlinofchaos’s picture

Priority: Critical » Major

This totally does not meet the definition of critical.

Jawi’s picture

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!!

Shnapoo’s picture

@Jawi, did you give #25 a try?

cdoyle’s picture

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.

Arnaud Meunier’s picture

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
node node
WHERE (( (node.nid IN (SELECT tn.nid AS nid
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 "" file @ line 134, change the group for "1" instead of "0".

2) Try to play with QueryConditionInterface::compile() (Drupal Core database abstraction - @ 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.

Arnaud Meunier’s picture

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 ( 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).

Arnaud Meunier’s picture

Status: Active » Needs review
612 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?

johnv’s picture

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 ?

Jawi’s picture

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!!

mstef’s picture

#39 works for me

icampana’s picture

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

Ken Ficara’s picture

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.

velcrobots’s picture

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.

kpander’s picture

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!

eliasbrat’s picture

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

Deraynger’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
lmeurs’s picture

Great catch, thanks for the patch!

Since we still do not know why the placeholder ID's differed, they could also differ in other situations. Couldn't we play safer by actually substituting arguments into the query before creating the hash?

Right now both the unprocessed query and the arguments array are stored in $key_data. Since this array is only used by this function to create a hash key, there is no need to keep the old structure intact.

$key_data['build_info'][$index] = array(
  'sql' => (string) $query,
  'arguments' => $query->getArguments(),

could become:

// Turn SQL query into a string with substituted placeholders.
$connection = Database::getConnection();
$sql = (string) $query;
$quoted = (array) $query->getArguments();

foreach ($quoted as $key => $val) {
  if (is_array($val)) {
    $quoted[$key] = implode(', ', array_map(array($connection, 'quote'), $val));
  else {
    $quoted[$key] = $connection->quote($val);

$key_data['build_info'][$index] = strtr($sql, $quoted);

EDIT: It appeared that placeholder arrays can can contain arrays as values, so I had to alter the generation of the SQL query using code from views_ui_preview(). Compared to the current version of get_cache_key() it only costs 7.6055526733398E-5 seconds extra on my local W7 workstation for a query with three placeholders.

lmeurs’s picture

Ah... Views maintainer dawehner tells about the importance of cloning the query object opposed to the method used by this patch at #1055616-150: Query arguments should be replaced before generating cache ID, so it seems not likely for this issue's patch to get committed. I think it is safe to set the status of this issue to Needs work.

I shared my proposal from previous comment at #1055616-170: Query arguments should be replaced before generating cache ID as well.

lmeurs’s picture

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

Patch attached.

berndlosert’s picture

At work, I discovered the same problem that this issue addresses and came up with essentially the same patch that Imeurs made in comment #52. I then discovered this issue and decided to Imeurs patch instead. We have been using Imeurs patch on our live site for over two months now without problems.