<p>Correct... by default the <a href="https://craftcms.com/docs/templating/cache" rel="nofollow">{% cache %}</a> tag will use the current page's URI (including querystring) for the cache key.  If you want to change that behavior you'll need to specify the <a href="https://craftcms.com/docs/templating/cache#using-key" rel="nofollow">using key</a> parameter and supply a unique key.  Although you might want to make something more unique than just <code>block.id</code> as that will be an integer and could potentially easily be overwritten.</p>

CC BY-SA 3.0
2016-09-19T17:46:40.263Z
In response to 'Although you might want to make something more unique than just block.id as that will be an integer and could potentially easily be overwritten.' Based on inspecting the templatecaches table, the path is still recorded in the 'path' column, and the (potentially custom) 'cacheKey' is stored in its cacheKey column. So am I right in thinking that even if a custom key is set, the path will still be checked in addition to the custom key when drawing from the cache?
David Oliver
CC BY-SA 3.0
2016-02-05T18:16:38.457Z
2016-02-05T18:16:38.457Z
Brad Bell
<p>When using the <code>{% cache %}</code> tag on an entry type, it caches the first entry on the page (multiple pages as well), and uses the cached entry for every other instance of that entry type on the page. What am I doing wrong? Here's an example. This one isn't complex so not sure it's worth caching, but I have some entries that have multiple relational fields.</p>

<pre><code>{% for block in entry.contentMatrix %}
  {% if block.type == "copyOneCol" %}
    {% cache %}
        .... output entry type data
    {% endcache %}

  ...next if, etc.
{% endfor %}
</code></pre>

CC BY-SA 3.0
2016-02-05T14:47:44.360Z
Ok, I'm using `{%  cache using key block.id %}` and that is tentatively working, giving each section it's own cache (I'm assuming). Is this the best way to do this?
Ben Shoults
<cache>
{% cache %} tag creates duplicate entries
# {% cache %} tag creates duplicate entries

(Asked by: username_0 on 2016-02-05)

When using the {% cache %} tag on an entry type, it caches the first entry on the page (multiple pages as well), and uses the cached entry for every other instance of that entry type on the page. What am I doing wrong? Here's an example. This one isn't complex so not sure it's worth caching, but I have some entries that have multiple relational fields.
{% for block in entry.contentMatrix %}
  {% if block.type == "copyOneCol" %}
    {% cache %}
        .... output entry type data
    {% endcache %}

  ...next if, etc.
{% endfor %}

**Tags:** cache
> **Comments:**
> **username_0**: Ok, I'm using `{%  cache using key block.id %}` and that is tentatively working, giving each section it's own cache (I'm assuming). Is this the best way to do this?  

---

## 1 answers

### Answer by username_1 on 2016-02-05. Score: 1 | Accepted answer

Correct... by default the [{% cache %}](https://craftcms.com/docs/templating/cache) tag will use the current page's URI (including querystring) for the cache key. If you want to change that behavior you'll need to specify the [using key](https://craftcms.com/docs/templating/cache#using-key) parameter and supply a unique key. Although you might want to make something more unique than just `block.id` as that will be an integer and could potentially easily be overwritten.

> **Comments:**
> **username_2**: In response to 'Although you might want to make something more unique than just block.id as that will be an integer and could potentially easily be overwritten.' Based on inspecting the templatecaches table, the path is still recorded in the 'path' column, and the (potentially custom) 'cacheKey' is stored in its cacheKey column. So am I right in thinking that even if a custom key is set, the path will still be checked in addition to the custom key when drawing from the cache?  

---

