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

In {foreach $recList as $key=>$item} , $item cannot show all keys (ex: {$item.sid}) #149

Closed
yourchoice opened this issue Jan 4, 2016 · 7 comments

Comments

@yourchoice
Copy link

I have an array associated from php to smarty tpl.

$recList have {$item.0|debug} :

Array
(
[feed_id] => 18124
[feed_ts] => 2014-04-16 10:02:59
[site_id] => 18052
[feed_truncate] => 0
[lang_iso] => fr
[feed_error] => XML KO
[sid] => 18052
)

In {foreach} any keys can be showed, except {$item.sid}, that show null even is not null.

@artcs
Copy link

artcs commented Jan 4, 2016

{$foo.sid} compiles to <?php echo $_smarty_tpl->tpl_vars['foo']->value[sid];?>
whereas {$foo.bar} compiles to <?php echo $_smarty_tpl->tpl_vars['foo']->value['bar'];?>
(Note the missing apostrophes around sid). Maybe it has to do something with the predefined SID from php sessions, which seems to be defined caseinsensitive.

Had this issue some time ago. You can work around it using{$item['sid']}, which compiles correct.

@yourchoice
Copy link
Author

Yes, I saw that {$item['sid']} working.

In my case {$item.sid} come from an {foreach}.

{foreach $recList as $key=>$item}
#{$item.sid}#{$item['sid']}#

{/foreach}
<<

I found a solution for my case,... idea is that these situations to be reviewed. Maybe exist and another predefined keys, even not understand how and why

@artcs
Copy link

artcs commented Jan 5, 2016

Yes, this should be reviewed. But the {foreach} part is not the culprit, it's a general bug when accessing tpl array vars with the dot syntax ({$item.$key}).
{$item[{$key}]} will work inside {foreach} even if $key is sid.

@uwetews
Copy link
Contributor

uwetews commented Jan 27, 2016

See #76

@artcs
Copy link

artcs commented Jan 27, 2016

I would expect, to access constants one has to use {$smarty.const.foo}. The way it works now, one has to watch out not to define anything that has the same name as an array member. Is it possible to switch this behaviour off via $php_handling or some other switch? I stopped using $array.foo altogether because of this feature/bug.

Consider this example:

define('foo', 'bar');
$foo = 'baz';
$arr = array('foo'=>'Foo','bar'=>'Bar', 'baz'=>'Baz');
$Smarty->assign('foo', $foo);
$Smarty->assign('arr', $arr);

Accessing {$foo} inside template correctly gives you baz while {$arr.foo} results in Bar which is confusing to me as I cannot always know what some other developer might have defined somewhere in the code.

uwetews added a commit that referenced this issue Feb 10, 2016
@uwetews
Copy link
Contributor

uwetews commented Feb 10, 2016

I removed the inline constant support from the $foo.bar array syntax.

The fix is in the master branch an will later be included in 3.1.30

@uwetews uwetews closed this as completed Feb 10, 2016
@artcs
Copy link

artcs commented Feb 10, 2016

Perfect. Thank you very much.

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

3 participants