Skip to content
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

3.1.31 potentially breaks if statement order #347

Closed
eth8505 opened this issue Mar 20, 2017 · 1 comment
Closed

3.1.31 potentially breaks if statement order #347

eth8505 opened this issue Mar 20, 2017 · 1 comment

Comments

@eth8505
Copy link

eth8505 commented Mar 20, 2017

As described on the forums here: http://www.smarty.net/forums/viewtopic.php?p=92056#92056 the bugfix applied here b8acd7e potentially breaks the processing order of if statements.

Let me re-describe:

Assuming I have a class with a has($key) and a get($key) method, where the get() method throws an exception if $key does not exist in the internal stack. If I then build the following if statement with smarty, the get() exception will be triggered with 3.1.31, but not with 3.1.30 or 3.1.29.

{if !$stack->has('mykey') || empty($stack->get('mykey')}
{/if}

The variable prefixing done by the php function parser for empty() function calls will convert the statement into

<?php $_prefixVariable1=$_smarty_tpl->tpl_vars['stack']->value->get('mykey');
if ($_smarty_tpl->tpl_vars['element_current']->value->has('mykey') && !empty($_prefixVariable1)) {?>

Which totally breaks the original handling of if statements, as the empty() call would never have to be executed if the key does not exist.

uwetews added a commit that referenced this issue Apr 17, 2017
@uwetews uwetews closed this as completed Apr 17, 2017
uwetews added a commit that referenced this issue Apr 17, 2017
…PHP behaviour since PHP 5.5

    #347 (reverted from commit cfd8bf3)
@uwetews uwetews reopened this Apr 17, 2017
uwetews added a commit that referenced this issue Apr 17, 2017
@uwetews
Copy link
Contributor

uwetews commented Apr 17, 2017

The fix is now in the master branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants