Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-19T11:19:15.350Z
Answers.Text: I'm aware of these methods... I have no Criteria or Element, though.
Answers.UserDisplayName: andrew.welch
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-19T15:38:21.580Z
Answers.Text: Ah, I see. By what event/criteria do you judge that the underlying info has changed and you ought to break the cache?
Answers.UserDisplayName: Michael Rog
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-19T18:36:05.807Z
Answers.Text: 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.
Answers.UserDisplayName: andrew.welch
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-19T22:52:02.257Z
Answers.Text: That would be the approach I'd take: To create a custom Element Type and manage it through your plugin.
Answers.UserDisplayName: Michael Rog
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-18T16:28:34.197Z
Answers.LastActivityDate: 2016-01-18T16:37:11.350Z
Answers.LastEditDate: 2016-01-18T16:37:11.350Z
Answers.UserDisplayName: Michael Rog
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-18T10:10:27.867Z
Comments.Text: 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?
Comments.UserDisplayName: Mats Mikkel Rummelhoff
Tags: <plugin-development><cache>
Title: Invalidating the cache tag from a plugin?
ThreadText: # 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*](https://craftcms.com/classreference/services/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()`](https://craftcms.com/classreference/services/TemplateCacheService#includeCriteriaInTemplateCaches-detail) and [`includeElementInTemplateCaches()`](https://craftcms.com/classreference/services/TemplateCacheService#includeElementInTemplateCaches-detail) 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](https://craftcms.com/docs/plugins/variables) 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.  
  
  ---
  
  