Answers.Body: <p>Is there a chance you once had this field <em>added to both sections</em>? Because this all looks like there's data still left set and you're only expecting "eventLevel" fields to be empty / null for your "activities" section entries, but in fact they are not.</p>
  
  <p>See this SE for <em>why</em> this can happen:<br>
  <a href="https://craftcms.stackexchange.com/questions/4869/entries-retain-field-data-that-has-been-removed-from-entry-type-layout">Entries retain field data that has been removed from entry type layout</a></p>
  
  <p>To solve the problem you could now clear the data, by (a) recreating the radio field with the same settings but with a different handle / name, go through your entries to copy the values, then delete the old field and give the new one the handle and name of the old one. Or you could (b) directly edit the values in the database, the problem with this approach is, you can't sort the records by section.</p>
  
  <p>This would also mean alot of work and I think it's actually not worth it at all, because there's a better way  to distinguish whether to show the field's value or not: just check for the entry's section!</p>
  
  <p>Here's how I would do it:</p>
  
  <pre><code>{% set isEvent = entry.section.handle == 'events' %}
  {% set isActivity = entry.section.handle == 'activities' %}
  
  {{ isEvent ? entry.eventLevel : 'Activity' }}
  </code></pre>
  
  <p>You just evaluate <code>entry.section.handle == 'events'</code> and store the result as a variable at the top of your template code. The variable is now available troughout the template and it is now very easy to use this info. You currently only need it once in your code, but this probably changes as you progress with the project.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T21:42:25.730Z
Answers.Text: Whilst similar to James's answer this one has a bit more flexibility, so I changed my selected answer.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T22:06:38.410Z
Answers.Text: It does also reflect the additional help that carlcs gave me getting to the root of the problem via a Slack DM conversation.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T18:25:22.330Z
Answers.LastActivityDate: 2016-02-19T18:30:28.597Z
Answers.LastEditDate: 2017-04-13T12:50:59.930Z
Answers.UserDisplayName: carlcs
Answers.Body: <p>To test if a field exists, you'll have to use brackets notation, i.e.</p>
  
  <pre><code>{% if entry['eventLevel'] is defined %}
     ...
  {% endif %}
  </code></pre>
  
  <p>When the field exists, but there isn't a selected option, the Radio FieldType returns an empty string, so you also need to test for <code>entry.eventLevel != ''</code>.</p>
  
  <p>Putting it together, I believe a ternary conditional would perhaps be the most succinct solution in your particular case:</p>
  
  <pre><code>&lt;td&gt;{{ entry['eventLevel'] is defined and entry.eventLevel != '' ? entry.eventLevel : 'Activity' }}&lt;/td&gt;
  </code></pre>
  
  <p>What the above does is to first check if the <code>entry</code> has a property <code>'eventLevel'</code> – the brackets notation is needed here, to avoid Twig throwing an exception if the <code>entry</code> variable <em>doesn't</em> have the property – before checking if the attribute's value is not an empty string. If both of those statements evaluate to <code>true</code>, then the attribute's value is printed; if not, the string <code>Activity</code> outputs.</p>
  
  <p>This is a bit beside the point, but if you're wondering about the syntax here, the so called <a href="http://twig.sensiolabs.org/doc/templates.html#other-operators" rel="nofollow">ternary operator</a> (e.g. <code>{{ variable ? 'yes' : 'no' }}</code>) is just a kind of a short-hand way to write conditionals. Ternary operators are supported in many programming languages (including JavaScript and PHP).</p>
  
  <p>If you wanted to, you could write out the full conditional and it would work exactly the same:</p>
  
  <pre><code>&lt;td&gt;
      {% if entry['eventLevel'] is defined and entry.eventLevel != '' %}
         {{ entry.eventLevel }}
      {% else %}
         Activity
      {% endif %}
  &lt;/td&gt;
  </code></pre>
  
  <p>I'd argue that a ternary operator is more readable, shorter and also makes it easier to deal with potential whitespace issues etc. when inlined in markup like this, though.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T12:13:59.227Z
