-
Notifications
You must be signed in to change notification settings - Fork 704
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3.1.33 breaks {foreachelse} on foreach loops applied to objects #506
Comments
What about this approach: Smarty should not be responsible for information that the underlying structure isn't able to provide (e.g.: the size of an (forward) iterator). Thus, don't calculate the total count and do not provide the properties that depends on it, if The If that sounds reasonable, I can gladly provide a patch. |
Thank you for your response. The core of this issue for me is not so much in not having a total but rather in not executing a {foreachelse} branch - this breaks way too many things. Consequently, I think it'd be great if an empty foreach() execution could be caught and used as grounds for executing {foreachelse} - IMO this would address the core issue about without having to resort to counting. |
I think this could be fixed by addressing the way the output code is generated. |
That's exactly what the patch above does. |
Keep track of main loop using a do_else variable. Fixed #506
When fix for for #443 was provided, it disabled calculating $total when $from is an object. A line shortly further down sets $total to a value of 1, which further prevents $from from being set to null and triggering {foreachelse} inside the compiled template.
PoC:
On v3.1.32, it outputs the expected "No items". On v3.1.33, it outputs nothing.
It doesn't appear that there is an easy way to determine if an object is empty or not without doing the count(), thus invoking the Countable interface. It would appear that this optimization is inapplicable to objects in $from where {foreachelse} is used, unless total is explicitly requested via a property, which would require editing existing affected templates, breaking backwards compatibility.
The text was updated successfully, but these errors were encountered: