Yes, this is definitely a feature request but not sure if it will be fulfilled in the near future.
Semantically, allowing the filter to work with a single argument (as implemented in Liquid Core) will lead to a change in behavior for existing users.

Say someone has the following use case:

{% assign potential_projects = site.projects | where: 'activity', nil %}

Allowing the return of the opposite data with the following can be confusing and complicated to implement and maintain, IMO:

{% assign active_projects = site.projects | where: 'activity' %}

Might I suggest, then, making this a bit clearer in the documentation, that there are some slight differences between the core Liquid filters and the Jekyll Liquid filters. Saying that "all the standard liquid filters are supported" and linking to the Liquid core documentation is a bit very misleading. It's really a liquid-like scripting language or jeykll-flavored liquid, not actually liquid. This really needs to be stated explicitly, right upfront.

I see that you have the section for Liquid filters, and the section before that for the Jekyll custom filters, but it could be a little more explicit that the second section is a subset of the standard liquid filters that are supported, and that the first section is Jekyll added functions. Might be good to say "not to be confused with the Liquid where filter" for that specific one as well.

While the prevalence of the use case I pointed to above will be very low, (detecting nil with where was introduced only in v4.0.0), I agree that the documentation should add a note saying that in the event where Jekyll has a Liquid filter with the same name as one in Liquid core, Jekyll's own version takes precedence. And list a few examples as well..

This issue has been automatically marked as stale because it has not been commented on for at least two months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the latest 3.x-stable or master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider building it first as a plugin. Jekyll 3 introduced hooks which provide convenient access points throughout the Jekyll build pipeline whereby most needs can be fulfilled. If this is something that cannot be built as a plugin, then please provide more information about why in order to keep this issue open.

This issue will automatically be closed in two months if no further activity occurs. Thank you for all your contributions.

Let's not change our filter and just document the differences for now.

Hi all,

I ran into this myself. Unless there's a publicly available report as to how many people in the community this affects (I'm not aware of such, and would love to know), it's hard to understand the size the audience that this touches. Operating on data is key.

It was not clear to me that there was in fact a difference between Jekyll’s 'where' and Liquid’s 'where'.

Ideas to help clarify the distinction

Adding documentation to state the nuances between Jekyll's implementation v.s. it's Liquid’s implementation is a great idea.

A table might suffice - think gap analysis.

Might there be an option for both in Jekyll? Choosing to use a prefix for the addition of Liquid's?Jekyll -where
Liquid - liq_where

Happy to hear your thoughts

I've ran into the same issue and I like @VincentVToscano's idea of having a separate filter with Liquid's functionality, keeping the original where unchanged.

For now I'm using an if statement to achieve what I wanted but it's a bit less elegant.

@jekyll/core Whatsay? Should Jekyll 4.1 expose the upstream Liquid where filter via a new name..?

Since it is against the documented and intended behavior, it is definitely a bug. I don't see how #issuecomment-531844647 will be confusing to anyone.

Also any idea how to select the elements from an array that have a value for a property? I am using github-pages, jekyll (= 3.9.0)

edit: this seem to work:

{% assign filtered_array = site.emptyArray %}

{% for element in big_array %}

	{% if element.property %}

		{% assign filtered_array = filtered_array | push: element %}

	{% endif %}

{% endfor %}