Answers.Body: <p>I haven't tested this but I'm pretty sure what you want is:</p>
  
  <pre><code>{% cache globally using key craft.request.path unless param == '1' %}
  </code></pre>
  
  <p>More information on the unless parameter can be found at <a href="http://buildwithcraft.com/docs/templating/cache" rel="nofollow">http://buildwithcraft.com/docs/templating/cache</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-25T23:04:05.707Z
Answers.Text: I've tried this, it does bypass the cache if param == '1', but does not clear the cache, which is what I'm trying to do
Answers.UserDisplayName: taylor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-25T21:00:04.637Z
Answers.LastActivityDate: 2015-03-25T21:00:04.637Z
Answers.UserDisplayName: Bruce Johnson
Answers.Body: <p><strong>EDIT</strong></p>
  
  <p><a href="http://buildwithcraft.com/updates#build2664" rel="nofollow">Craft 2.4</a> is now available, adding the <a href="https://buildwithcraft.com/classreference/services/TemplateCacheService#deleteCachesByKey-detail" rel="nofollow">deleteCachesByKey</a> method. This means the following would be the best solution to this question:</p>
  
  <pre><code>public function clearcache($key)
  {
      craft()-&gt;templateCache-&gt;deleteCachesByKey($key);
  }
  </code></pre>
  
  <hr>
  
  <p><strong>ORIGINAL</strong></p>
  
  <p>Your original attempt using a variable method will actually work (as long as the call to the variable method <code>clearcache</code> occurs before the cache tag in your template, of course).</p>
  
  <p><em>Your problem is that the</em> <code>deleteCacheById()</code> <em>method expects the template cache's database ID, not the cache key.</em></p>
  
  <p>Unfortunately, <a href="https://buildwithcraft.com/classreference/services/TemplateCacheService" rel="nofollow">TemplateCacheService</a> doesn't actually offer an easy way to delete a cache by its key, so you'll need to get your hands dirty with a custom SQL query:</p>
  
  <pre><code>public function clearcache( $key )
  {
      craft()-&gt;db-&gt;createCommand()-&gt;delete( 'templatecaches', 'cacheKey=:key', array( ':key'=&gt; $key ) );
  }
  </code></pre>
  
  <p><strong>Disclaimer</strong>: I'd imagine there's a good reason <em>why</em> there's no core <code>deleteCacheByKey</code> method, so it'd be great if somebody with a deeper knowledge of template caches could chime in. Might be there's some ramifications or negative side effects to deleting a cache manually like this.</p>
  
  <p>Sidenote 1: Since the <code>clearcache</code> method shouldn't return any data, consider using Twig's <a href="http://twig.sensiolabs.org/doc/tags/do.html" rel="nofollow">do</a> method to call it:</p>
  
  <pre><code>{% do craft.myplugin.clearcache( craft.request.path ) %}
  </code></pre>
  
  <p>Sidenote 2: Instead of using a combination of GET variables and plugin variable methods to clear the cache, you might want to consider an implementation where you POST your "replies" form to a <em>controller action method</em> in your plugin. The controller could then be responsible for </p>
  
  <ol>
  <li>Saving the reply (possibly to an external application using cURL?)</li>
  <li>Busting the relevant template cache w/ a custom DbCommand</li>
  <li>Redirecting back to the referring page</li>
  </ol>
  
  <p>Having a controller (which in turn might call methods on a <em>service</em> to execute on the above points) might, in my opinion, make for a cleaner implementation than the proposed solution (just based on the limited information you've provided, of course – I wouldn't know about the details or inner workings of your application).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T03:41:09.193Z
Answers.Text: Thanks, Mats! Your modification to 'clearcache()' worked exactly as is, nice! I moved it all out of twig and instead the clearcache() function is being triggered by the service that handles inserting new replies, I agree that is a much cleaner implementation. 
  
  For now, I think this is good enough to move on from, but I am curious to learn more about the craft caching and why there isn't core functionality to do this. There probably is a good reason. If anyone also has any thoughts/knowledge on this I'd love to read about it for curiosities sake.
