Author image
Senior Developer

Views content cache

Views is awesome. You get a ton of flexibility and power, but that comes at a price: Some of the queries that views produces are less than optimal, and the rendering of results can take a long time. Views 2.6 introduced a nice solution to some of the issues, with the introduction of caching plugins.

Views itself comes with a single cache plugin (okay, okay two if you're really counting) that is time-based. So you can say: "I don't care if I show content that's 6 hours old" and it'll handle it fine. I've been thinking for a while that there should really be a better way, if you've got a view listing blog posts, you only really need to flush the cache on that view when a new blog post is added, or and existing one is updated or deleted. After a client really needed this, I looked into it and found some code lying around in the views issue queue written by huesforalice. I cleaned it up some and created a module, presenting:

Views content cache. Its really simple, just choose the content types you care about, and the module handles the rest!

Well, almost, trouble is, it's actually quite hard to know when a node has changed. It's easy for things on the node itself, but harder for things like comments on the node, or things like votingapi votes. If you take all of these things into account, after a while you're back to not gaining much from the caching. I expect things like this to be addressed before a stable release of the module.


Dale Jung (datacaliber on d.o) build a custom caching engine for Bonnier that was like that - everything was interrupt driven so the caches were only cleared when someone was modified that was related to it, e.g. you have a view of ten nodes, if one of those nodes was modified then the cache was invalidated and thus the view was reloaded. And there was a Panels plugin too. Good stuff. Unfortunately locked within the bowels of Bonnier's svn repository for now.

Great idea!

I had a similar idea, but then I came to think about the nice rules module. What if you could create rules for when you need to clear the cache of a specific view or a panel?

It was not possible at the time, so I took the liberty of creating my own module, cache actions. (

It provides actions for clearing the cache of the drupal cache bins, specific views, specific panel pages and specific mini panels.

Your module is a great alternative to my module, since it requires less configuration. I will recommend it to anyone who looks for a more simple solution!

Great work!

Yay! I'm glad to see someone adding new caching plugins!

Added the 2 projects to the bottom of the expires module

Let me know if there are any other cache expiration modules out there.

Glad I bumped to this page. Your post is direct and informative. will sure be reading more of your posts.

Weird. Googled my name and came across this. I'm looking to get the caching modules, among other stuff, released to the wild.

The Drupal 5 version supported views and panels. Though both of those modules were modified to support the caching.

Drupal 6 only supports panels, but since all the output ran through panels it was fine. At the time, I wanted to cache the actual views results data structure, but didn't have the necessary hooks. That might have changed.

The basic goal was that all pane caches should have permanent lifetimes and ONLY invalidate via the use of events. So logged in users would have near 100% cache coverage that was not stale.

I'm pretty sure it has complete coverage of events for most modules (nodequeue, votingapi, taxonomy, etc) as Field & Stream, Outdoorlife, and Parenting all run it in production with no stale caches afaik.

Granted it's been awhile since I've touched Drupal or those sites so who knows what's up now. Performance/caching is definitely one of those issues where one block/code change can muck up the works.

Comments on this article are now closed, if you want to give us feeback you can use our contact form instead.