Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-23T00:30:09.167Z
Answers.Text: 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.
Answers.UserDisplayName: monkeyArms
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-23T00:36:13.430Z
Answers.Text: 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!
Answers.UserDisplayName: monkeyArms
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-23T18:20:18.337Z
Answers.Text: @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.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-04-08T05:08:49.037Z
Answers.Text: 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.
Answers.UserDisplayName: PWL
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-11-22T01:09:07.377Z
Answers.LastActivityDate: 2014-11-23T18:19:21.450Z
Answers.LastEditDate: 2014-11-23T18:19:21.450Z
Answers.UserDisplayName: Brandon Kelly
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-11-21T18:24:45.323Z
Comments.Text: 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.
Comments.UserDisplayName: Steve Abraham
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-11-21T22:36:15.550Z
Comments.Text: Sent to support - I will share the results when I receive them.
Comments.UserDisplayName: monkeyArms
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-11-22T00:41:40.420Z
Comments.Text: 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!
Comments.UserDisplayName: carlcs
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-11-22T00:46:52.983Z
Comments.Text: Not sure if that extra check is more expensive than sending the "unnecessary" data though!?
Comments.UserDisplayName: carlcs
Tags: <field><frontend><field-layout-designer><deletion>
Title: Entries retain field data that has been removed from entry type layout
ThreadText: # 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](https://github.com/marionnewlevant/craft-mnbreakandcontinue) 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 username_3.  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, @username_3 ? Any upcoming "fix" in Craft 4? Hard topic to search for.  
  
  ---
  
  