Releases: jesseditson/archival
v0.8.2
v0.8.2
v0.8.1
v0.8.1
v0.8.0
v0.8.0
v0.7.5
v0.7.5
v0.7.4
v0.7.4
v0.7.3
v0.7.3
v0.7.2
v0.7.2
v0.7.1
update rust toolchain in ci
v0.7.0
v0.7.0
v0.6.0
Breaking Release
Description
This release removes an auto-defaulting behavior that would allow you to omit fields from an object .toml
file and still be able to address them in liquid. For instance, if you defined:
# objects.toml
[subobjects]
title = "string"
field_name = "string"
and then had a .liquid
file with
{% for obj in objects.subobjects %}
{{ obj.field_name }}
{% endfor %}
and one of your subobjects
was defined as
title = "some object"
Archival would still build. This seemed nice, but had the unfortunate tradeoff of causing if
statements to feel like false positives.
For instance:
{% for obj in objects.subobjects %}
{% if obj.field_name %}THIS HAS A FIELD{% endif %}
{% endfor %}
with the above subobject
would print THIS HAS A FIELD
, which is confusing, and definitely a worse experience than a build failure when you access an undefined field.
In fact, access of undefined fields throwing errors is a good thing in 90% of cases, as it will help prevent you from shipping UI bugs (e.g. writing <a href="{{obj.field}}">foo</a>
and resulting in a link that points nowhere).
However, this will result in new build failures without any client code changes for sites relying on the old behavior.
TL:DR;
If you were using a prior version of archival, update to this version and verify that your site builds before publishing the new binaries.
If you encounter a build error, make sure you wrap access of undefined object fields with {% if object.field %}
blocks, or make sure that all objects of that type define that field.