Thread

Not sure if this is a bug or expected behaviour…

I have a situation where an entries tag is returning a set of results.  Within that entries loop a {query} tag is filtering the output of the entries tag, returning a smaller number of results.

If I use {switch} within that query tag it’s still counting results that are excluded by the query.

i.e.

{exp:channel:entries channel="mychannel"}
{exp:query sql="[query]"}
{switch="||x"}
{/exp:query}
{/exp:channel:entries}

If the results from the above *without the query tag* were:

One
Two
Three(x)
Four
Five
Six(x)

And let’s say the query tag eliminates “Three”, the desired result would be:

One
Two
Four(x)
Five
Six

However what you actually get is:

One
Two
Four
Five
Six(x)

Does that make any sense at all to anyone other than me? 😊

Cheers,
Steve.

Hi Steve,

I think that what is happening here is that because both the Channel Entries tag and also the SQL Query tag can both utilise the {switch} variable then the Channel Entries tag parsing is taking precedence here.

What you may be able to do to get around this it so use an embedded template which has your query in it and get around the switch problem in that way.

That said nesting a SQL query tag inside a Channel Entries tag like that could be pretty processor intensive depending on what you’re exactly doing there. Could you not just use a single SQL query to get what you need instead?

Best wishes,

Mark

Mark,

Never occurred to me of course that it’s simply an issue with the entries taking priority over the switch tag – you’ll be right with that I’m sure.

I could use a single query, but for various reasons this way was more straightforward at the time – I’ll maybe need to rethink that now.

Cheers for the reply!
S.

I could use a single query, but for various reasons this way was more straightforward at the time – I’ll maybe need to rethink that now.

Yep sometimes it’s best to completely forgo the Channel Entries tag if you start nesting it with other tags and just go with one single SQL query tag. Saves a lot of overhead that way.

Cheers for the reply!
S.

No problem at all. Hope you get it all sorted soon.

Best wishes,

Mark

Thanks Mark! Are you good to go, Steve?