26

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, was there a correct answer to this question posted? – Anna_MediaGirl Dec 12 '12 at 5:12
  • Anna - unfortunately there was not! Still no definitive answer from anyone that bears out in testing. – Derek Hogue Dec 12 '12 at 14:42
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

| improve this answer | |
  • 1
    This makes the most sense to me, and bears out in practice as well. Thanks. – Derek Hogue Dec 13 '12 at 17:53
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.

| improve this answer | |
  • 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 Nov 15 '12 at 20:17
  • 4
    Hmm, 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 Nov 15 '12 at 20:47
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

| improve this answer | |
  • 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 Dec 12 '12 at 18:50
  • 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 Dec 13 '12 at 22:24
  • 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 Dec 13 '12 at 23:01
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

| improve this answer | |
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.

| improve this answer | |
1

My way: always single quoted!

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

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

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

It' about EE parsing order.

| improve this answer | |
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!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.