Answers.UserDisplayName: taylor
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T17:03:21.427Z
Answers.Text: Nice fix Mats! I totally agree... `deleteCacheByKey` should probably be an official thing. Might be worth posting a feature request on [feedback.buildwithcraft.com](http://feedback.buildwithcraft.com/)!
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T21:39:13.457Z
Answers.Text: I concur – and so does apparently Brandon Kelly, as he added a feature request for it a few weeks back :) -> http://feedback.buildwithcraft.com/forums/285221-feature-requests/suggestions/7179242-templatecacheservice-deletecachesbykey
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-03-26T02:34:18.967Z
Answers.LastActivityDate: 2015-06-03T01:12:45.517Z
Answers.LastEditDate: 2015-06-03T01:12:45.517Z
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Body: <p>I've been looking around and can't seem to find anything, maybe it's not possible.</p>
  
  <p>For a forum plugin I'm toying with, topics use more data outside of the page in craft's db, so I need a way to bust the cache as craft won't be able to detect a change. So is there a way to 'bust' the Craft Cache possibly with a variable? I'd love to be able to do something like:</p>
  
  <pre><code>{% set param = craft.request.getParam( 'newreply' ) %}
  
  {% cache globally using key craft.request.path until param == '1' %}
      {# generated page content #}
  {% endcache %}
  </code></pre>
  
  <p>This way it'd stay cached until the page was requested with <code>?newreply=1</code>, effectively busting the cache.</p>
  
  <p>This doesn't seem to be working though. Does anyone have any ideas how this could be accomplished? If not possible with twig, would there be a way to do it in a plugin?</p>
  
  <p>For example, what if I did something like:</p>
  
  <pre><code>{# twig template #}
  
  {{ craft.myplugin.clearcache( craft.request.path ) }}
  
  
  
  {# MyPluginVariable.php #}
  
  public function clearcache($pageid)
  {
  
      craft()-&gt;templateCache-&gt;deleteCacheById($pageid);
  
      return true;
  
  }
  </code></pre>
  
  <p>That doesn't seem to do anything though</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T04:35:54.040Z
Comments.Text: I wonder what happens if you set the `until` value to a time in the past?  Something like `now|date_modify("-1 day")`
Comments.UserDisplayName: Ben Parizek
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T06:10:26.357Z
Comments.Text: Tried it out, doesn't bust cache :[
Comments.UserDisplayName: taylor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T08:37:23.457Z
Comments.Text: What if you append the query string to the key? I.e. ```{% cache globally using key craft.request.path ~ '?' ~ craft.request.queryString %}```
Comments.UserDisplayName: Mats Mikkel Rummelhoff
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T18:59:34.457Z
Comments.Text: That wouldn't get the effect I'm hoping for, as I'd like to flush the cache for the page without the query string. Basically what I want to accomplish is whenever someone writes a new reply to a forum topic, their browser would refresh the page with ?newreply=1, flushing the topic's cache so everyone can see the new response
Comments.UserDisplayName: taylor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T20:16:09.120Z
Comments.Text: Can you make the forum plugin expose the timestamp of the newest reply to Twig? If so, you could change the cache tag to something like: {% cache globally using key 'page-content-' ~ craft.myForumPlugin.newestReplyTimestamp %}. Would create one extra db query, but it'd be as simple as they get.
Comments.UserDisplayName: André Elvan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T20:39:40.817Z
Comments.Text: FWIW, you're original example won't work because [until](http://buildwithcraft.com/docs/templating/cache#until) is specifically looking for a date/time.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-25T23:06:05.870Z
Comments.Text: @AndréElvan Very interesting idea. That would certainly work, would Craft store the old cache for the previous keys though?
Comments.UserDisplayName: taylor
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-26T00:30:47.340Z
Comments.Text: @ZackTaylor Where are your "replies" stored? Outside of Craft? Where does the POST request for the reply form go?
Comments.UserDisplayName: Mats Mikkel Rummelhoff
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-26T09:31:44.843Z
Comments.Text: @ZackTaylor Craft would store the cache until it expires (as specified with the for keyword), but would automatically delete it later.
Comments.UserDisplayName: André Elvan
Tags: <templating><cache>
Title: Busting Craft Cache
ThreadText: # Busting Craft Cache
  
  (Asked by: username_0 on 2015-03-25)
  
  I've been looking around and can't seem to find anything, maybe it's not possible.
  
  For a forum plugin I'm toying with, topics use more data outside of the page in craft's db, so I need a way to bust the cache as craft won't be able to detect a change. So is there a way to 'bust' the Craft Cache possibly with a variable? I'd love to be able to do something like:
  
  ```
  {% set param = craft.request.getParam( 'newreply' ) %}
  
  {% cache globally using key craft.request.path until param == '1' %}
      {# generated page content #}
  {% endcache %}
  
  ```
  
  This way it'd stay cached until the page was requested with `?newreply=1`, effectively busting the cache.
  
  This doesn't seem to be working though. Does anyone have any ideas how this could be accomplished? If not possible with twig, would there be a way to do it in a plugin?
  
  For example, what if I did something like:
  
  ```
  {# twig template #}
  
  {{ craft.myplugin.clearcache( craft.request.path ) }}
  
  {# MyPluginVariable.php #}
  
  public function clearcache($pageid)
  {
  
      craft()->templateCache->deleteCacheById($pageid);
  
      return true;
  
  }
  
  ```
  
  That doesn't seem to do anything though
  
  **Tags:** templating, cache
  
  > **Comments:**
  > **username_1**: I wonder what happens if you set the `until` value to a time in the past?  Something like `now|date_modify("-1 day")`  
  > **username_0**: Tried it out, doesn't bust cache :[  
  > **username_2**: What if you append the query string to the key? I.e. ```{% cache globally using key craft.request.path ~ '?' ~ craft.request.queryString %}```  
  > **username_0**: That wouldn't get the effect I'm hoping for, as I'd like to flush the cache for the page without the query string. Basically what I want to accomplish is whenever someone writes a new reply to a forum topic, their browser would refresh the page with ?newreply=1, flushing the topic's cache so everyone can see the new response  
  > **username_3**: Can you make the forum plugin expose the timestamp of the newest reply to Twig? If so, you could change the cache tag to something like: {% cache globally using key 'page-content-' ~ craft.myForumPlugin.newestReplyTimestamp %}. Would create one extra db query, but it'd be as simple as they get.  
  > **username_4**: FWIW, you're original example won't work because [until](http://buildwithcraft.com/docs/templating/cache#until) is specifically looking for a date/time.  
  > **username_0**: @username_3 Very interesting idea. That would certainly work, would Craft store the old cache for the previous keys though?  
  > **username_2**: @ZackTaylor Where are your "replies" stored? Outside of Craft? Where does the POST request for the reply form go?  
  > **username_3**: @ZackTaylor Craft would store the cache until it expires (as specified with the for keyword), but would automatically delete it later.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-03-26. Score: 6 | Accepted answer
  
  **EDIT**
  
  [Craft 2.4](http://buildwithcraft.com/updates#build2664) is now available, adding the [deleteCachesByKey](https://buildwithcraft.com/classreference/services/TemplateCacheService#deleteCachesByKey-detail) method. This means the following would be the best solution to this question:
  
  ```
  public function clearcache($key)
  {
      craft()->templateCache->deleteCachesByKey($key);
  }
  
  ```
  
  ---
  
  **ORIGINAL**
  
  Your original attempt using a variable method will actually work (as long as the call to the variable method `clearcache` occurs before the cache tag in your template, of course).
  
  *Your problem is that the* `deleteCacheById()` *method expects the template cache's database ID, not the cache key.*
  
  Unfortunately, [TemplateCacheService](https://buildwithcraft.com/classreference/services/TemplateCacheService) doesn't actually offer an easy way to delete a cache by its key, so you'll need to get your hands dirty with a custom SQL query:
  
  ```
  public function clearcache( $key )
  {
      craft()->db->createCommand()->delete( 'templatecaches', 'cacheKey=:key', array( ':key'=> $key ) );
  }
  
  ```
  
  **Disclaimer**: I'd imagine there's a good reason *why* there's no core `deleteCacheByKey` method, so it'd be great if somebody with a deeper knowledge of template caches could chime in. Might be there's some ramifications or negative side effects to deleting a cache manually like this.
  
  Sidenote 1: Since the `clearcache` method shouldn't return any data, consider using Twig's [do](http://twig.sensiolabs.org/doc/tags/do.html) method to call it:
  
  ```
  {% do craft.myplugin.clearcache( craft.request.path ) %}
  
  ```
  
  Sidenote 2: Instead of using a combination of GET variables and plugin variable methods to clear the cache, you might want to consider an implementation where you POST your "replies" form to a *controller action method* in your plugin. The controller could then be responsible for
  
  1. Saving the reply (possibly to an external application using cURL?)
  2. Busting the relevant template cache w/ a custom DbCommand
  3. Redirecting back to the referring page
  
  Having a controller (which in turn might call methods on a *service* to execute on the above points) might, in my opinion, make for a cleaner implementation than the proposed solution (just based on the limited information you've provided, of course – I wouldn't know about the details or inner workings of your application).
  
  > **Comments:**
  > **username_0**: Thanks, username_2! Your modification to 'clearcache()' worked exactly as is, nice! I moved it all out of twig and instead the clearcache() function is being triggered by the service that handles inserting new replies, I agree that is a much cleaner implementation.   For now, I think this is good enough to move on from, but I am curious to learn more about the craft caching and why there isn't core functionality to do this. There probably is a good reason. If anyone also has any thoughts/knowledge on this I'd love to read about it for curiosities sake.  
  > **username_6**: Nice fix username_2! I totally agree... `deleteCacheByKey` should probably be an official thing. Might be worth posting a feature request on [feedback.buildwithcraft.com](http://feedback.buildwithcraft.com/)!  
  > **username_2**: I concur – and so does apparently Brandon Kelly, as he added a feature request for it a few weeks back :) -> http://feedback.buildwithcraft.com/forums/285221-feature-requests/suggestions/7179242-templatecacheservice-deletecachesbykey  
  
  ---
  
  ### Answer by username_5 on 2015-03-25. Score: 1
  
  I haven't tested this but I'm pretty sure what you want is:
  
  ```
  {% cache globally using key craft.request.path unless param == '1' %}
  
  ```
  
  More information on the unless parameter can be found at <http://buildwithcraft.com/docs/templating/cache>
  
  > **Comments:**
  > **username_0**: I've tried this, it does bypass the cache if param == '1', but does not clear the cache, which is what I'm trying to do  
  
  ---
  
  