Conditional with value "0" or 0 evaluates to true
Developer Preview
The context here is I’m setting a global variable via $assign_to_config as 0, and then using that global variable in a template conditional.
Simplest way to reproduce this.
Add this to index.php
$assign_to_config['global_vars'] = array('foo' => 0);Sample template:
{if foo}Foo != 0{/if}Expected output: nothing Actual output: Foo != 0
I don’t know if this is isolated to global variables, but I suspect not.
Pre 2.9 falsy conditionals like this worked as you’d expect. This behavior is different.
Pre 2.9 falsy conditionals like this worked as you’d expect.
Yes and no. Your example is indeed broken and should evaluate to false, but your title mentions ‘0’, which is the special cookie.
For the value check without comparison “{if var}”, a value of 0 or ‘0’ was treated differently by advanced conditionals and simple conditionals.
- Advanced conditionals evaluated like PHP, where both 0 and ‘0’ are false.
- Simple conditionals evaluated like JavaScript and Python, where 0 is false and ‘0’ is true!
So which one makes more sense? Well, I don’t know! When you’re checking if an entry field has data (which means you’re dealing with strings), then I would say 2) makes more sense. It has content, it just happens to be the number 0. But do we break more sites by breaking the advanced or simple case? They can’t both stay.
Just so I’m clear–0, the integer, should evaluate to false and since it currently doesn’t, that’s a bug, right?
And regarding which falsy behavior makes more sense: my vote goes for the way PHP handles it. Not because it inherently makes more sense, but because this is, after all, a PHP-based framework. As a developer my expectation it works the way the underlying language does. And this does not break backwards compatibility.
I definitely see your point about custom fields. I can see the case where you’d have a text field (“Items sold – leave blank if this is not a sellable item”, or something like that) and want ‘0’ to be true.
Whatever you ultimately decide, this is the kind of thing that needs to explicitly be in the docs, both in the user guide’s add-on docs and the change log:
“NOTE: conditional variables whose value is 0 will be evaluated as false and those whose value is ‘0’ will be evaluated as true, as they do in languages such as Javascript or python.”
Just so I’m clear—0, the integer, *should* evaluate to false and since it currently doesn’t, that’s a bug, right?
Yes. The bug here was in variable values being cast to strings. We’re going to stop doing that.
As a developer my expectation it works the way the underlying language does.
I can definitely appreciate that from a developer standpoint. As we diverge more (the string operators and ^ power operator already do), the concern for us has to shift more towards the non-programmer who is writing templates. The reason is simple: we can explain strange behavior to a programmer much more accurately and succinctly than to someone who has no programming background. And picking the right defaults means less explaining to do. PHP does this for example:
3 == "3 little pigs" // trueThat’s just plain wrong! You can’t tell someone that’s true and not back it up with an explanation. On the other hand, saying it’s false is obvious. I don’t like dealing with my own type coercion, but I will if it means avoiding this kind of nonsense.
Whatever you ultimately decide, this is the kind of thing that needs to explicitly be in the docs, both in the user guide’s add-on docs and the change log
Agreed. We’ll have truth tables in the template docs and developer warnings in the dev docs.