template rendering doesn't reset cycle tag

In #5908 Malcolm talks about the importance of keeping the state of the internal counter. Currently, the {% for %} tag (and potentially others) sets up a local context for each iteration, so if we put the counter straight on the context, it'll be lost the next iteration.

I think Context needs a way to set a "global" context variable (if you understand the internals, probably just stuffing it at the highest level context).

There's a workaround for this which can be used in templates:

Using the 'cycle as' syntax resets the variable. By outputting the 'cycle as' inside a comment it hides it from the rendering. It's not perfect, but it works in most cases

<!--{% cycle 'rowB' 'rowA' as rowstyle %}-->
{% for post in posts %}
        <tr class="{% cycle rowstyle %}">
        ...
{% endfor %}

Replying to harryman100: Scrap that, it was fluke that it worked with a particular dataset

Milestone post-1.0 deleted

#11290 reported this again.

I came across this a few times when rendering multiple tables next to each other with the same cycle (with 2 arguments for colouring) on a row. A double loop. If a table had an even amount of rows, the colours matched, otherwise, a grid appeared. It came out ugly sometimes, but acceptable.

Looking for a quick fix, I suspected there must be a reset of some sort, but there is not.

The {% cycle [] as var %} could be a nice way to fix this. But for starters, the output of {% cycle [] as var %} should go away. "as var" in other tags denotes a variable for later use. If we can reference the cycle-variable on the node, we could make a {% cycle reset var %} of some sort, which would reset the cycle referenced.

The attached patch fixes the issue and passes the test attached to #11290.

The test and fix are attached in the same patch here for completeness.

Fixes cycle reset issue by adding reset feature to node.

This would be fixed by #6262 - and I consider the ticket there to contain the correct fix to this issue.

Resolved by [11862]