<p><strong>The <a href="https://craftcms.com/classreference/services/TemplateCacheService" rel="nofollow"><em>TemplateCacheService</em></a> provides a ton of helpful methods to take care of this for you.</strong></p>

<p>While you <em>can</em> explicitly tell Craft to invalidate certain caches (by element ID, etc.) if you need to, I prefer to use <a href="https://craftcms.com/classreference/services/TemplateCacheService#includeCriteriaInTemplateCaches-detail" rel="nofollow"><code>includeCriteriaInTemplateCaches()</code></a> and <a href="https://craftcms.com/classreference/services/TemplateCacheService#includeElementInTemplateCaches-detail" rel="nofollow"><code>includeElementInTemplateCaches()</code></a> to <em>register</em> the appropriate element(s)/criteria with the template cache, so that Craft takes care of cache invalidation according to its own internal logic:</p>

<pre><code>$myCrtieria = ... ; // (some ElementCriteriaModel)

$cacheService = craft()-&gt;getComponent('templateCache', false);

if ($cacheService)
{
    $cacheService-&gt;includeCriteriaInTemplateCaches($myCriteria);
}  
</code></pre>

<p>...</p>

<p><strong>p.s. Unless you really <em>need</em> to render HTML via a Twig hook, I strongly suggest refactoring to use a custom <a href="https://craftcms.com/docs/plugins/variables" rel="nofollow">Template Variable</a> instead.</strong> Doing so is more consistent with Craft's own internal practice. Twig hooks are typically used to change context variables and perform other logic that is specific to changing how Twig renders templates. For doing content-related business logic (e.g. fetching data from the database and rendering it into templates), using Craft's provided structures will save you trouble down the road.</p>

CC BY-SA 3.0
2016-01-19T11:19:15.350Z
I'm aware of these methods... I have no Criteria or Element, though.
andrew.welch
CC BY-SA 3.0
2016-01-19T15:38:21.580Z
Ah, I see. By what event/criteria do you judge that the underlying info has changed and you ought to break the cache?
Michael Rog
CC BY-SA 3.0
2016-01-19T18:36:05.807Z
In this, via a hash of the data.  I'm just looking for a generalized way to tell Craft that a cache needs to be broken... but I'm guessing the only way to do it would be to make a fake element for the express purpose of cache busting.
andrew.welch
CC BY-SA 3.0
2016-01-19T22:52:02.257Z
That would be the approach I'd take: To create a custom Element Type and manage it through your plugin.
Michael Rog
CC BY-SA 3.0
2016-01-18T16:28:34.197Z
2016-01-18T16:37:11.350Z
2016-01-18T16:37:11.350Z
Michael Rog
<p>I have a plugin that renders HTML via a hook.  If someone wraps that hook with <code>{% cache %}</code> in their templates, how can my plugin tell Craft to invalidate the cache when something within it changes?</p>

<p>EDIT: Let's say, for example, that I'm getting JSON data from an external source via my plugin.  I could be rendering this via a hook, or using a Variable, it doesn't matter that much.</p>

<p>There's no Element that the content that changes can be linked to, in order to invalidate the cache.</p>

CC BY-SA 3.0
2016-01-18T10:10:27.867Z
Can you give an example of a template using your plugin? Also, it'd be helpful if you could describe the HTML rendered by your plugin – what does it contain and what "changes" in it when you want to break the cache?
Mats Mikkel Rummelhoff
<plugin-development><cache>
Invalidating the cache tag from a plugin?
# Invalidating the cache tag from a plugin?

(Asked by: username_0 on 2016-01-18)

I have a plugin that renders HTML via a hook. If someone wraps that hook with `{% cache %}` in their templates, how can my plugin tell Craft to invalidate the cache when something within it changes?

EDIT: Let's say, for example, that I'm getting JSON data from an external source via my plugin. I could be rendering this via a hook, or using a Variable, it doesn't matter that much.

There's no Element that the content that changes can be linked to, in order to invalidate the cache.

**Tags:** plugin-development, cache

> **Comments:**
> **username_1**: Can you give an example of a template using your plugin? Also, it'd be helpful if you could describe the HTML rendered by your plugin – what does it contain and what "changes" in it when you want to break the cache?  

---

## 1 answers

### Answer by username_2 on 2016-01-18. Score: 2

The TemplateCacheService provides a ton of helpful methods to take care of this for you.
While you can explicitly tell Craft to invalidate certain caches (by element ID, etc.) if you need to, I prefer to use includeCriteriaInTemplateCaches() and includeElementInTemplateCaches() to register the appropriate element(s)/criteria with the template cache, so that Craft takes care of cache invalidation according to its own internal logic:
$myCrtieria = ... ; // (some ElementCriteriaModel)

$cacheService = craft()->getComponent('templateCache', false);

if ($cacheService)
{
    $cacheService->includeCriteriaInTemplateCaches($myCriteria);
}  

...
p.s. Unless you really need to render HTML via a Twig hook, I strongly suggest refactoring to use a custom Template Variable instead. Doing so is more consistent with Craft's own internal practice. Twig hooks are typically used to change context variables and perform other logic that is specific to changing how Twig renders templates. For doing content-related business logic (e.g. fetching data from the database and rendering it into templates), using Craft's provided structures will save you trouble down the road.

> **Comments:**
> **username_0**: I'm aware of these methods... I have no Criteria or Element, though.  
> **username_2**: Ah, I see. By what event/criteria do you judge that the underlying info has changed and you ought to break the cache?  
> **username_0**: In this, via a hash of the data.  I'm just looking for a generalized way to tell Craft that a cache needs to be broken... but I'm guessing the only way to do it would be to make a fake element for the express purpose of cache busting.  
> **username_2**: That would be the approach I'd take: To create a custom Element Type and manage it through your plugin.  

---

