<p>The fields attached to an asset source will be connected to the asset, and will follow the asset no matter where it's used. So yes, this is the intended behavior.</p>

<p>If you need to specify on an entry basis what size an image should have, you need to add a field for selecting size on the entry type. Say you have a field "Main image" in your entry type, you'd add a "Main image size" field to the same entry type. </p>

<p>If you're making a gallery or something, instead of having one assets field where you select all images, you could create a matrix field that has one column for (one) asset and one column for size instead, and add each image as it's own row.</p>

CC BY-SA 3.0
2016-04-18T06:03:31.477Z
You might also check out the supertable plugin, which can be used in combination with matrix fields to create more complex layouts. In the past I have also created a separate channel called 'partials' (or 'sections' or 'modules' or whatever) and used a matrix field in my main 'pages' structure to create relationships to the partials. This has the advantage of allowing partials to be reused throughout the site as needed.
Douglas McDonald
CC BY-SA 3.0
2014-10-15T21:06:22.787Z
Thanks Andre, this is good to know, and highly disappointing. In EE I would have done as you suggest, but since in the case mentioned I'm not creating a gallery, but a series of different entry types that can be combined by the editors in a single template to create very customisable layouts including text and groups of images. Being able to adjust the image positions etc via Asset fields keeps things clean and intuitive in the editing panel.
pumkincreative
CC BY-SA 3.0
2014-10-15T21:16:02.510Z
I see. So you're creating some sort of long-form articles/one-pagers? How are you using entry types for this? Wouldn't a Matrix field be better suited?
André Elvan
CC BY-SA 3.0
2014-10-15T22:01:08.667Z
I decided that Matrix wasn't practical in this case as there are a fair few fields per type. The model of multiple entry types per section works well for this particular application. Also if I was to use Matrix then I wouldn't have the option to fall back on that to provide unique fields per Asset instance (afaik you can't nest Matrix fields, right?). I am therefore allowing the editors to build up a long single page by adding different entry types within a Structure section.
pumkincreative
CC BY-SA 3.0
2014-10-15T19:09:22.423Z
2014-10-15T19:09:22.423Z
André Elvan
<p>To be clear, you're using <a href="http://buildwithcraft.com/docs/image-transforms" rel="nofollow noreferrer">image transforms</a> to control the size of your image, correct?</p>

<p><a href="https://craftcms.stackexchange.com/a/4163/45">André is correct...</a> If your image manipulation fields will have different values per entry, then those fields should be attached to the <strong>entry type</strong>, not the <strong>asset source</strong>.</p>

<p>So your entry type would contain these fields:</p>

<ul>
<li><strong>Image</strong>

<ul>
<li>"Assets" fieldtype</li>
<li>limit 1</li>
</ul></li>
<li><strong>Image Size</strong>

<ul>
<li>"Dropdown" fieldtype</li>
<li>options: "Small", "Medium", "Large"</li>
</ul></li>
</ul>

<p>Your template would look something like this:</p>

<pre><code>{% set asset = entry.image.first %}
{% set transformSize = entry.imageSize.value %}

&lt;img src="{{ asset.getUrl(transformSize) }}" width="{{ asset.getWidth(transformSize) }}" height="{{ asset.getHeight(transformSize) }}"&gt;
</code></pre>

<p>The person editing the entry can easily select <strong>which asset</strong> and <strong>what size</strong>.</p>

CC BY-SA 3.0
2014-10-17T10:58:08.393Z
Thanks Lindsey, yes I understand this way of doing it, it just seems to me that the usefulness of the fields is reduced if they relate to Assets and not instances of Assets. I would argue that it's also a little counter-intuitive given that you can edit these fields from the Entry page. Anyway I'm probably just grumbling because I didn't realise this and now I've got to change several structures to work as Matrix fields instead of standalone Asset fields.
pumkincreative
CC BY-SA 3.0
2014-10-16T03:43:10.247Z
2016-04-18T05:39:32.087Z
2017-04-13T12:50:59.930Z
Lindsey D
<p>I have a few fields assigned to an Asset Source, which allow the user to alter the appearance of the image (large, small, portrait, landscape) etc. on the front end.</p>

<p>I'm not sure if this is a bug or intended behaviour, but when I enter a field value as an editor to a particular instance of an Asset, if that Asset then appears elsewhere in a different entry, it appears to inherit the field values of the Asset where it was used previously.</p>

<p>I need to be able to have an image in one entry set to, for example, 'large', but also have that same image appear on another entry but set to 'small'.</p>

<p>Assuming this is intended behaviour, how can I get around this?</p>

<assets>
Are values in Asset fields held globally for a particular Asset?
# Are values in Asset fields held globally for a particular Asset?

(Asked by: username_0 on 2014-10-15)

I have a few fields assigned to an Asset Source, which allow the user to alter the appearance of the image (large, small, portrait, landscape) etc. on the front end.

I'm not sure if this is a bug or intended behaviour, but when I enter a field value as an editor to a particular instance of an Asset, if that Asset then appears elsewhere in a different entry, it appears to inherit the field values of the Asset where it was used previously.

I need to be able to have an image in one entry set to, for example, 'large', but also have that same image appear on another entry but set to 'small'.

Assuming this is intended behaviour, how can I get around this?

**Tags:** assets

---

## 2 answers

### Answer by username_1 on 2014-10-15. Score: 2 | Accepted answer

The fields attached to an asset source will be connected to the asset, and will follow the asset no matter where it's used. So yes, this is the intended behavior.

If you need to specify on an entry basis what size an image should have, you need to add a field for selecting size on the entry type. Say you have a field "Main image" in your entry type, you'd add a "Main image size" field to the same entry type.

If you're making a gallery or something, instead of having one assets field where you select all images, you could create a matrix field that has one column for (one) asset and one column for size instead, and add each image as it's own row.

> **Comments:**
> **username_0**: Thanks Andre, this is good to know, and highly disappointing. In EE I would have done as you suggest, but since in the case mentioned I'm not creating a gallery, but a series of different entry types that can be combined by the editors in a single template to create very customisable layouts including text and groups of images. Being able to adjust the image positions etc via Asset fields keeps things clean and intuitive in the editing panel.  
> **username_1**: I see. So you're creating some sort of long-form articles/one-pagers? How are you using entry types for this? Wouldn't a Matrix field be better suited?  
> **username_0**: I decided that Matrix wasn't practical in this case as there are a fair few fields per type. The model of multiple entry types per section works well for this particular application. Also if I was to use Matrix then I wouldn't have the option to fall back on that to provide unique fields per Asset instance (afaik you can't nest Matrix fields, right?). I am therefore allowing the editors to build up a long single page by adding different entry types within a Structure section.  
> **username_2**: You might also check out the supertable plugin, which can be used in combination with matrix fields to create more complex layouts. In the past I have also created a separate channel called 'partials' (or 'sections' or 'modules' or whatever) and used a matrix field in my main 'pages' structure to create relationships to the partials. This has the advantage of allowing partials to be reused throughout the site as needed.  

---

### Answer by username_3 on 2014-10-16. Score: 1

To be clear, you're using image transforms to control the size of your image, correct?
André is correct... If your image manipulation fields will have different values per entry, then those fields should be attached to the entry type, not the asset source.
So your entry type would contain these fields:

Image

"Assets" fieldtype
limit 1

Image Size

"Dropdown" fieldtype
options: "Small", "Medium", "Large"


Your template would look something like this:
{% set asset = entry.image.first %}
{% set transformSize = entry.imageSize.value %}



The person editing the entry can easily select which asset and what size.

> **Comments:**
> **username_0**: Thanks Lindsey, yes I understand this way of doing it, it just seems to me that the usefulness of the fields is reduced if they relate to Assets and not instances of Assets. I would argue that it's also a little counter-intuitive given that you can edit these fields from the Entry page. Anyway I'm probably just grumbling because I didn't realise this and now I've got to change several structures to work as Matrix fields instead of standalone Asset fields.  

---

