strict_variables throws exception on checking if variable exists

[ptoews]

I'm using a jekyll layout where I want to include content of pages, depending on whether it exists.
Apparently, it is supposed to be done like described in #89
In my case it would look as follows:

{% assign title = page.title %}
{% if page.name %}
    {% assign title = page.name %}
{% endif %}
<title> {{ title }} | {{ site.title }} </title>

But since I have strict_variables set to true, which is really useful for development, Liquid throws an exception on building (undefined variable name included).

In my opinion, strict_variables should not throw exceptions for cases where the undefined variable is checked for existance.

[ptoews]

I've found a workaround for this case, which works only because page is a hash:

{% assign title = page.title %}
{% for key in page %}
    {% if key == "name" %}
        {% assign title = page.name %}
    {% endif %}
{% endfor %}

[pushrax]

This is a really good point, thanks for opening the issue. Some options:

• your suggestion of using if as a key existence operator in strict_variables mode
• new filter ( | has: 'name') or operator (if defined page.name or if page has name) to check existence of a key
• make this work more like a Ruby hash: allow access to missing keys but raise if accessing a key on a missing value

[paleite]

Do we have an update on this?

[mdlincoln]

Just adding my 👍 as we'd love to enable strict_variables on our project (in our case, a Jekyll site) but we rely heavily on checking for variable existence in our templates, so we can't use this as currently implemented.

(thanks also for a great templating library!)

[maxandersen]

Here is another 👍 as I was hoping to use strict_variables too to avoid dumb mistakes - but it doesn't work as existence check is used in not only my templates but also many themes.

I would say to be backwards compatible it should be that page.missing_key is allowed, but page.missing_key.value should give error and then have a more explicit operator to get better checks in new code.

[pushrax]

cc @dylanahsmith @Thibaut IMO this is a bug, and fixing it would make adopting strict_variables possible in Shopify for new templates. Out of the options in #1034 (comment) what do you prefer, or do you have another suggestion?

[dylanahsmith]

I think we need to decide whether we want to expose the concept of undefined as being distinct from nil. Currently, strict_variables has that distinction and it can help with typos or variable renames that miss some usage. However, it also requires either making sure the variable is always initialized (e.g. explicitly set to nil) or that we add something new to explicit check for undefined or handle the undefined value (e.g. using a filter like the default filter).

Alternatively, we could decide we don't really want that concept of undefined and treat undefined as nil. That is basically how strict_variables works. This would also be more consistent with the already recommended way of checking for the existence of a variable. We could still make things more strict about where nil could be used in even in this case, like doing a variable lookup on nil (e.g. page.name when page is nil). We could also try to do static analysis in the future to determine where a variable lookup always returns nil as a way of making it more strict.

I think we should try to avoid mixing concepts for consistency, because it would lead to unexpected behaviour. For instance, if we treat the {% if some_var %} as a special case, then it would lead to the expectation that {{ some_var | default: other_var }} would work. If we special case the default filter as well, then it would seem like other filters might be able to work with an undefined value. So I think we would end up with either special cases that we would have to document or something more like javascript where undefined is an actual value which application code would have to be updated to handle in a backwards compatible way.

• make this work more like a Ruby hash: allow access to missing keys but raise if accessing a key on a missing value

I think this probably makes the most sense, since it will be conceptually consistent with how liquid works without strict_variables where there isn't a distinction between undefined and nil.

[pascalbetz]

Defined and present (truthy/falsey) are two different things, IMHO.

I would prefer to be able to check if:

• a key is defined
• a value from an existing key is present

while having strict_variables: true

To achieve this I had to jump through some hoops:

I added a custom filter

module Filters
  def key(object, element)
    object.key?(element)
  end
end
Liquid::Template.register_filter(Filters)

And then used it in my template like so

{%- assign hasKey = data | key: 'bandwidth' %}
{%- if hasKey and data.bandwidth %}
  Bandwith: {{ data.bandwidth }}
{%- endif %}

template.render!("data" => {}) #=> ""
template.render!("data" => {"bandwidth" => nil}) #=> ""
template.render("data" => {"bandwidth" => 1234 }) #=> "Bandwidth: 1234"

while direct access to undefined keys still raises.

[steveoh]

Has a syntax been chosen?

It seems like there are a lot of good ideas and one needs to be chosen and implemented.

[asbjornu]

@pascalbetz, that custom filter looks exactly like what I'm after – until this issue is resolved, at least. I'm just wondering how you "install" such a custom filter into a Jekyll site. Do I need to create a whole repository, gem, bundle and all to host those 6 lines of code to say plugins: "jekyll-key" in my Jekyll site's _config.yml or can a Jekyll plugin reside "locally" within the Jekyll site, somehow?

[pascalbetz]

Sorry, no experience with Jekyll.

[asbjornu]

This article on Jekyll plugins taught me that plugins can just be dumped in a _plugins folder, so your filter seems to be working in my Jekyll instance now, @pascalbetz. Thanks!

[chuckhoupt]

I've found that the Liquid contains operator works well for existence testing variables. Shouldn't this be the canonical way to test for fields?

Example:

{% if page contains "name" %}
   Name: {{ page.name }}
{% endif %}

[pascalbetz]

Looks like contains should work (according to the code) but the documentation does not mention this.