Is the stash refresh variable the only means of breaking a cached set?

Question

I'm trying to get into some more advanced use of Stash and I'm wondering about cache breaking. With some of the dedicated cache add-ons, you can set rules around cache breaking that are not simply time based - you can set a given cache to break when a new entry is added, for example - which is awfully handy.

My question is this - is Stash suitable for caching dynamic content on a basis other than time? My fear is that time would be a challenge for a site with certain channels being updated at much higher intervals than in others. The last thing i want to do is create a situation in which a client is confused by a recent entry not appearing in the site because the last page visit that was cached was only minutes before the most recent update was made and therefore the remaining time in the cache must expire before it breaks and is re-set and cached anew with a visit to the site. Just curious what the strategies are in using stash (or not) with caching.

Answer 1

You can use the {exp:stash:destroy} {or it's alias {exp:stash:unset}) to unset a cached variable or variables within an entire scope (user or site): https://github.com/croxton/Stash/tree/dev#expstashunset-requires-php-523-or-expstashdestroy

Here's an example of use to clear cached comments when a new comment is submitted: https://gist.github.com/3973821

You may be able to find creative used of this tag to facilitate automatic cache clearing; for example, using the {edit_date} variable as part of a variable name or context.

The tag is also available programmatically as Stash::destroy($params} where $params is an array of key=>value pairs representing tag parameters. You can use this in a custom extension to clear cached variables on new entry submission or entry edit. I don't have an example to hand but I know some members of the EE community have already created extensions like this. Perhaps they could share the code below?

Finally, I'm in the early stages of writing a control panel module to manage automatic cache busting rules, which will also include an interface for manual cache clearing.

Answer 2

As you say, automatic cache breaking is very nice, and IMHO a must, since anything else is bound to impact the user experience for the editors. My goto caching addon since its release has been CE Cache, which solves this nicely.

For my 4–5 latest projects I've used the Template Partials approach (with Stash) increasingly. I love this way to develop in ExpressionEngine, but my main gripe is with caching. I feel that using Stash's own caching, and then having to code the breaking logic into the templates somehow, is way to fragile and hacky. Might work for smaller projects with few content types/variables, but not on more complex stuff.

So, I've continued to use CE Cache, with varying success. The problem is that you, naturally, have to cache the "controller"-part of your templates, together with your "view"-part, which, if you keep things DRY, means that you most of the time has to cache the whole page or nothing. This kinda defeats the whole point of CE Cache, which excels at caching more specific chunks of a page (or at least, that's where it excels in my opinion). The result is that you either have to break the cache more often (for all channels shown in a page, low variables, etc.), or you have to skip automatic cache breaking for some or all types of content (and leave it to the editor to do it manually). Neither is ideal.

On my latest project where I kept things very DRY, and the pages generally contained content from a lot of different channels, I'm left with the feeling that using the templates partials approach actually had a negative impact on the overall performance. But this is very project-specific, in many cases where you have simpler content, caching the whole page is perfectly OK.

I'm still trying to figure out what the optimal approach would have been, but I have a feeling that taking a step back and dividing the page into more (than one) native embeds, and thereby being able to cache separate parts of the page with CE Cache, would have been better. Not so pretty, but this is ExpressionEngine after all and sometimes it pays to work with the system instead of against it. Also, a parsed and cached embed isn't a performance issue.

Just my two cents.

Answer 3

Although Stash doesn't currently have automated cache breaking you can use the {exp:stash:unset} tag (docs) to flush caches when certain actions occur. For an example of this in use take a look at the top of Mark Croxton's sample viewModel template, where it's used to clear out cached comment data when a new comment is submitted.

The Stash::destroy method is also available statically, which means that creating custom cache-breaking extensions is fairly simple. I recently put together a very basic extension which flushes out all globally scoped caches whenever an entry or Low variable is updated. I was considering fleshing it out a bit more and releasing it 'properly' at some point, but if you'd like to see some sample code I've uploaded a gist to Github. I'm pretty sure it will only be compatible with the dev branch at the moment.

You should be able to implement additional triggers for cache breaking by inserting extra hook names into the $hooks array (so long as the hooks don't require a return value).

Although it is possible to create all sorts of complex site-specific cache breaking rules via some fairly simple extensions it doesn't change the fact that addons like CE Cache are far more powerful, with cache refreshing and support for multiple drivers built-in. On a high traffic site those features are likely to be essential, but on low-medium traffic sites, particularly those where content is updated infrequently, I'm increasingly finding that Stash is all that's needed.

[I started writing this before Mark submitted his answer. There's quite a bit of overlap but I've written it now, so here goes anyway...]