<p>Technically, all entries have all fields, regardless of their layout. Field layouts are mostly just a UI thing.</p>

<blockquote>
  <p>1) Is there a way to tell if an field is actually actively assigned to the entry layout?</p>
</blockquote>

<p>It’s a little cumbersome and would require the <a href="https://github.com/marionnewlevant/craft-mnbreakandcontinue" rel="nofollow">MN Break and Continue</a> plugin, but yes:</p>

<pre><code>{% for flf in entry.getFieldLayout().getFields() %}
    {% set field = flf.getField() %}

    {% if field.handle == 'text' %}
        {{ entry.text }}
        {% break %}
    {% elseif field.handle == 'multiContent' %}
        {{ entry.multiContent.text }}
        {% break %}
    {% endif %}
{% endfor %}
</code></pre>

<blockquote>
  <p>2) I understand why the field data would be retained in the database even though the field was removed from the layout, but under what circumstances would populating 'deleted' fields for entries be desired behavior? It surely adds overhead, it is counter-intuitive (imo) and has the potential to cause all sort of issues.</p>
</blockquote>

<p>Actually it’s <em>faster</em> for Craft to not worry about the field layout, which is why it’s not taken into account right now. Less data to fetch, and logic to run. If you check for <code>entry.text</code>, Craft just assumes you know what you’re doing.</p>

<p>Maybe a better approach would be to just check the entry type’s ID/name:</p>

<pre><code>{% if entry.typeId in [1,2,3] %}
    {{ entry.text }}
{% elseif entry.typeId in [4,5,6] %}
    {{ entry.multiContent.text }}
{% endif %}
</code></pre>

<p>(or)</p>

<pre><code>{% if entry.type.handle in ['one', 'two', 'three'] %}
    {{ entry.text }}
{% elseif entry.type.handle in ['four', 'five', 'six'] %}
    {{ entry.multiContent.text }}
{% endif %}
</code></pre>

CC BY-SA 3.0
2014-11-23T00:30:09.167Z
Thank you Brandon.  I went with the breakandcontinue solution along with looping over the field layout fields.  I don't believe the second approach would work because I have multiple entry types with different fields in each section.
monkeyArms
CC BY-SA 3.0
2014-11-23T00:36:13.430Z
Side note: I still feel that having all fields available to each entry is unexpected/undesired behavior, and I can't think of a single case when it would be useful.  I guess I will have to put a sticky-note on my computer and live with it (until it bites me).  Thanks again!
monkeyArms
CC BY-SA 3.0
2014-11-23T18:20:18.337Z
@monkeyArms Just edited the 2nd option in my answer to be based on the entry type’s ID/handle, rather than the section’s. Same basic idea.
Brandon Kelly
CC BY-SA 4.0
2022-04-08T05:08:49.037Z
It's been 8 years, is there another out-of-the-box solution for this at this point, @BrandonKelly ? Any upcoming "fix" in Craft 4? Hard topic to search for.
PWL
CC BY-SA 3.0
2014-11-22T01:09:07.377Z
2014-11-23T18:19:21.450Z
2014-11-23T18:19:21.450Z
Brandon Kelly
<p>I have a single page section titled "About".  At one point, I had assigned a "text" Rich Text field to the entry type layout.  I then put some filler text in this field and saved the entry.  Later I removed this field from the field layout.</p>

<p>The issue is that craft still populates this entry field on the front-end, i.e. <code>{{ entry.text }}</code> still shows the filler text.</p>

<p>This is problematic for several reasons, but most importantly (in my scenario) because I am working on a search results template which shows an excerpt from each entry; different entries may have different fields available, so I am doing a basic if/else to see what fields may be available, i.e.:</p>

<pre><code>{% if entry.text is defined %}
    {{ entry.text }}
{% elseif entry.multiContent.text is defined %}
    {{ entry.multiContent.text }}
{% endif %}
</code></pre>

<p>This raises two questions:</p>

<p>1) Is there a way to tell if an field is actually <em>actively</em> assigned to the entry layout?</p>

<p>2) I understand why the field data would be retained in the database even though the field was removed from the layout, but under what circumstances would populating 'deleted' fields for entries be desired behavior?  It surely adds overhead, it is counter-intuitive (imo) and has the potential to cause all sort of issues.</p>

