Difference between quoted and unquoted comparison syntax

27

6

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?

Derek Hogue

Posted 2012-11-15T19:58:34.187

Reputation: 17 344

Derek, was there a correct answer to this question posted? – Anna_MediaGirl – 2012-12-12T05:12:11.513

Anna - unfortunately there was not! Still no definitive answer from anyone that bears out in testing. – Derek Hogue – 2012-12-12T14:42:48.173

Answers

13

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

Wouter Vervloet

Posted 2012-11-15T19:58:34.187

Reputation: 479

1This makes the most sense to me, and bears out in practice as well. Thanks. – Derek Hogue – 2012-12-13T17:53:19.663

21

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.

Jason Siffring

Posted 2012-11-15T19:58:34.187

Reputation: 493

4Hmm, but in a Channel Entries tag, {if count == total_results} works just fine. And in my own custom plugins and modules, I can always check my custom variable data unquoted without issue. – Derek Hogue – 2012-11-15T20:47:00.350

Nice answer! How do we then avoid the performance hit they say comes along with advanced conditionals in this case? Care to update your answer? – Natetronn – 2012-11-15T20:17:51.487

6

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

Lisa

Posted 2012-11-15T19:58:34.187

Reputation: 2 511

Thanks Lisa. Maybe you can answer this - do P&T add-ons use EE's $this->EE->TMPL->parse_variables() or $this->EE->functions->prep_conditionals() methods? Or do they use a custom method? It's most often P&T add-ons where I find that unquoted variables comparison falls down. – Derek Hogue – 2012-12-12T18:50:17.467

Hey Derek --

I haven't checked every add-on, but Matrix uses prep_conditionals - had to check by finding in Project as I wasn't actually sure myself.

The P&T add-ons (and several others) parse some pretty complicated data, and I suspect that is why you find you have to quote and brace variables. With that said, I am not a programmer - so I'll need to check in with Brandon on more specifics. :)

-Lisa – Lisa – 2012-12-13T22:24:11.510

Hey Derek - it turns out that EE 2.5.3 got a lot more strict on conditionals for no clear reason. We haven't yet gone through the EE template parser to figure out what is going on there. -Lisa – Lisa – 2012-12-13T23:01:50.013

5

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

Victor Gutierrez

Posted 2012-11-15T19:58:34.187

Reputation: 363

See my comment here on how this doesn't ring true in my experience. – Derek Hogue – 2012-11-15T21:37:59.473

2

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.

madebyhippo

Posted 2012-11-15T19:58:34.187

Reputation: 1 831

1

My way: always single quoted!

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

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

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

It' about EE parsing order.

Filippo Salza

Posted 2012-11-15T19:58:34.187

Reputation: 136

0

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!

Mutual

Posted 2012-11-15T19:58:34.187

Reputation: 1 304