1

Part of our go live process is to put caching in place for the site. It is a great feature. But I am unsure on the best strategy, not from a technical perspective but from a non-technical cms editor perspective...

For example, we usually setup the cache on the header and footer includes on our templates. I like to set it up for 1 hour, that way it will clear reasonably often. That way if the editor changes some header or footer markup they just need to wait an hour for the new content to appear. Which brings me to the issue, our cms editors find this all a bit confusing, they are never sure what will be cached and what won't, if you show them how to clear the cache they end up doing it almost every edit just to be sure. Or they make edits and when it doesn't look they way they want they think it must be the cache and leave it looking odd for days before they admit something must be wrong.

So how do other people deal with this? I am thinking we might write a plugin to clear the entire cache on any entry save or structure modification. But this seems a bit crude.

2
  • 1
    Are you using the {% cache %} tag or are you cacheing from a plugin? The cache tag should automatically clear and re-save when whatever entry they are cacheing for is updated, assuming you have your configs set up correctly. Commented Jun 23, 2015 at 1:24
  • yes using the cache tag so something like {% cache for 1 hour if craft.config.siteCached %} where siteCached is a var. I understand the cache clears when a page is edited. But some things don't quite work that way, for example if the a new page is added to the top navigation, or the home page lists the latest 3 news items and a new news item is added. Or global header or footer values are changed. Commented Jun 24, 2015 at 2:30

1 Answer 1

3

I am by no means a caching expert, but here's what I do know...

When you wrap a chunk of Twig code in a cache tag, it processes that chunk of code all the way down to HTML, then stores that HTML in the database. A cache key references this pre-parsed HTML code, so it can be easily called up later.

But in addition to the HTML itself, two other pieces of data are stored alongside it:

  • A list of criteria used to generate the HTML
  • A list of elements used to generate the HTML

The main reason that criteria and elements are also recorded is for the purpose of cache invalidation... So for example, if someone were to change an element associated with a cached chunk, that chunk would immediately become invalidated. You wouldn't need to write a separate plugin in that case, the cache would be invalidated simply by updating a corresponding element. Something similar happens to criteria, if the criteria results would have changed.

Check out this question which I asked awhile ago... It goes into greater depth about the related caching tables, and how they work together to make sure your cache stays fresh.

Also, make sure you've reviewed the official recommendations about the proper usage of cache tags, to figure out the best times to use (and not to use) the tag.

Lastly, I'd recommend taking the time to watch this excellent video from Barrel Strength Design about the wonders of the cache tag. There is a lot to be learned from that video, and it's a great way to get your bearings on caching in general.

1
  • I've seen the recommendations, but haven't watched the video, I'll check it out, thx! Commented Jun 24, 2015 at 2:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.