<p>My assessment would be if testimonial will never be null and customerImage will always exist (note: not the same as having an asset attached), you can do that if your logic within the include template checks for the existence of an actual image on the field and then calling .one() to get the asset, before outputting anything image related.</p>
<p>The way you have done it is probably the way I'd do it, as you are then having your include do the logic check so it's organised. Equally doing it the way you have done it also allows you to provide an alternative layout to fallback to without an image if you wanted.</p>

CC BY-SA 4.0
2022-07-04T21:44:20.123Z
Thanks. My main concern is if something would result in a fatal error when an image is not set and I use the value to pass it. But from your answer I assume this is not a problem! ;)
Álvaro Franz
CC BY-SA 4.0
2022-07-04T21:51:27.617Z
@AlvaroFranz In this case, both the section and field itself will exist on the entry for the include to be valid, you are then doing your checks for an actual asset image to then use, so no the include shouldn't cause any issues.
James White
CC BY-SA 4.0
2022-07-04T21:53:57.077Z
Thanks. Im accepting this answer because it answers the original question. Curiosity: in what case would the field not exist and throw an error? Only if it is not defined in Craft? I mean, always, when the field exists in Craft, will nit exist in the template as "null" when defined but not used?
Álvaro Franz
CC BY-SA 4.0
2022-07-04T22:02:27.267Z
Generally yes, if the field exists in your fields table and it's on the content table (unless a matrix field), it can't not exist but if the field isn't on your entry type template, it will likely have no value i.e. null. You just have to bear in mind with Twig when calling objects on variables in a chain, if there's a chance that one can be null, you need to either use null coalesce or check before trying to use it, but in this case, your section is unlikely to never not exist and the image field is a defined field in Craft, but defensive coding is still something to be aware of.
James White
CC BY-SA 4.0
2022-07-04T20:05:31.770Z
2022-07-04T20:16:58.440Z
2022-07-04T20:16:58.440Z
James White
<p>Let's say I have a channel called <code>testimonial</code> which has a field called <code>customerImage</code>.</p>
<p>I want to use a twig template to display information about the customer, which may or may not have an image set.</p>
<p>So, inside the twig template for the channel, I have:</p>
<pre><code>...
&lt;h2&gt;Whatever&lt;/h2&gt;
&lt;div class=&quot;whatever&quot;&gt;
    {% include '/_includes/showImage' with {
        image: testimonial.customerImage
    } %}
&lt;/div&gt;
....
</code></pre>
<p>The question is, do I need to check for <code>testimonial.customerImage</code> being set before passing it to the include, if the include already checks it?</p>
<p>The <code>showImage.twig</code> file uses it as follows:</p>
<pre><code>{% if image and image.one() %}
....
</code></pre>
<p>Is this correct or do I have to check if it exists before using it even to pass the value?</p>

<templating><variable>
Do I have to check if a field has a value if I want to use it in an include that already checks the value?
# Do I have to check if a field has a value if I want to use it in an include that already checks the value?

(Asked by: username_0 on 2022-07-04)

Let's say I have a channel called testimonial which has a field called customerImage.
I want to use a twig template to display information about the customer, which may or may not have an image set.
So, inside the twig template for the channel, I have:
...
Whatever

    {% include '/_includes/showImage' with {
        image: testimonial.customerImage
    } %}

....

The question is, do I need to check for testimonial.customerImage being set before passing it to the include, if the include already checks it?
The showImage.twig file uses it as follows:
{% if image and image.one() %}
....

Is this correct or do I have to check if it exists before using it even to pass the value?

**Tags:** templating, variable

---

## 1 answers

### Answer by username_1 on 2022-07-04. Score: 2 | Accepted answer

My assessment would be if testimonial will never be null and customerImage will always exist (note: not the same as having an asset attached), you can do that if your logic within the include template checks for the existence of an actual image on the field and then calling .one() to get the asset, before outputting anything image related.

The way you have done it is probably the way I'd do it, as you are then having your include do the logic check so it's organised. Equally doing it the way you have done it also allows you to provide an alternative layout to fallback to without an image if you wanted.

> **Comments:**
> **username_0**: Thanks. My main concern is if something would result in a fatal error when an image is not set and I use the value to pass it. But from your answer I assume this is not a problem! ;)  
> **username_1**: @AlvaroFranz In this case, both the section and field itself will exist on the entry for the include to be valid, you are then doing your checks for an actual asset image to then use, so no the include shouldn't cause any issues.  
> **username_0**: Thanks. Im accepting this answer because it answers the original question. Curiosity: in what case would the field not exist and throw an error? Only if it is not defined in Craft? I mean, always, when the field exists in Craft, will nit exist in the template as "null" when defined but not used?  
> **username_1**: Generally yes, if the field exists in your fields table and it's on the content table (unless a matrix field), it can't not exist but if the field isn't on your entry type template, it will likely have no value i.e. null. You just have to bear in mind with Twig when calling objects on variables in a chain, if there's a chance that one can be null, you need to either use null coalesce or check before trying to use it, but in this case, your section is unlikely to never not exist and the image field is a defined field in Craft, but defensive coding is still something to be aware of.  

---

