Support for "contains" in "where" filter?

[swanson]

I'd like to be able to filter posts on my site based on the inclusion of a certain tag. Currently, I have to do it like this:

# Work-around
{% for post in site.posts %}
  {% if post.tags contains "ruby" %}
    <li><a href="{{ post.url }}">{{ post.title }}</a></li>
  {% endif %}
{% endfor %}

I would like support for checking if a collection contains an item as part of the where clause. The work-around is okay, but it will require extra effort if we want to e.g. limit it to the first 5 posts matching a tag (since you'd have to track the count manually).

Maybe something like:

{% for post in site.posts | where_contains: "tags", "ruby" %}
  <li><a href="{{ post.url }}">{{ post.title }}</a></li>
{% endfor %}

or if tags are important enough,

{% for post in site.posts | with_tag: "ruby" %}
  <li><a href="{{ post.url }}">{{ post.title }}</a></li>
{% endfor %}

I'm happy to work on a PR if this is appropriate for Jekyll core - I'm less interested in a custom plugin since all my Jekyll stuff is deployed to GH Pages.

[parkr]

Does site.tags not satisfy your need?

jekyll/lib/jekyll/site.rb

Line 354 in 00c898b

"tags" => post_attr_hash('tags'),

[swanson]

@parkr - ah, had not seen that. That will serve my needs for this case.

[parkr]

Glad to hear we already have what you need!

[chimericdream]

Sorry to resurrect a relatively old issue, but I ran into this recently as well. In my case, I want to filter a collection based on a specific category. Each collection item can belong to an arbitrary number of categories, and I need to be able to get a list of items in a particular category.

Something like this is what I am hoping for:

{% assign item_list = site.items | contains:"item.categories", "Some Category" %}

[Lemez]

Me too.
The tags filter is great, but I would like present my posts to the user with different categories of tag:
location-tags, artist-tags, content-tags etc.

So:
{% assign pages_list = (site.posts | where: "location" contains "London") %}

would be ideal.

[envygeeks]

We are not SQL, so your example will never happen @Lemez but if you would like to suggest a more viable syntax that doesn't require us to parse please file a new ticket and spark a conversation rather than necromancing an old ticket. Thanks.