Smarty

[ovnn]

The smarty if Block {if isset($smarty.section.listing.index) && isset($liste[$smarty.section.listing.index].inserats_type)}

throws
Fatal error: Cannot use isset() on the result of an expression (you can use "null !== expression" instead) in .... on line 164

if i remove the first isset statement, its work fine. With the second and only the first statement it return the error above

With smarty 3.1.19 it works fine with smarty 3.1.29 throws in the error above.

Best regards
ovnn

[AnrDaemon]

You shouldn't have used it like that in first place.
There's next to no reason to access $smarty variable from template.
What the hell you are trying to do with it?

[ovnn]

i check outside of the section "listing" if the Section "listing" was used

if yes the second checks if the array element with the index val exist

[AnrDaemon]

I have an urge to insert facepalm.
Assign a flag variable inside your section.
And check for it rather than rely on engine internals, which can change radically between versions.

But if you want a real solution, then rethink your templates from the ground up to never ever need to perform the checks of this kind.

[ovnn]

its not really possible to redesign. i write above, i check if section is used this is not right. I check outside the section and the if block whether the section array exist and has one or more indexes. The if Block on my first post, checks again and after that it checks another index. Now i have write it to a extra Var and it works.

The intention on the construct on first post was to use less variables and Save ram.

it was inspired by the smarty doc example
7.76. total property example
{section name=customer loop=$custid step=2}
{$smarty.section.customer.index} id: {$custid[customer]}<br />
{/section}
There are {$smarty.section.customer.total} customers shown above.

[AnrDaemon]

You want to use whole kilobyte of code to save 8 bytes of RAM on a flag variable, I got it right?

[ovnn]

sure, 8 byte for this user and 8 bytes for other user. Its a high traffic page with many simultan page impressions. The smarty template code is not new, is a old code build some years ago.

At Build it works fine without an extra var and i saw no need to not use the $smarty.section.listing.index

[AnrDaemon]

Now, use profiler and compare your template execution times.

[U.Tews]

Because of some internal changes some of the $smarty special variables are no longer real variables and their values are obtained by internal function calls. Some of the php function like isset() or empty() can not handle this.
This problem will be addressed in the next release.

However in your example the call of isset($smarty.section.listing.index) is not needed and isset($liste[$smarty.section.listing.index].inserats_type) will do the job.

And it will save execution time LOL.

[U.Tews]

This is now fixed on github in teh master branch and will latr be included in 3.1.31

[eth8505]

We just update smarty to 3.1.31 (from 3.1.29) and some of our templates broke rather badly due to this change, as the bahaviour of if-statements changes.

We have a list of attributable elements, with has() and get() methods, where the get() method throws an exception if the attribute does not exist.

[Aristophan]

What happens if you change
https://github.com/smarty-php/smarty/blob/master/libs/sysplugins/smarty_internal_templatecompilerbase.php#L791

to your needs, eg

[eth8505]

I could do lots of things and build special cases, but it doesn't feel right, as what smarty does here is break the way if statements are supposed to be processed in any language.

If statements are processed from left to right. If you have chained or conditions, the first true condition will result in the rest of the conditions not being executed, as we already have a true result due to the or.
What smarty does here is simply wrong, as the order of the conditions is changed.

[Aristophan]

That was just a quick help. Nothing objected.
It just seemed to be "somehow" necessary to not allow things like "('".
(It looks like because of function property handling.)
I think the processing order of "isset() OR empty()" is still valid, but code must be read and this is why you are redirected. It assumes there is a function property in your code part.
So you could as well try with

[eth8505]

I see. I'll have to stick to 3.1.29 then, as that's the last one working properly for me.