Users of Liquid will often wish to filter an array to only those items that match a certain criteria. For example, showing "pinned" messages at the top of a list.
Example usage:
`{{ comments | where: "pinned" | first }}`
or
`{{ products | where: "category", "kitchen" }}`
* Add where filter to standard filters
* Add tests for new where functionality
This could be used to preserve the old default of rendering
non-Liquid::Error messages or for providing default behaviour like error
reporting which could be missed if the exception renderer needed to be
specified on each render.
These errors may contain sensitive information, so is safer to
render a more vague message by default.
This is done by replacing non-Liquid::Error exceptions with a
Liquid::InternalError exception with the non-Liquid::Error accessible on
through the cause method. This also allows the template name and line
number to be attached to the template errors.
The exception_handler render option has been changed to exception_renderer
since now it should raise an exception to re-raise on a liquid rendering
error or return a string to be rendered where the error occurred.
The argument `truncate_string` is now coerced into a string to avoid
`NoMethodError`s. This is mostly for added resiliency. It is doubtful
that someone would actually intent to use a number as truncate string,
but accidentally supplying one is entirely possible.
When including a template which is not defined, the exception raised is
*undefined method `split` for nil:NilClass*
This occurs for a scenario like the following:
`{% include nil %}`
or
`{% include undefined-var %}`
Making the code raise an argument error to allow better understanding of
the include error
Currently, `truncatewords` raises a TypeError when the argument
`truncate_string` is an interger. This PR forces string coercion for any
value provided for this argument. Thus,
```ruby
assert_equal 'one two1', @filters.truncatewords("one two three", 2, 1)
```
holds true. Another option would be to raise a `Liquid::ArgumentError`.
What is preferred?
When sorting an empty array with the "sort" filter, it returns nil
instead of []. This confuses subsequent filters in the chain that
expect an array. For example, when followed by the "map" filter, it
produces an array containing one nil element: [nil].
I could special-case the nil return value, but that would be more
cumbersome than making sure "sort" always returns an array.
Add a case to the "sort" method to return [] if the array is empty,
before performing any checks on ary.first that assume a non-empty array.
There is still a danger of returning nil if the first item in the array
is nil and it is non-empty, but I'm not sure how better to handle that
case.
Apply a similar fix to sort_natural, uniq, and compact filters.
Samuel