Body: <p>I can't seem to figure out a good way to see if an Entry has an actual field defined. All the examples I see just to a falsy check for the property name, but this might fail if you have previously defined a field (either by switching Entry Type, or if you modified the Entry Type).</p>
  <p>Example:</p>
  <p>Entry Type 1 previously had a field called <code>MyFirstField</code> (let's say it's a static table).</p>
  <p>I later on concludes that the table was wrong, and hard to work with on some types. So I modify the Entry Type and replace it with <code>MyFirstFieldV2</code>. I still keep <code>MyFirstField</code> on some other type, and I use a shared partial to render this, so I want to check if the current type has <code>MyFirstField</code>, or <code>MyFirstFieldV2</code> and render it appropriately.</p>
  <p>The falsy check works, as long as it is a new entry. If it is an old entry, it will think that it has data for <code>MyFirstField</code>, even though I have removed that field from the type.</p>
  <p>Entry type has a fields() method, that returns an array of all fields, but that becomes quite clunky to work with. I guess it would be possible to make some helper that validates the field name against that array, but it feels like there should be an easier way.</p>
  <p>Preferably I think the entry should loose all properties that no longer exists on the entry type, but it seems like every entry has a property (albeit null) for each and every field that exists in the system?</p>
  <p>EDIT: Regardless whether this is a feature or a bug, what is the appropriate way to check if an Entry Type has a certain field configured? The fields() function doesn't at all return what I expected.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-27T12:46:57.370Z
Comments.Text: I agree that it's not intuitive that when removing a field from an entry type the data does not get deleted, but personally I view this as a feature rather than a bug. For example it allows for switching between (some) fieldtypes without losing data - If you create something as a Redactor field and later decide it should be a simple text input you can switch back without losing any data thanks to this feature. The only real 'solution' to your problem is to put the old field back into the entry type and then delete the content from it.
Comments.UserDisplayName: James Smith
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-27T14:21:43.363Z
Comments.Text: @JamesSmith Sure, having the data intact when switching back is indeed nice, but I'm talking about having the data at hand, when rendering the template. That could be avoidable (filtering out fields that no longer exists).
Comments.UserDisplayName: jishi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-28T11:17:52.130Z
Comments.Text: Looks like refactoring this behaviour has been on the radar for at least 3 years: https://github.com/craftcms/cms/issues/1524 (https://github.com/craftcms/cms/issues/1898)
Comments.UserDisplayName: James Smith
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-02-28T11:44:31.420Z
Comments.Text: Targeted for 4.0, that is exciting news, thank you for providing these links!
Comments.UserDisplayName: jishi
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-09-02T10:54:53.543Z
Comments.Text: Seems to be targeted for 5.0 now... :(
Comments.UserDisplayName: jishi
Tags: <craft3><entry-type>
Title: Check if entry type has field
ThreadText: # Check if entry type has field
  
  (Asked by: username_0 on 2020-02-26)
  
  I can't seem to figure out a good way to see if an Entry has an actual field defined. All the examples I see just to a falsy check for the property name, but this might fail if you have previously defined a field (either by switching Entry Type, or if you modified the Entry Type).
  
  Example:
  
  Entry Type 1 previously had a field called `MyFirstField` (let's say it's a static table).
  
  I later on concludes that the table was wrong, and hard to work with on some types. So I modify the Entry Type and replace it with `MyFirstFieldV2`. I still keep `MyFirstField` on some other type, and I use a shared partial to render this, so I want to check if the current type has `MyFirstField`, or `MyFirstFieldV2` and render it appropriately.
  
  The falsy check works, as long as it is a new entry. If it is an old entry, it will think that it has data for `MyFirstField`, even though I have removed that field from the type.
  
  Entry type has a fields() method, that returns an array of all fields, but that becomes quite clunky to work with. I guess it would be possible to make some helper that validates the field name against that array, but it feels like there should be an easier way.
  
  Preferably I think the entry should loose all properties that no longer exists on the entry type, but it seems like every entry has a property (albeit null) for each and every field that exists in the system?
  
  EDIT: Regardless whether this is a feature or a bug, what is the appropriate way to check if an Entry Type has a certain field configured? The fields() function doesn't at all return what I expected.
  
  **Tags:** craft3, entry-type
  
  > **Comments:**
  > **username_1**: I agree that it's not intuitive that when removing a field from an entry type the data does not get deleted, but personally I view this as a feature rather than a bug. For example it allows for switching between (some) fieldtypes without losing data - If you create something as a Redactor field and later decide it should be a simple text input you can switch back without losing any data thanks to this feature. The only real 'solution' to your problem is to put the old field back into the entry type and then delete the content from it.  
  > **username_0**: @username_1 Sure, having the data intact when switching back is indeed nice, but I'm talking about having the data at hand, when rendering the template. That could be avoidable (filtering out fields that no longer exists).  
  > **username_1**: Looks like refactoring this behaviour has been on the radar for at least 3 years: https://github.com/craftcms/cms/issues/1524 (https://github.com/craftcms/cms/issues/1898)  
  > **username_0**: Targeted for 4.0, that is exciting news, thank you for providing these links!  
  > **username_0**: Seems to be targeted for 5.0 now... :(  
  
  ---
  
  ## 0 answers
  
  