Blog

Parse Order and Low Variables

23 May 2012 4 comments

It’s been a while since my last blog post about parse order in ExpressionEngine, so I think it’s time for new one. I’d like to explain how you can use Low Variables to use the parse order to your advantage. Get your parse order cheat sheet ready and let’s go!

What is “parsing”?

In ExpressionEngine, parsing a template simply means replacing all markers in the template with the actual content. In this case, the markers consist of variables and tags. One by one, new content is put into the template for each marker, thus creating a new template after each replacement. The order in which the markers are replaced is called the parse order. I’ve explained this in my Parse Order Pro talk.

Early vs. Late

Low Variables lets you create global variables. By default, these are parsed (replaced) at the very end of the parse order (stage 9, if you’re checking my cheat sheet). However, you can choose to enable Early Parsing for each variable, effectively making it a Snippet. These are parsed at the very beginning of the parse order (stage 1).

For early parsed vars, Low Variables offers even more granular control. Each one is parsed in the order in which it appears in its group, allowing you to nest them. Just be careful you don’t end up in parse order limbo.

Variables vs. Tags

So, Low Variables are either parsed at stage 1 or 9, depending on whether early parsing is enabled. But wait, there’s more. You can also choose to use tags to parse the variables, and tags are always parsed at stage 5, no matter what the early parsing preference is.

Using tags will allow you to avoid nesting conflicts, as Jamie Pittock explains here. Some variable types require you to use the tag syntax, so extra processing can be done before replacing the marker with its content, like Matrix. Remember, tags can have parameters, global variables cannot.

Nesting

[cue Inception music] So, there are three stages at which a Low Variable can be parsed:

1. As early parsed global variables using the variable syntax (stage 1);
2. As tags, single or pair, using the tag syntax (stage 5);
3. As late parsed global variables (the default) using the variable syntax (stage 9).

Looking at these stages, you can always nest variables upwards: 2 in 1, 3 in 1, and 3 in 2. As noted before, you can also nest 1 in 1, but only if they are in the same group and in the right order. Theoretically, you can nest 2 in 2, but that might cause your brain to melt. Nesting 3 in 3 won’t necessarily break things, but it can lead to unexpected results. Nesting 1 in 2, 1 in 3, or 2 in 3 will never work.

Parse Order never gets old

There you go. Low Variables will give you unprecedented control over what is parsed when, so you can create efficient and elegant templates that scale.

• Tips and Tricks

Comments

1. Gareth 25 May 2012 at 14:32

   Hi Low
   I am trying to fully understand how the parse order works - not an easy thing but I am getting there (I think).

   I have your PDF http://loweblog.com/downloads/ee-parse-order.pdf as a great refernce.

   My question is - the PDF states that global variables are parsed first but then states that user global variables and others are parsed last. So how do you know which global variables are parsed first? Is there a list somewhere?

   Thanks in advance.

   Gareth

2. Lodewijk Schutte 25 May 2012 at 15:53

   Early parsed global variables are Snippets, Segment variables and Embed variables. In addition to that, any variables defined in your index.php or config.php are also parsed early.

   All other global variables are parsed late. See also the EE docs on global template variables.

3. David VanHook 19 January 2013 at 16:57

   Low: Great product!  I’ve discovered a tricky question about parse order I’ve run into.  This is an code base I’ve inherited, so I’m not sure how best to handle.  (My apologies in advance; I am neither an EE nor a LV expert.)  Any thoughts you have would be much appreciated.

   Template pseudocode:

   {if segment_2 ==“books”}
     {Generate list of books here—lots of heavy SQL}
         {if no_results}
         sorry, no books found
         {/if}
     {lv_classic_display}  // This is a template for what we want to display for each book
   {/if}

   {if segment_2 == “authors”}
     ... same as above, but SQL pulls up authors

   {if segment_3 == “publishers”}
     ... same as above, but SQL pulls up publishers

   The problem I’m having is that the SQL stuff is being executed for ALL options on the page.  So, even if my segment_2 = “publishers”, it is still running the full SQL for pulling up all authors, and for pulling up all books, in addition to for publishers.  The stuff is never displayed on the page, because of the IF statements in there, but the SQL is causing a major performance drag.  It’s running hundreds of unnecessary queries in the background. 

   If I remove the {lv_classic_display}, the SQL does not execute.  So it appears to me that the inclusion of the low variable is forcing the loop around it to execute BEFORE the IF statement. 

   Early Parsing is turned on on the site—and I don’t think I can turn that off.  Is there a way for me to modify this to prevent this?

   I have tried using the alternate syntax:
   {exp:low_variables:parse var=“lv_classic_display”}
   and while that DOES eliminate the database queries, it also outputs just the { } code, rather than executing it.  So for each book my output looks like this:

   {ml_author_name}

   {ml_screen_name}

   Any suggestions for how I might be able to adjust this?  The performance on this page is getting killed by these silent SQL queries running in the background that aren’t ever going to get displayed….

   Thank you very much.

   Dave V.

    

4. Lodewijk Schutte 19 January 2013 at 17:26

   Hi Dave. Instead of trying to answer here, I’m going to redirect you to the EE StackExchange site: http://expressionengine.stackexchange.com/

   It’s much more suitable for general support questions like this.