5

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.

4
  • If reproducible in the latest build then it sounds like a bug to me, I think it's worth reporting to [email protected] and let the guys know. Nov 21, 2014 at 18:24
  • Sent to support - I will share the results when I receive them.
    – monkeyArms
    Nov 21, 2014 at 22:36
  • 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
    Nov 22, 2014 at 0:41
  • Not sure if that extra check is more expensive than sending the "unnecessary" data though!?
    – carlcs
    Nov 22, 2014 at 0:46

1 Answer 1

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 %}
4
  • 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
    Nov 23, 2014 at 0:30
  • 2
    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
    Nov 23, 2014 at 0:36
  • @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. Nov 23, 2014 at 18:20
  • 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
    Apr 8, 2022 at 5:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.