cool tech graphics

How to Fix Caching for Views With Exposed Filters in Drupal 7

Filed under:

One of the better features of the views module in Drupal is the ability to cache your view's output. This can come in handy when your view is doing a lot of computation. Caching your view will save your server a lot of unneeded work. One of the big current drawbacks of this feature is if you enable caching for your view and you have an exposed filter, you'll run into the following scenario:

User A enters a value for the filter

Then User B enters a different value for that same filter

Yikes! As you can see, caching is serving up User A's result set for User B! User B just wanted to see results in North Carolina and recieved results in Oregon! This is not very helpful as-is. Thankfully, there is a handy patch to views available to you at: Let me go ahead and explain how to apply this patch so you can have nice cached views with exposed filters in Drupal 7.

UPDATE: Since I wrote this article, there has since been another patch released. Feel free to try and use later patches (#81 and higher) instead of #71. If you do this, be sure to fully test views' caching to the fullest you can before deploying this fix anywhere.

  • Fire up a terminal and navigate to your drupal directory: cd ~/Sites/my_drupal_site/drupal
  • Update the views module: with drush: drush dl views or use http://yoursite.tld/admin/modules/update )
  • Change to the views module directory: either cd sites/all/modules/views or cd sites/all/modules/contrib/views
  • Download the patch (I'm using #71 as it worked best for me at the time of this writing). wget
  • Apply the patch: patch -p1 < views-1055616-71.patch
  • Clear your caches

You should now be able to test your cached view and see different results for different values entered into your exposed filters.

User A enters a value for the filter

and then User B enters a different value for that same filter

Much better, right? Hopefully this patch will become part of the next dev release of views, and make its way into a stable release, so this functionality will work out of the box. Happy Drupaling!

Date posted: February 14, 2013


If you have a views with an exposed filter but without any preloaded default content, is there any point to use the Views' caching feature? U only use it to load the default results, right? Or does it also speed up dynamic results in some way?

This will apply caching to the results, even on non-default results. It just caches the results per each value used in the exposed filter. For a generic search form this might not make a lot of sense. However, for exposed filters where many users might be entering the same exact values (say just the postal code for a store locator), this can help increase performance.

Thanks, I've been trying to find out why my date span filters were working fine in preview mode but completely useless in browser tests though I'd disabled views caching and drupal caching for development. The latest patch saved me - thanks much for pointing it out here!

Better solution views_custom_cache .

Hi Chris,

Many thanks for the very informative post.
I have two questions to ask you if you have any time to respond I would greatly appreciate it.

1. I've tried to test your above scenario by caching my Better Exposed Filters Views the nornal way (without the patch) and using Incognito, I requested two different sets of filter results for the same View. In my case, I received the correct results for both users. Is this because the problem may have been fixed now given it's been more than two years since this post or am I doing something wrong.

2. How does performance compare against "content-based" caching through the content views cache module and time-based through the recommended patch? Which one would you choose and why?

Many thanks in advance

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Metal Toad is an Advanced AWS Consulting Partner. Learn more about our AWS Managed Services

Have questions?