I'm sure this has something to do with the parse order or it might be a bug. I'm trying to set a Stash variable in the first matrix row. After looking at the template debugging, Stash sets the variable in each loop of the matrix, thus not listening to the conditional.

    {if row_count == 1}{exp:stash:set name="my_var"}{option_value}{/exp:stash:set}{/if}

If I add a static character inside the conditional, it only parses once.


I added replace="no" parameter to the stash:set tag which fixed the variable from being overwritten once it's set. However, I would still like to know if setting the variable like the above is possible or if I'm approaching it the wrong way.

Update 2

I'm running a CartThrob site that has a ton of price modifiers (PM) for buying sheds online. A user can choose between several options, colors & other upgrades to build and buy a shed online. The site relies heavily on javascript which uses variables to construct files paths and other logic. Some PM fields I need to capture the 'default' options (first row of matrix field) to set variables for file paths and pricing logic. So instead of adding a ton of matrix pairs to the template where needed, I'm trying stay as DRY as possible. Hopefully that makes sense?

Live Example, view console to see some variables (soft launch right now as we are adding more styles)

  • I guess it would be helpful if you told us why you needed to save that variable. If you told us a little more information we could provide an alternative solution or validate your update Commented Mar 3, 2014 at 18:47
  • Sure, I just updated my questions with more context
    – Siebird
    Commented Mar 3, 2014 at 22:12

2 Answers 2


Maybe try wrap your code in an explicit parse block:

{exp:stash:parse parse_tags="yes" parse_depth="5" parse_conditionals="yes"}

(PS - your site is looking great!)

  • Thanks, it was a major improvement over the former. A WIP and files/scripts need to be optimized once finalized.
    – Siebird
    Commented Mar 4, 2014 at 14:16
  • Did you try this by any chance? I think it has the virtue of being a bit more explicit and nicely subverting parse order, but it might be slower. Depending on how complex your needs in that loop, it would certainly be more flexible with what you can do in there too. Commented Mar 4, 2014 at 23:14

I asked Mark over twitter and he replied:

@siebird usually (but not always) conditionals that are 'owned' by tags are 'prepped' but not actually evaluated until the end of parsing.

Which I did not know, so that explains the stash:set parsing every time through the matrix loop. As I stated above, adding the replace="no" parameter fixed the issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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