Difference between quoted and unquoted comparison syntax

Question

In general, when comparing variables in templates, I use unquoted variable names. e.g.,

{if segment_3 == category_url_title}

If comparing to an actual value (not a variable), I quote the value. e.g.,

{if count == "1"}

But in some cases (within a Matrix or Playa field, for instance), the comparisons only work if you quote the parsed variable. e.g.,

{if "{row_count}" == "{total_rows}"}

So my questions is - why is this? Does it have to do with strings containing spaces vs those that are space-free (like segment variables, integers, and booleans)? Often it just seems random, which I don't like.

I've also read that there is a performance hit when comparing using quoted vs unquoted syntax. Any truth to this?

Answer 1

As I have noticed a lot, you mainly have to use quoted values when working with third party modules/plugins.

I believe it has something to with the fact that not all developers call the prep_conditionals method in their code, so the values are parsed by the method that also replaces the normal tags in your template (not in conditionals).

If you look at the prep_conditionals-method it internally adds the quotes around values and != false when using a boolean check (no 2nd part in your conditional) before the template parser is called.

So I generally use the 'clean' version when working with EE native values, but add quotes when working with third party values.

– Wouter

Answer 2

Using quotes makes it an advanced conditional which has a different parse order than simple conditionals.

This is a simple conditional.

{if segment_2 == "category"}

While this is parsed as an advanced conditional.

{if "{segment_2}" == "category"}

I think that explains why you have to put quotes around the P&T variables. Basic conditionals are parsed before module and plugin tags, so the value of {total_rows} won't be determined in time.

Advanced conditionals are parsed after module and plugin tags, so by then you'll know the value of {total_rows}.

More on conditionals here.

Here is more on parse order from the parse order master.

Answer 3

Here is a FAQ on it - from the Wayback machine:

http://web.archive.org/web/20101020213825/http://expressionengine.com/forums/viewthread/130537/

I link to it because there is a security factor when you have quoted and braced conditionals:

5) Are you comparing a quoted variable to a value? This is not supported and depending on the source of the variable, may even have security implications. By doing this, you are allowing the tag that “owns” that variable to parse and replace it with its unfiltered contents. Doing so is trusting that it has no bad characters, no javascript, and no need for error checking that is normally performed when the conditional is used with the proper syntax outline above. Unsupported, possible security risk: {if "{custom_field}" == "foo"}

So you want to be really careful with that syntax any time you have user input information (ie: segments!)

-Lisa Wess
Pixel & Tonic

Answer 4

When you put quotes around a variable/tag, the template parser first needs to parse the variables and then it will execute the conditional.

Module tags/variables (what do we call them these days?) always have to be done with quotes since the template parser first needs to parse the variable/tag to find out it's value.

This will force the conditional to be parsed at a later stage in the parse order. Otherwise known as: Advanced Conditionals

Answer 5

This is simply to do with parsing in my understanding. putting quotes around it seems to make a difference (from recollection during my days doing P&T Support) - however, I don't pretend to understand why.

Answer 6

My way: always single quoted!

{if '{my_variabile}' == '1'}

{if '{segment_3}' == '{category_url_title}' }

{if '{count}' == '{1}'}

It' about EE parsing order.

Answer 7

Interesting points. I'm not too sure on the reasoning behind it, but I personally take the stance that when comparing strings you should use quotation marks (as with PHP) and checking numerical or Boolean data should be without.

I wonder if this has anything to do with the parse order? Another possibility could be that these 'basic' data types have been developed so they automatically wrap a quotation mark when used in this context where as the Pixel & Tonic ones haven't been written in this way.

That's a stretch!