Thread

I’m using {count} inside {exp:channel:entries} within a single channel entry loop. The problem is {count} does not seem to work when {exp:channel:categories} is used inside of a single channel entry loop. Outside of a single entry or even in a non-single channel entries loop, it works just fine. Here’s an example:

{exp:channel:entries channel="my_channel" entry_id="1" limit="1"}
    {exp:channel:categories group_id="1"}
        {count}: {category_name}
    {/exp:channel:categories}

    {!-- this doesn't work either --}
    <ul>
    {categories}
    <li>{count}: {category_name}</li>
    {/categories}
    </ul> 
{/exp:channel:entries}

The above would output something like the following on both accounts:

1: category 1
1: category 2
1: category 3
And so on…

Is this a known limitation such as {exp:channel:next_entry} not working correctly inside of a channel entries loop? I don’t see any mention of it in the docs. Or, is this a bug that should be reported?

it doesn’t seem a bug. both exp:channel:entries and exp:channel:categories tags have {count} variable. it would be better to embed categories tag into another template like:

{embed="temp_grp/tmp_name" entry_count="{count}"}

Thanks for the advice, Bhashkar. It’s my understanding, however, that embeds would add an undesirable overhead. Especially, when getting called in a category loop. For example, that embed would get called for every category in the loop. Also, while I’ve not tried your solution yet, I’m not sure you can accurately supply the count variable to the embed if it’s not working correctly in the first place. As it states above, the code example works fine in a normal {exp:channel:entries} loop. The {count} only breaks (showing 1 for every iteration) when it’s inside a single entry loop. Moving the code outside of that loop does seem to fix the problem, which is why it appears to be a bug.

Hi kylemade,

yes, i understand. it will create more overhead. i advised this to overcome the ambiguity of {count} tag.

another way is to use Categories add-on. its nice add-one to display the categories. Could you please give it a try.
i hope, it will fix your issue.

Best Regards,

I just made a quick demo using an embed as you suggested and had the same results (“1” for every iteration). Here’s the code:

{!-- site/my_template --}
{exp:channel:entries channel="my_channel" entry_id="1" limit="1"}
    {exp:channel:categories group_id="1"}
        {embed="_embeds/.my_hidden_template" entry_count="{count}"}: {category_name}
    {/exp:channel:categories} 
{/exp:channel:entries} 

{!-- _embeds/.my_hidden_template --}
{embed:entry_count}

Also, thanks for the link, but my question was not posed to find a solution. I’m actually using a homemade plugin that solves this (among other things). I’m simply asking if this is a bug or a known limitation (e.g. do I submit a bug report or a feature request)? Given my results, I’m inclined to think it’s a bug. What do you think?

Hi Kylemade,

I think, it’s not a bug. it may be a known limitation. You can see same thing while nesting a channel entries tags({exp:channel:entries}). there are few other cases also like that.

Best Regards,

With respect to parsing a single result row, I came across this in the docs today:

Parsing a Single Result Row

You can still benefit from the simplified variable parsing by using parse_variables_row(), though you will no longer automatically have {count}, {total_results}, or {switch=} variables. To include these variables when parsing your own result rows, you will need to add them yourself.

This leads me to believe that {count} and {switch=} were not enabled for the above scenarios. It should be simple enough to right this, so I will be submitting a feature request shortly.

ok fine.

Why you are using 2 accounts to post the replies?

I figured someone might be wondering that. I started using “kylemade” today for better transparency / accountability in the forums. I meant to post the last comment from my new account, but realized only after the fact that I was logged into my employer’s account, “elative.” Alas, time travel is not possible, so I’ll be more wary of the submit button next time 😉