I only asked because I already earlier indicated that this could not be done via Footers but let to believe it was possible so asked to show me how.
So to be clear:
From the beginning I understood that you can not use new features such as Footers when using Custom themes. We decided to continue with Custom themes.
From the introduction of Footers it was clear that styling elements for these could be implemented. As we use Custom themes we did not bother.
When @Lubos announced putting Custom themes we were asked what we needed and several times it was made clear that something would be put in place, but nothing happened. Now that footers are being strengthened it is time for the long-awaited header or whatever feature to allow us to ditch custom themes.
Thank you, so it is possible. Very interesting. I did not manage to change the header font colour to #fff nor do I know how to change the background to similar as the headers. I will experiment with the script and styling further.
The data exposed in the footer seems to be the same as the data exposed in custom themes. All data comes from Invoice/transaction. only the way to get it is different.
So I think, when we use custom themes, there is no need to use footers anymore. unless there are special needs that cannot be done in custom themes.
@tut, discussion out of title, looks like this thread needs to be split.
Yes i know that. But using the footer option you can select different footers depending on situation. So in custom theme when footers are included either those footer doesnt change much from transaction to transaction or you would’ve to put too much conditioning or seperate themes for each kind of footer combination. So that would be too much for too little benefit. So lets hope the headers and new custom themes are introduced soon.
I wanted to revisit the original issue regarding the duplication of custom fields in Liquid templates, as the thread seems to have veered into discussions about changing template colors. If you’re still dealing with the problem of rendering duplicate fields, here’s a solution that worked for me.
The idea is to use a string as an array to keep track of the labels that have already been rendered. Here’s how you can do it:
{% assign rendered_labels = "" %} {# Array to track already rendered labels #}
{% for field in custom_fields %}
{% if field.label and rendered_labels != "" and rendered_labels contains field.label %}
{% continue %} {# Skip to the next field if the label has already been rendered #}
{% endif %}
{% if field.label %}
<tr>
<td style="text-align: right; width: 150px; max-width: 150px;">
<div style="font-weight: bold; text-align: right; white-space: nowrap; width: 150px; max-width: 150px;">{{ field.label }}:</div>
</td>
<td>
<div style="text-align: left; width: 300px; max-width: 300px; padding-left: 10px;">{{ field.text | newline_to_br }}</div>
</td>
<td colspan="3">
<div style="text-align: left; width: 400px; max-width: 400px;"> </div>
</td>
</tr>
{% assign rendered_labels = rendered_labels | append: field.label | append: "," %} {# Add the rendered label to the array #}
{% endif %}
{% endfor %}
Explanation:
Track Rendered Labels: I used rendered_labels as a string to store labels that have already been rendered.
Check Before Rendering: Before rendering a field, I check if the label is already in rendered_labels.
Skip Duplicates: If the label is found, the continue statement skips rendering for that field.
This approach ensures that each label is only rendered once, preventing any duplicates in the output. I hope this helps anyone dealing with similar issues in Liquid templates!
Let me know if you have any questions or improvements!