PHP_EOL error when using expressions in {{ }}

[SylwesterZarebski]

I have a problem with newest 3.6.2 version which changed building template's lines.
With this version all lines get PHP_EOL on end which bring error in lines like:

{{ @cart->get_item(@item->item_id) != null ? @cart->get_item(@item->item_id)->order_element_amount : 0 }}

Compiled line is:

<?= $cart->get_item($item->item_id) != null ? $cart->get_item($item->item_id)->order_element_amount : 0.PHP_EOL ?>

And error is:
Fatal error: syntax error, unexpected 'PHP_EOL' (T_STRING), expecting ',' or ';'

I have added temporary parentheses around expression, but i should not do that.

Problem looks like is effect of fix: f3-factory/fatfree-core#205

Besides, You should not add artificial EOLs, and consider removing PHP_EOL, because:
a) EOLs are unwelcomed in some situations - like TEXTAREA
b) it is inconsistent with PHP, which do not output EOLs after ?>
c) it should be user responsible to generate proper template

PS. Could it be framework configuration for adding or not EOLs?

[ikkez]

The EOL is only added when you have a newline after your expression. i.e. like

<textarea>
{{@text}}
</textarea>

instead of <textarea>{{@text}}</textarea>. There reason why it's added manually is because php does consume the newline after ?> which produces other issues. We could probably replace it by (PHP_EOL)?

[SylwesterZarebski]

Yes, but it is expected that {{ }} is working the same as <?php and ?> which consumes newline.
Otherwise is not expected and is a breaking compatibility between 3.6.2 and previous versions.

You could add <?= PHP_EOL ?> to avoid wrong cases (like above). Then compiled code should look like:

<?= $cart->get_item($item->item_id) != null ? $cart->get_item($item->item_id)->order_element_amount : 0 ?><?= PHP_EOL ?>

But i propose to add new configuration option to avoid incompatibility between versions.

Edit: After some thoughts i think adding PHP_EOL is wrong, because template file could use non standard EOL like CRLF on Linux hosts. It could fix some very basic case, but is not good general way of fixing problem.

[ikkez]

fixed in f3-factory/fatfree-core@d5fb7fc
PHP_EOL already contains the platform specific new line character(s), so there's nothing to fix at this point.

[SylwesterZarebski]

No, it is not fixed. Adding PHP_EOL (LF) on Linux host mangle files which has Windows EOLs (CRLF), which is required for many file types. Fix of: f3-factory/fatfree-core#205 just created another class of problems.

But it could be this way if anyone could disable this functionality by setting core variable, which now is not possible. Changing critical core internals without giving compatibility options to set them back is very bad way to develop software. It's my 2 cents...

[ikkez]

Don't get me wrong, but the PHP_EOL is only added once in template complilation and only in case we need to mitigate the new-line consumption by ?>, as is would break your template otherwise. If there is more whitespace instead, it'll put it down into the template just as it is right here: https://github.com/bcosca/fatfree-core/blob/d5fb7fc33ddcc91ed81314170b4b1c99dec8311d/base.php#L2834-L2835
That means that your CRLF, LF, or CR new endings are kept as they are. And it won't add them if there wasn't any. I checked it all once more, even with textarea and couldn't find an issue.
Your initial issue with expressions ending with numerics was valid and solved. If you however found another issue, please reopen or create a new issue.

[SylwesterZarebski]

It is not inserting EOLs in PHP template, but in result file, and i'm using templating not only for sending to browser, but many more like generating company internal XMLs and prepared SMTP commands (which both requires CRLFs and i'm on Linux host).

[ikkez]

Alright, the lastest commit doesn't use PHP_EOL anymore.

[SylwesterZarebski]

Dear Christian :).
Thanks, but my only complain is could You make this functionality configurable? It will be a win-win situation then, because some user could find Your changes useful, just not me.

[ikkez]

Thanks for criticizing all of my changes. I'm just trying to understand your point, since I do not think that a config option would be useful for anyone, but you (maybe).

The point is that when you i.e. render a config file like this (or SMTP command sheet, etc)

[usercfg]
var1 = {{ @var1 }}
var2 = {{ @var2 }}
var3 = {{ @var1 }}
var4 = {{ @var2 }}

the result with your proposed option turned OFF would be:

[usercfg]
var1 = <?= ($var1) ?>
var2 = <?= ($var2) ?>
var3 = <?= ($var1) ?>
var4 = <?= ($var2) ?>

It seems to me that this is what you want, right? In fact, when you require() this file (to resolve the variables), it becomes var1 = text1var2 = text2var3 = text1var4 = text2. Now tell me why this is useful to you and why this requires a config method?!

[SylwesterZarebski]

First, I apologize, if i was being rude.

What You have written is what i expect - it is well known PHP behaviour (bad or good - not worth to discuss about it) and fighting with by solving one problem, it brings more problems to solve then.

Of course You and many more can find this functionality useful.

[ikkez]

Here's a suggestion for a config option for this behaviour, f3-factory/fatfree-core#223

[SylwesterZarebski]

Thanks a lot. I appreciate Your effort :).

[xfra35]

Thanks @ikkez for digging into this and bringing the appropriate fixes.

@SylwesterZarebski can you please give a short code example where disabling the "interpolation" behaviour would be useful? I just can't figure it out.

[SylwesterZarebski]

The need for 'option' is compatibility:

1. Compatibility with previous framework's versions
2. Compatibility with PHP

I.e. i have a template which has CRLFs which is converted from plain PHP and now looks like this:

title1: {{ @var1 }}CRLF
CRLF
title2: {{ @var2 }}CRLF
CRLF

year ago it looks almost the same:

title1: <?php print ($var1); ?>CRLF
CRLF
title2: <?php print ($var2); ?>CRLF
CRLF

It works in previous framework versions. Now with internal framework changes i should convert all the templates to remove additional CRLF. When i want to go back to plain PHP i need to add these CRLFs once more.

PS. In general, i think the problem is why that serious change sneak into release version, when should not, because it fundamentally changes how templates works. I'm not expecting that kind of changes in bugfix/release line of development (3.6.x vs 3.7.x vs 4.0.x and so on), because i'm expecting, when i regularly change framework to new version in the same line, nothing breaks (modulo bugs of course).

[xfra35]

Ok. I just understood how PHP ending tags swallow EOLs. For some reason, I didn't suspect it was that bad.

So if we have:

title1: <?= $myvar ?>
#
title2: <?= $myvar ?>
#

PHP renders (with $myvar='foo'):

title1: foo#
title2: foo#

Now testing a similar F3 template:

title1: {{ @myvar }}
#
title2: {{ @myvar }}
#

F3 3.6.1 rendered the template like PHP does:

title1: foo#
title2: foo#

while F3 3.6.2 "fixes" that weird behaviour:

title1: foo
#
title2: foo
#

I like the way 3.6.2 renders templates without swallowing EOLs (like I would expect PHP to do). But I also understand that some devs may have reasons to stick to PHP rendering logic.

So 👍 for f3-factory/fatfree-core#223

[xfra35]

@SylwesterZarebski you wrote:

i'm expecting, when i regularly change framework to new version in the same line, nothing breaks

We all expect the same. The thing is that nobody suspected the backwards compatibility break when fixing f3-factory/fatfree-core#205.

[SylwesterZarebski]

Thanks a lot for understanding. I really appreciate Your effort.