# Update expressions for v1.8

> The two expression syntax changes in v1.8, what the upgrade migration rewrites for you, and how to fix an expression that still uses the old form.

The expression engine was rebuilt for v1.8. Almost everything you could write before still works exactly the same way, but two specific pieces of syntax changed. Buttons automatically rewrites your existing stored expressions during the upgrade; this guide is mainly about what to do if you're writing or pasting a new expression afterward. What actually changed If you used this before v1.8 Use this instead Already-stored expressions getVariableValue('abc.def') getVariable('abc.def') Rewritten automatically during upgrade parseVariables('bare.dot.path') (no $(...) ) parseVariables('$(bare.dot.path)') Rewritten automatically during upgrade Everything else (every previously available function, the $(...) variable reference syntax itself, assignment and update operators, and every operator you'd expect in an expression) carries forward unchanged. This wasn't a small tweak: the underlying parser was fully replaced, but as a deliberate superset of what came before, with these two exceptions. What the automatic migration does for you When you upgrade to v1.8, a one-time migration runs automatically and rewrites both of the patterns above wherever it finds them in your stored button content, workflow nodes, and position variable values; no action needed on your part for anything already saved before the upgrade. Note The migration only rewrites the specific expression storage locations it's designed to handle. If you have an expression stored somewhere unusual that this migration doesn't reach, it will keep using the old syntax silently rather than erroring, see "If you get stuck" below for how to notice this. What you still need to fix yourself The migration only touches data that already existed before you upgraded. Anything you type or paste in after upgrading needs to already use the new syntax, including: An expression copied from an old note, script, or training material that predates v1.8. An expression you're recreating from memory the old way. If you paste in an old getVariableValue(...) call, it will fail outright rather than silently doing the wrong thing, see below. A bare, unwrapped path passed to parseVariables(...) , on the other hand, won't error; it just won't resolve, which is easier to miss. Fix a broken expression If getVariableValue fails: replace it with getVariable , using the exact same arguments: getVariableValue('abc.def') becomes getVariable('abc.def') . If parseVariables isn't resolving a value you expect it to: check whether the argument is wrapped in $(...) . parseVariables('abc.def') needs to become parseVariables('$(abc.def)') . If you get stuck What you see What to try An expression throws an error mentioning an unsupported function called getVariableValue . Replace it with getVariable , using the same arguments: this alias was removed in v1.8. parseVariables(...) returns the literal text you passed in instead of a resolved value. Wrap the argument in $(...) : a bare dot-path is no longer treated as an implicit variable reference. An expression that worked before upgrading now behaves differently, and it's not one of the two patterns above. This is unexpected: the rebuilt parser is meant to be a superset of the old one otherwise. Check the expression for getVariableValue or an unwrapped parseVariables argument first, since those are the two known changes; if neither applies, this may be worth reporting rather than working around. Where to go next Expression functions and operators reference Use variables in controls and expressions Understand variable scope