<p>As you already found out, the <code>loop.index</code> counter increments for each iteration of the loop, not only if you use or print it within your conditional. The best solution to work against it is to get rid of that conditional.</p>

<p>In this case it is in fact possible to catch only those entries you are after, making the conditional redundent</p>

<pre><code>{% for entry in craft.entries.section('gigs').datum('&lt; ' ~ present) %}
    &lt;h2 class="{{ cycle(['odd','even'], loop.index0) }}"&gt;{{ entry.title }&lt;/h2&gt;
{% endfor %}
</code></pre>

<p>if it wasn't, you could have done your own counter that increments within the conditional.</p>

<pre><code>{% set index = 0 %}
{% for entry in craft.entries.section('gigs') %}
    {% if entry.datum &lt; present %}
        {% set index = index + 1 %}
        &lt;h2 class="{{ cycle(['odd','even'], index) }}"&gt;{{ entry.title }&lt;/h2&gt;
    {% endif %}
{% endfor %}
</code></pre>

CC BY-SA 3.0
2015-02-12T13:55:42.863Z
2015-02-12T14:05:05.157Z
2015-02-12T14:05:05.157Z
carlcs
<p>I have this code:</p>

<pre><code>{% for entry in craft.entries.section('gigs') %}
    &lt;h2 class="{{ cycle(['odd','even'], loop.index0) }}"&gt;{{ entry.title }}&lt;/h2&gt;
{% endfor %}
</code></pre>

<p>This returns the same cycles for the last two entries like so:</p>

<pre><code>&lt;h2 class="odd"&gt;Title 1&lt;/h2&gt;
&lt;h2 class="even"&gt;Title 2&lt;/h2&gt;
&lt;h2 class="odd"&gt;Title 3&lt;/h2&gt;
&lt;h2 class="even"&gt;Title 4&lt;/h2&gt;
&lt;h2 class="odd"&gt;Title 5&lt;/h2&gt;
&lt;h2 class="odd"&gt;Title 6&lt;/h2&gt;
</code></pre>

<p>No matter how many entries, the last two entries have always the same class. Why is that?</p>

<p>Edit: Okay, I figured the problem. It's not a bug:</p>

<p>I filter the entries by date:</p>

<pre><code>{% set present = now|date_modify("-1 day") %}
{% for entry in craft.entries.section('gigs') %}
   {% if entry.datum &lt; present %}
       &lt;h2 class="{{ cycle(['odd','even'], loop.index0) }}"&gt;{{ entry.title }&lt;/h2&gt;
    {% endif %}
 {% endfor %}    
</code></pre>

<p>so the cycle filter works, but since some entries are filtered the odd/even schema doesn't work any longer. I guess I have to filter the entries first and then apply the cycle filter. But how would I have to write do that?</p>

CC BY-SA 3.0
2015-02-08T14:23:46.943Z
That is odd (see what I did there?). No, jokes aside, I'm not seeing this behavior when using the exact same code you're using. I suspect this is a bug that should be sent to P&T support.
André Elvan
CC BY-SA 3.0
2015-02-08T16:55:17.613Z
Works fine here as well. Have you tried printing the index  `{{ loop.index0 }}` — I believe that is what determines which value is ultimately used.
Douglas McDonald
CC BY-SA 3.0
2015-02-08T18:27:17.547Z
We're not doing anything on top of Twig's [cycle](http://twig.sensiolabs.org/doc/functions/cycle.html) implementation. Maybe there is some additional template code affecting it that you didn't share?
Brad Bell
<templating><cycle>
Cycle tag - last cycle returns same cycle
# Cycle tag - last cycle returns same cycle

(Asked by: username_0 on 2015-02-08)

I have this code:
{% for entry in craft.entries.section('gigs') %}
    {{ entry.title }}
{% endfor %}

This returns the same cycles for the last two entries like so:
Title 1
Title 2
Title 3
Title 4
Title 5
Title 6

No matter how many entries, the last two entries have always the same class. Why is that?
Edit: Okay, I figured the problem. It's not a bug:
I filter the entries by date:
{% set present = now|date_modify("-1 day") %}
{% for entry in craft.entries.section('gigs') %}
   {% if entry.datum < present %}
       {{ entry.title }
    {% endif %}
 {% endfor %}    

so the cycle filter works, but since some entries are filtered the odd/even schema doesn't work any longer. I guess I have to filter the entries first and then apply the cycle filter. But how would I have to write do that?

**Tags:** templating, cycle
> **Comments:**
> **username_1**: That is odd (see what I did there?). No, jokes aside, I'm not seeing this behavior when using the exact same code you're using. I suspect this is a bug that should be sent to P&T support.  
> **username_2**: Works fine here as well. Have you tried printing the index  `{{ loop.index0 }}` — I believe that is what determines which value is ultimately used.  
> **username_3**: We're not doing anything on top of Twig's [cycle](http://twig.sensiolabs.org/doc/functions/cycle.html) implementation. Maybe there is some additional template code affecting it that you didn't share?  

---

## 1 answers

### Answer by username_4 on 2015-02-12. Score: 3 | Accepted answer

As you already found out, the loop.index counter increments for each iteration of the loop, not only if you use or print it within your conditional. The best solution to work against it is to get rid of that conditional.
In this case it is in fact possible to catch only those entries you are after, making the conditional redundent
{% for entry in craft.entries.section('gigs').datum('< ' ~ present) %}
    {{ entry.title }
{% endfor %}

if it wasn't, you could have done your own counter that increments within the conditional.
{% set index = 0 %}
{% for entry in craft.entries.section('gigs') %}
    {% if entry.datum < present %}
        {% set index = index + 1 %}
        {{ entry.title }
    {% endif %}
{% endfor %}


---