Answers.Text: That didn't work, still blank if no eventLevel.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T12:27:32.297Z
Answers.Text: @PaulFrost Right – I assumed the Radio FieldType returned a falsey value for fields without a selected value, but it actually returns an empty string. I edited my answer; should work now – the correct test is `entry[eventLevel] is defined and entry.eventLevel != ''`
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T13:03:16.107Z
Answers.Text: The `if entry.eventLevel is defined` test won't work in this case, because it is truthy even if the field isn't attached to this entry type's field layout but to any other entry type. A simple `if entry.eventLevel` test should work though.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T13:53:52.543Z
Answers.Text: Your revised example works. But I'm confused by the structure of the query, I haven't seen the the ? and colon used in examples before, where is that documented?.
   I had tried {% if entry.eventLevel %}{{ entry.eventLevel }}{% else %}Activity{% endif %} in the first place and when that didn't work I tried to be more specific.
  So both James and Mats solutions work but neither seem very intuitive.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T13:58:12.823Z
Answers.Text: I'm really struggling with the conversion from using ExpressionEngine to Craft, some simple things seem to require very complex, unintuitive code and with so many ways to do the same thing finding examples  is hard.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T14:09:10.300Z
Answers.Text: @PaulFrost No worries – I amended my answer to include some more details for both the conditional itself, and so-called ternary operators in general. Hope it helps. As for EE vs. Craft, I've worked with both and I'd argue that Twig is _way_ easier to deal with than EE's parser. However, the two are very different and of course there'll be a learning curve. I recommend checking out [Straight Up Craft's introductory Twig tutorials](https://straightupcraft.com/articles/getting-started-with-twig-templating-for-craft-cms); they're pretty good for getting a jump start on all of the basic concepts.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T14:10:40.610Z
Answers.Text: Also, [Craft Cookbook](http://craftcookbook.net/) is a great place to find code examples.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T14:51:55.330Z
Answers.Text: Thanks Mike, I've browsed those links and keep referring/searching through them whenever I want to do something, but as this thread shows there are at least 2 solutions and they are very different. I'm not a programmer, so it seems that many solutions require a bit more of a PHP general knowledge/thought process than I have.  But I don't think I'm going back to EE.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T15:26:50.877Z
Answers.Text: @PaulFrost you have an array of entries and they are from two different sections. If an entry is from section A, it has a value for the radio field and if  it's from section B it has no value (stored as NULL). When looping through your entries you have now two options, check the field value or check the section handle. Hope this makes it clearer for you.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T16:33:47.137Z
Answers.Text: @carlcs I still don't understand why {% if entry.eventLevel %}{{ entry.eventLevel }}{% else %}Activity{% endif %} or adding is defined, is null, or length doesn't work. Section B doesn't have the eventLevel field in it's field layout, so I would expect it to be empty or null or not defined.
  It's the need to wrap eventLevel in brackets that confuses me. I'm not sure when or why I should do that, as I have other IF variable loops that work without brackets.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T16:47:59.413Z
Answers.Text: Yeah, I think `if entry.eventLevel` or `if entry.eventLevel is null` should work and the `is defined` test isn't necessary. There's one exception though, which is if you had this field attached to section B and later removed it, because removing a field doesn't delete the values from the db. Maybe this is the case here?
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T16:52:39.627Z
Answers.Text: @PaulFrost It's because for some of your entries (i.e. the Section B ones), the `eventLevel` attribute won't exist, and attempting to access a non-existing attribute isn't allowed (even as a part of a conditional). See [this page](https://straightupcraft.com/articles/testing-if-something-exists-is-defined-length-is-not-null-is-not-empty#how-can-you-tell-if-a-variable-exists) for reference. I'd recommend turning on [`devMode`](https://craftcms.com/support/dev-mode) for your dev environment if you haven't; it'll make debugging your code a lot easier.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T16:59:41.297Z
Answers.Text: @carlcs The issue is that `{% if entry.attributeThatDoesntExist is defined %}` will always evaluate to `true` (you can test this with `{{ dump(entry.attributeThatDoesntExist is defined) }}`). I don't know exactly _why_ it this is, and I admit it seems less than logical/intuitive, but the gist is that whenever an attribute may or may not exist, you have to use brackets notation to test for it before attempting to access the attribute using dot notation.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T11:36:55.443Z
Answers.LastActivityDate: 2016-02-19T17:02:52.640Z
Answers.LastEditDate: 2016-02-19T17:02:52.640Z
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.Body: <p>How about a conditional to check the entry.type rather than the field? Perhaps more appropriate in this case rather than checking if the field is defined. Something like this:</p>
  
  <pre><code>{% if entry.type.handle == 'events' %}
      {{ entry.eventLevel }}
  {% else %}
      Activity
  {% endif %}
  </code></pre>
  
  <p>Alternatively, check the section rather than the entry type with <code>entry.section.handle</code> instead of <code>entry.type.handle</code>.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T12:16:58.337Z
Answers.Text: I'm not sure what you mean, by check the entry.type. Plus if it's an event it must have a level set, can't be empty.
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T12:38:54.560Z
Answers.Text: @PaulFrost I’ve just edited the answer to include an example.
Answers.UserDisplayName: James
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T13:10:35.047Z
Answers.Text: @James I think he's confused because he's getting the entries from multiple sections. Your answer probably works anyways, because there's a good chance he's got this set up with different entry type handles.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T13:23:28.553Z
Answers.Text: @carlcs good point. Paul, you could also check against the entry.section rather than the entry type if that makes more sense.
Answers.UserDisplayName: James
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T13:41:20.010Z
Answers.Text: Yes, I changed it to section and that works. But I would never have found that solution from the docs. Why do I need to check the section first?
Answers.UserDisplayName: Paul Frost
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T14:04:05.890Z
Answers.Text: You check for the entry's section and conditional on that either output the field value or something else. The code simply expresses what you are askin for, @PaulFrost...
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T11:29:27.850Z
Answers.LastActivityDate: 2016-02-19T13:27:43.553Z
Answers.LastEditDate: 2016-02-19T13:27:43.553Z
Answers.UserDisplayName: James
Body: <p>I have 2 sections, events and activities, that share many fields. But activities doesn't have an eventLevel field as there isn't a level. eventLevel is a radio fieldtype. So I want to insert the eventLevel when it exists and if it doesn't just insert the text "Activity". I've tried various tests on if eventLevel is defined, is null, and length. If there is an eventLevel it displays, but if it's an activity I end up with an empty cell.</p>
  
  <pre><code>{% set events = craft.entries.find({section:'events,activities', eventDate : "&gt;= " ~ now.w3cDate() , order:'eventDate'}) %}
  {% if events %}
      {% for entry in events %}
      &lt;tr&gt;
          &lt;td class="col-date"&gt;{{ entry.eventDate.format('D j M') }}&lt;/td&gt;
          &lt;td&gt;&lt;a href="{{ entry.url }}" title="More info about {{ entry.eventName }}"&gt;{{ entry.eventName }}&lt;/a&gt;&lt;/td&gt;
          &lt;td&gt;{{ entry.nearestTown }}&lt;/td&gt;
          &lt;td&gt;{% if entry.eventLevel is defined %}{{ entry.eventLevel }}{% else %}Activity{% endif %}&lt;/td&gt;
      &lt;/tr&gt;
      {% endfor %}
  {% endif %}
  </code></pre>
  
  <p>I've also tried the twig default filter with the same result:</p>
  
  <pre><code>{{ entry.eventLevel|default('Activity') }}
  </code></pre>
  
Tags: <conditional>
Title: Problem with IF conditional not working
ThreadText: # Problem with IF conditional not working
  
  (Asked by: username_0 on 2016-02-19)
  
  I have 2 sections, events and activities, that share many fields. But activities doesn't have an eventLevel field as there isn't a level. eventLevel is a radio fieldtype. So I want to insert the eventLevel when it exists and if it doesn't just insert the text "Activity". I've tried various tests on if eventLevel is defined, is null, and length. If there is an eventLevel it displays, but if it's an activity I end up with an empty cell.
  
  ```
  {% set events = craft.entries.find({section:'events,activities', eventDate : ">= " ~ now.w3cDate() , order:'eventDate'}) %}
  {% if events %}
      {% for entry in events %}
      <tr>
          <td class="col-date">{{ entry.eventDate.format('D j M') }}</td>
          <td><a href="{{ entry.url }}" title="More info about {{ entry.eventName }}">{{ entry.eventName }}</a></td>
          <td>{{ entry.nearestTown }}</td>
          <td>{% if entry.eventLevel is defined %}{{ entry.eventLevel }}{% else %}Activity{% endif %}</td>
      </tr>
      {% endfor %}
  {% endif %}
  
  ```
  
  I've also tried the twig default filter with the same result:
  
  ```
  {{ entry.eventLevel|default('Activity') }}
  
  ```
  
  **Tags:** conditional
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2016-02-19. Score: 2 | Accepted answer
  
  Is there a chance you once had this field *added to both sections*? Because this all looks like there's data still left set and you're only expecting "eventLevel" fields to be empty / null for your "activities" section entries, but in fact they are not.
  
  See this SE for *why* this can happen:  
  [Entries retain field data that has been removed from entry type layout](https://craftcms.stackexchange.com/questions/4869/entries-retain-field-data-that-has-been-removed-from-entry-type-layout)
  
  To solve the problem you could now clear the data, by (a) recreating the radio field with the same settings but with a different handle / name, go through your entries to copy the values, then delete the old field and give the new one the handle and name of the old one. Or you could (b) directly edit the values in the database, the problem with this approach is, you can't sort the records by section.
  
  This would also mean alot of work and I think it's actually not worth it at all, because there's a better way to distinguish whether to show the field's value or not: just check for the entry's section!
  
  Here's how I would do it:
  
  ```
  {% set isEvent = entry.section.handle == 'events' %}
  {% set isActivity = entry.section.handle == 'activities' %}
  
  {{ isEvent ? entry.eventLevel : 'Activity' }}
  
  ```
  
  You just evaluate `entry.section.handle == 'events'` and store the result as a variable at the top of your template code. The variable is now available troughout the template and it is now very easy to use this info. You currently only need it once in your code, but this probably changes as you progress with the project.
  
  > **Comments:**
  > **username_0**: Whilst similar to username_3's answer this one has a bit more flexibility, so I changed my selected answer.  
  > **username_0**: It does also reflect the additional help that username_1 gave me getting to the root of the problem via a Slack DM conversation.  
  
  ---
  
  ### Answer by username_2 on 2016-02-19. Score: 4
  
  To test if a field exists, you'll have to use brackets notation, i.e.
  
  ```
  {% if entry['eventLevel'] is defined %}
     ...
  {% endif %}
  
  ```
  
  When the field exists, but there isn't a selected option, the Radio FieldType returns an empty string, so you also need to test for `entry.eventLevel != ''`.
  
  Putting it together, I believe a ternary conditional would perhaps be the most succinct solution in your particular case:
  
  ```
  <td>{{ entry['eventLevel'] is defined and entry.eventLevel != '' ? entry.eventLevel : 'Activity' }}</td>
  
  ```
  
  What the above does is to first check if the `entry` has a property `'eventLevel'` – the brackets notation is needed here, to avoid Twig throwing an exception if the `entry` variable *doesn't* have the property – before checking if the attribute's value is not an empty string. If both of those statements evaluate to `true`, then the attribute's value is printed; if not, the string `Activity` outputs.
  
  This is a bit beside the point, but if you're wondering about the syntax here, the so called [ternary operator](http://twig.sensiolabs.org/doc/templates.html#other-operators) (e.g. `{{ variable ? 'yes' : 'no' }}`) is just a kind of a short-hand way to write conditionals. Ternary operators are supported in many programming languages (including JavaScript and PHP).
  
  If you wanted to, you could write out the full conditional and it would work exactly the same:
  
  ```
  <td>
      {% if entry['eventLevel'] is defined and entry.eventLevel != '' %}
         {{ entry.eventLevel }}
      {% else %}
         Activity
      {% endif %}
  </td>
  
  ```
  
  I'd argue that a ternary operator is more readable, shorter and also makes it easier to deal with potential whitespace issues etc. when inlined in markup like this, though.
  
  > **Comments:**
  > **username_0**: That didn't work, still blank if no eventLevel.  
  > **username_2**: @username_0 Right – I assumed the Radio FieldType returned a falsey value for fields without a selected value, but it actually returns an empty string. I edited my answer; should work now – the correct test is `entry[eventLevel] is defined and entry.eventLevel != ''`  
  > **username_1**: The `if entry.eventLevel is defined` test won't work in this case, because it is truthy even if the field isn't attached to this entry type's field layout but to any other entry type. A simple `if entry.eventLevel` test should work though.  
  > **username_0**: Your revised example works. But I'm confused by the structure of the query, I haven't seen the the ? and colon used in examples before, where is that documented?.  I had tried {% if entry.eventLevel %}{{ entry.eventLevel }}{% else %}Activity{% endif %} in the first place and when that didn't work I tried to be more specific. So both username_3 and username_2 solutions work but neither seem very intuitive.  
  > **username_0**: I'm really struggling with the conversion from using ExpressionEngine to Craft, some simple things seem to require very complex, unintuitive code and with so many ways to do the same thing finding examples  is hard.  
  > **username_2**: @username_0 No worries – I amended my answer to include some more details for both the conditional itself, and so-called ternary operators in general. Hope it helps. As for EE vs. Craft, I've worked with both and I'd argue that Twig is _way_ easier to deal with than EE's parser. However, the two are very different and of course there'll be a learning curve. I recommend checking out [Straight Up Craft's introductory Twig tutorials](https://straightupcraft.com/articles/getting-started-with-twig-templating-for-craft-cms); they're pretty good for getting a jump start on all of the basic concepts.  
  > **username_2**: Also, [Craft Cookbook](http://craftcookbook.net/) is a great place to find code examples.  
  > **username_0**: Thanks Mike, I've browsed those links and keep referring/searching through them whenever I want to do something, but as this thread shows there are at least 2 solutions and they are very different. I'm not a programmer, so it seems that many solutions require a bit more of a PHP general knowledge/thought process than I have.  But I don't think I'm going back to EE.  
  > **username_1**: @username_0 you have an array of entries and they are from two different sections. If an entry is from section A, it has a value for the radio field and if  it's from section B it has no value (stored as NULL). When looping through your entries you have now two options, check the field value or check the section handle. Hope this makes it clearer for you.  
  > **username_0**: @username_1 I still don't understand why {% if entry.eventLevel %}{{ entry.eventLevel }}{% else %}Activity{% endif %} or adding is defined, is null, or length doesn't work. Section B doesn't have the eventLevel field in it's field layout, so I would expect it to be empty or null or not defined. It's the need to wrap eventLevel in brackets that confuses me. I'm not sure when or why I should do that, as I have other IF variable loops that work without brackets.  
  > **username_1**: Yeah, I think `if entry.eventLevel` or `if entry.eventLevel is null` should work and the `is defined` test isn't necessary. There's one exception though, which is if you had this field attached to section B and later removed it, because removing a field doesn't delete the values from the db. Maybe this is the case here?  
  > **username_2**: @username_0 It's because for some of your entries (i.e. the Section B ones), the `eventLevel` attribute won't exist, and attempting to access a non-existing attribute isn't allowed (even as a part of a conditional). See [this page](https://straightupcraft.com/articles/testing-if-something-exists-is-defined-length-is-not-null-is-not-empty#how-can-you-tell-if-a-variable-exists) for reference. I'd recommend turning on [`devMode`](https://craftcms.com/support/dev-mode) for your dev environment if you haven't; it'll make debugging your code a lot easier.  
  > **username_2**: @username_1 The issue is that `{% if entry.attributeThatDoesntExist is defined %}` will always evaluate to `true` (you can test this with `{{ dump(entry.attributeThatDoesntExist is defined) }}`). I don't know exactly _why_ it this is, and I admit it seems less than logical/intuitive, but the gist is that whenever an attribute may or may not exist, you have to use brackets notation to test for it before attempting to access the attribute using dot notation.  
  
  ---
  
  ### Answer by username_3 on 2016-02-19. Score: 3
  
  How about a conditional to check the entry.type rather than the field? Perhaps more appropriate in this case rather than checking if the field is defined. Something like this:
  
  ```
  {% if entry.type.handle == 'events' %}
      {{ entry.eventLevel }}
  {% else %}
      Activity
  {% endif %}
  
  ```
  
  Alternatively, check the section rather than the entry type with `entry.section.handle` instead of `entry.type.handle`.
  
  > **Comments:**
  > **username_0**: I'm not sure what you mean, by check the entry.type. Plus if it's an event it must have a level set, can't be empty.  
  > **username_3**: @username_0 I’ve just edited the answer to include an example.  
  > **username_1**: @username_3 I think he's confused because he's getting the entries from multiple sections. Your answer probably works anyways, because there's a good chance he's got this set up with different entry type handles.  
  > **username_3**: @username_1 good point. username_0, you could also check against the entry.section rather than the entry type if that makes more sense.  
  > **username_0**: Yes, I changed it to section and that works. But I would never have found that solution from the docs. Why do I need to check the section first?  
  > **username_1**: You check for the entry's section and conditional on that either output the field value or something else. The code simply expresses what you are askin for, @username_0...  
  
  ---
  
  