Answers.Body: <p>In my opinion it's a good, easy and fast way to caching content. We use similar solutions on different Websites and it works perfect for us. Maybe you should do a more specific flagging to avoid deleting all cached entries at once. And you should take care about possible dynamic code parts like forms.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-16T13:41:23.083Z
Answers.Text: Thanks for the feedback! Have you had any issues with image transforms in your caching approach?
Answers.UserDisplayName: mjr
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-17T07:25:36.543Z
Answers.Text: Jep, we had once some issues with image transforms. We used generateTransformsBeforePageLoad => true in our general config and sometimes (not traceable) the image transform was not created. Changing back to the default generateTransformsBeforePageLoad  => false fixed this problem. The Craft caching is clever and stores the cache only if no temporary transform url is in the content.
Answers.UserDisplayName: Tom Bauer
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-15T09:56:03.567Z
Answers.LastActivityDate: 2016-06-15T21:02:04.097Z
Answers.LastEditDate: 2016-06-15T21:02:04.097Z
Answers.UserDisplayName: Tom Bauer
Body: <p>I've been thinking about creating the simplest possible cache solution and would like to know if this is a worthwhile option.</p>
  
  <p>Using the outstanding <a href="https://github.com/mmikkel/CacheFlag-Craft">cacheflag</a> plugin, I place the entire layout wrapper template inside these tags:</p>
  
  <pre><code>{% cacheflag flagged "content" globally using key craft.request.path %}
   ... lots o code....
  {% endcacheflag %}
  </code></pre>
  
  <p>In the back end, I flag each of the section with a "content" flag.</p>
  
  <p>I think by doing this, each url should have it's own cache file. And all caches are cleared whenever a new entry is posted.</p>
  
  <p>Granted it may a bit of a sledgehammer style solution, but if traffic is average it could perhaps be effective?</p>
  
  <p>Is my understanding correct or is this a bad idea?</p>
  
Tags: <cache>
Title: Is caching the layout wrapper template a viable option?
ThreadText: # Is caching the layout wrapper template a viable option?
  
  (Asked by: username_0 on 2016-06-14)
  
  I've been thinking about creating the simplest possible cache solution and would like to know if this is a worthwhile option.
  
  Using the outstanding [cacheflag](https://github.com/mmikkel/CacheFlag-Craft) plugin, I place the entire layout wrapper template inside these tags:
  
  ```
  {% cacheflag flagged "content" globally using key craft.request.path %}
   ... lots o code....
  {% endcacheflag %}
  
  ```
  
  In the back end, I flag each of the section with a "content" flag.
  
  I think by doing this, each url should have it's own cache file. And all caches are cleared whenever a new entry is posted.
  
  Granted it may a bit of a sledgehammer style solution, but if traffic is average it could perhaps be effective?
  
  Is my understanding correct or is this a bad idea?
  
  **Tags:** cache
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-06-15. Score: 2 | Accepted answer
  
  In my opinion it's a good, easy and fast way to caching content. We use similar solutions on different Websites and it works perfect for us. Maybe you should do a more specific flagging to avoid deleting all cached entries at once. And you should take care about possible dynamic code parts like forms.
  
  > **Comments:**
  > **username_0**: Thanks for the feedback! Have you had any issues with image transforms in your caching approach?  
  > **username_1**: Jep, we had once some issues with image transforms. We used generateTransformsBeforePageLoad => true in our general config and sometimes (not traceable) the image transform was not created. Changing back to the default generateTransformsBeforePageLoad  => false fixed this problem. The Craft caching is clever and stores the cache only if no temporary transform url is in the content.  
  
  ---
  
  