I’m well aware that there is work happening on document structures and layouts, and that some of this might cause problems with custom themes. I also understand that custom themes are the user’s responsibility. However, I’m hoping that somebody might be able to give some guidance to understand what has changed in the last day and how I can fix my theme.
My custom theme uses conditional checks for two purposes:
- We are required by our tax authorities to submit our sales invoices electronically through a fiscal device. The script that reads our PDFs does not handle multiple options for the “quantity” header. If we submit a sales invoice containing only an item that is measured in units, such as m or l, the script does not recognise this as being the “quantity” column, and the submission fails. I customised our theme to use “Qty” as the column header in all instances. I wrote about it in this post.
- I have modified our theme so that if an item with a certain code is selected, that row will be highlighted and an alert will be created.
Both of these customisations have worked well until today. We are using the cloud version, currently on 22.7.6. I have tested in Firefox and Chrome.
There are a few other conditionals within the theme that check if certain fields exist and position them at the top of the document. These seem to be working fine, so I think the problem has to do with the way I have declared variables in my theme and then referenced them further down.
<table>
{% assign myRowHighlight = false %}
<thead>
…
</thead>
<tbody>
{% for row in table.rows %}
<tr>
…
</tr>
{% endfor %}
{% if myRowHighlight %}<script>alert("Alert!")</script>{% endif %}
{% for total in table.totals %}
<tr>
…
</tr>
{% endfor %}
</tbody>
<tfoot>
…
</tfoot>
</table>
I have shown only the bits of code that I believe are causing the problem, but will happily share the whole theme if that would be helpful. The code for each row contains a check which will change the value of my myRowHighlight variable to true if certain conditions are met, but even if I assign it a value of true in the declaration at the top of the table, the script is not triggered. I would appreciate any advice that might help me get the variables and checks working again.
Having done a little more testing it looks like we might have lost the ability to set and call variables altogether. The following creates an alert with the message “Test”:
<table>
{% assign myRowHighlight = true %}
<script>alert("Test")</script>
…
</table>
But the following doesn’t create an alert at all:
<table>
{% assign myRowHighlight = true %}
<script>alert("Value = " + myRowHighlight)</script>
…
</table>
I have made a test where I declared a variable in liquid and then called it using liquid.
{% assign test = "It works" %}
<td>
<div style="font-size: 14px; font-weight: bold; margin-bottom: 20px; padding: 0px 30px">{{ test }}</div>
</td>
It worked:
So this rules out the this scenario:
…and
This rules out that script tags don’t work.
But honestly I wasn’t aware that we were able to directly refer to variables declared in Liquid using JS and so Idk exactly what happened here and I can’t reproduce it.
What’s the most recent version where this used to work for you?
1 Like
Thanks @Ealfardan. You’ve highlighted a flaw in my reasoning and testing. I hadn’t actually called the Liquid variables in JS except in my testing just now, so perhaps that has never worked. I’ve just tried this and it works:
<table>
{% assign myRowHighlight = true %}
{% if myRowHighlight %}<script>alert("Test")</script>{% endif %}
…
</table>
So I’ll need to do a bit more testing to see why it doesn’t work lower down in my theme. I became aware of the problem this morning. As far as I know it was working fine yesterday. My first customisation as described in post #1 above has been working since I created it in April 2021. I made the second one a couple of months ago and it has been working fine since then, so something has changed in the last 24 hours or so that has affected them both.
1 Like
Theoretically, the concept should work since liquid is eventually interpreted into JS. But I guess the scoping must be different. I even tried declaring a global variable in JS first and then using it in liquid but even that didn’t work:
<script>myRowHighlight = true;</script>
<table>
<tr>
<td>{{ myRowHighlight }}</td>
</tr>
</table>
<script>alert(myRowHighlight);</script>
It didn’t work when called in liquid but it worked when it’s called again by the second script tag. I guess this means we have tighter security over liquid now compared to April 
.
So unless your customization heavily depends on cross declaring variables between JS and liquid, I think refactoring your code would be best, exactly as you did already.
1 Like
Thanks for your help. I think I’ve been looking at the wrong things. I’ve been testing with Sales Orders, and I see now that they behave differently to Sales Invoices.
In Sales Orders, the first column is called “Item” and shows the item code concatenated with the item name. In Sales Invoices, the first column is called “Code” and shows only the item code.
My second customisation checked the first column against a string, and applied certain styling to the row if there was a match. But when the code was concatenated with the name it stopped matching at all. So, I will modify my theme to be more robust and search for a substring. Or I could check “Hide item name on printed documents” in the settings for that item, which has fixed the problem for that customisation in my test.
I haven’t worked out why my first customisation is still failing, but I will look more closely at the column names and layout structure, as I suspect it is probably for a similar reason as above.
1 Like
True, a lot has changed over these past couple of weeks.
I’ve worked out why my first customisation was failing. It was checking for column headers matching “M”, “L”, or “Hours” and replacing those with “Qty”. However, in Sales Orders the units now appear in column headers in lowercase, so adding “m”, “l”, and “hours” to my list of search candidates fixed it.
