Raise your hand if you knew this one: wrapping a variable in curly brackets will negate an otherwise perfectly legitimate-looking Simple Conditional.

I sure hope I'm not the only one raising my hand.

Yes, Simple Conditionals are more than just about their lack of logical operators (e.g. no AND, OR), lack of control structures (e.g. no ELSE, ELSEIF), or type of variable (e.g. must be a segment, embed, or global variable).  To pass the mustard to be considered a "Simple" conditional, it also must follow a few syntax rules as well.

 

No writing about EE's Parse Order is complete without a knowledge bomb from @low.

@kristengrote Because of line 3197 of Template.php in EE2.6.1, but I guess that’s not what you want to hear. #eecms

— Lodewijk Schutte (@low) June 6, 2013

 

It's especially awesome to notice that EE's own docs describing what a Simple Conditional is, actually isn't - "username" is not an early-parsed variable. @low pointed out that one as well.

If you're like me you may be surprised by this, because it is not explicitly mentioned in EE's documentation. But if you read between the lines (as well as through the comments), you'll see the syntax rules emerge, which are:

• the left-hand side of the condition MUST be either a segment, embed, or global variable
• the right-hand side of the condition MUST be a string (at least at the time that the condition is evaluated)
• the left-hand variable MUST NOT have curly brackets and/or quotes around it

So what is a Simple Conditional

First, let's see what is a Simple Conditional. Here, we are comparing a segment variable against a string:

{if segment_1 == "blog"}
	<h1>Blog!</h1>
{/if}

What isn't a Simple Conditional

Wrapping your variable in curly brackets:

{if {segment_2} == "blog"}
	...
{/if}

Wrapping your variable in curly brackets and quotes:

{if "{segment_1}" == "blog"}
	...
{/if}

Flipping the placement of your variable and the string you are comparing:

{if "blog" == segment_1}
	...
{/if}

Ommitting the quotes around the string just because it's an integer:

{if embed:number < 5}
	...
{/if}

Placing an Advanced Conditional within a Simple Conditional:

{if segment_1 != ""}	
	{exp:class:method}
		{if var == "foo"}
			Lorem
		{if:else}
			Ipsum
		{/if}
	{/exp:class:method}
{/if}

Courtesy of @low with a genius solution: https://gist.github.com/low/1391783

Bonus 1: Comparing 2 early-parsed variables (possible)

Have you ever wanted to compare 2 early-parsed variables? It's possible, but again, syntax matters.  Keeping the above rules in mind, the trick is to get EE to parse the right-hand variable into a string prior to the Simple Conditional stage of the parse order. Like so:

{if segment_1 == "{embed:segment}"}
	...
{/if}

Bonus 2: Comparing a non-existent variable (not possible...ish)

Let's say you're using Rob Sanchez's awesome Mo' Variables extension to create an early-parsed variable for a browser cookie named "hometown". If that cookie matches the string value "richmond", you want to run a special query just for those visitors. You'd probably write something like:

{if cookie:hometown == "richmond"}
	{exp:channel:entries channel="howdyneighbor"}
		...
	{/exp:channel:entries}
{/if}

If the cookie "hometown" exists (regardless of value, including an empty string), then this conditional would in fact be Simple. However if the cookie did not yet exist, the above would in fact fail as a Simple Conditional.

So how might we construct a Simple Conditional to successfully run against a non-existent variable? Refer to what we learned above: by "casting" the non-existent variable to a string, and comparing it to an existing variable:

{!-- Where 'lv_hometown_default' is an early parsed Low Variable with a value of "richmond" --}
{if lv_hometown_default == "{cookie:hometown}"}
	...
{/if}

Of course if your code fails as a Simple Conditional, it will be fine as an Advanced Conditional, and there's nothing necessarily wrong with your code!  Sometimes though when you're looking to squeeze out performance gains, the difference matters.  Or, and this is more relevant to recent work of our own, if you're conditionally setting a Preload Replace variable, then it's of vital importance.

Either way, these nuances of EE's parsing engine are important to master. As always I welcome feedback, correction, and illumination.