CC BY-SA 3.0
2014-11-21T18:24:45.323Z
If reproducible in the latest build then it sounds like a bug to me, I think it's worth reporting to support@buildwithcraft.com and let the guys know.
Steve Abraham
CC BY-SA 3.0
2014-11-21T22:36:15.550Z
Sent to support - I will share the results when I receive them.
monkeyArms
CC BY-SA 3.0
2014-11-22T00:41:40.420Z
It's probably not the desired behavior, but simply not yet build-in to return active fields only. Thanks for reporting this to P&T!
carlcs
CC BY-SA 3.0
2014-11-22T00:46:52.983Z
Not sure if that extra check is more expensive than sending the "unnecessary" data though!?
carlcs
<field><frontend><field-layout-designer><deletion>
Entries retain field data that has been removed from entry type layout
# Entries retain field data that has been removed from entry type layout

(Asked by: username_0 on 2014-11-21)

I have a single page section titled "About".  At one point, I had assigned a "text" Rich Text field to the entry type layout.  I then put some filler text in this field and saved the entry.  Later I removed this field from the field layout.
The issue is that craft still populates this entry field on the front-end, i.e. {{ entry.text }} still shows the filler text.
This is problematic for several reasons, but most importantly (in my scenario) because I am working on a search results template which shows an excerpt from each entry; different entries may have different fields available, so I am doing a basic if/else to see what fields may be available, i.e.:
{% if entry.text is defined %}
    {{ entry.text }}
{% elseif entry.multiContent.text is defined %}
    {{ entry.multiContent.text }}
{% endif %}

This raises two questions:
1) Is there a way to tell if an field is actually actively assigned to the entry layout?
2) I understand why the field data would be retained in the database even though the field was removed from the layout, but under what circumstances would populating 'deleted' fields for entries be desired behavior?  It surely adds overhead, it is counter-intuitive (imo) and has the potential to cause all sort of issues.

**Tags:** field, frontend, field-layout-designer, deletion

> **Comments:**
> **username_1**: If reproducible in the latest build then it sounds like a bug to me, I think it's worth reporting to support@buildwithcraft.com and let the guys know.  
> **username_0**: Sent to support - I will share the results when I receive them.  
> **username_2**: It's probably not the desired behavior, but simply not yet build-in to return active fields only. Thanks for reporting this to P&T!  
> **username_2**: Not sure if that extra check is more expensive than sending the "unnecessary" data though!?  

---

## 1 answers

### Answer by username_3 on 2014-11-22. Score: 4

Technically, all entries have all fields, regardless of their layout. Field layouts are mostly just a UI thing.

1) Is there a way to tell if an field is actually actively assigned to the entry layout?

It’s a little cumbersome and would require the MN Break and Continue plugin, but yes:
{% for flf in entry.getFieldLayout().getFields() %}
    {% set field = flf.getField() %}

    {% if field.handle == 'text' %}
        {{ entry.text }}
        {% break %}
    {% elseif field.handle == 'multiContent' %}
        {{ entry.multiContent.text }}
        {% break %}
    {% endif %}
{% endfor %}


2) I understand why the field data would be retained in the database even though the field was removed from the layout, but under what circumstances would populating 'deleted' fields for entries be desired behavior? It surely adds overhead, it is counter-intuitive (imo) and has the potential to cause all sort of issues.

Actually it’s faster for Craft to not worry about the field layout, which is why it’s not taken into account right now. Less data to fetch, and logic to run. If you check for entry.text, Craft just assumes you know what you’re doing.
Maybe a better approach would be to just check the entry type’s ID/name:
{% if entry.typeId in [1,2,3] %}
    {{ entry.text }}
{% elseif entry.typeId in [4,5,6] %}
    {{ entry.multiContent.text }}
{% endif %}

(or)
{% if entry.type.handle in ['one', 'two', 'three'] %}
    {{ entry.text }}
{% elseif entry.type.handle in ['four', 'five', 'six'] %}
    {{ entry.multiContent.text }}
{% endif %}

> **Comments:**
> **username_0**: Thank you Brandon.  I went with the breakandcontinue solution along with looping over the field layout fields.  I don't believe the second approach would work because I have multiple entry types with different fields in each section.  
> **username_0**: Side note: I still feel that having all fields available to each entry is unexpected/undesired behavior, and I can't think of a single case when it would be useful.  I guess I will have to put a sticky-note on my computer and live with it (until it bites me).  Thanks again!  
> **username_3**: @username_0 Just edited the 2nd option in my answer to be based on the entry type’s ID/handle, rather than the section’s. Same basic idea.  
> **username_4**: It's been 8 years, is there another out-of-the-box solution for this at this point, @BrandonKelly ? Any upcoming "fix" in Craft 4? Hard topic to search for.  

---

