Add a simple profiling system to liquid rendering. Each
liquid tag ({{ }} and {% %}) is processed through this profiling,
keeping track of the partial name (in the case of {% include %}), line
number, and the time it took to render the tag. In the case of {%
include %}, the profiler keeps track of the name of the partial and
properly links back tag rendering to the partial and line number for
easy lookup and dive down. With this, it's now possible to track down
exactly how long each tag takes to render.
These hooks get installed and uninstalled on an as-need basis so by
default there is no impact on the overall liquid execution speed.
Three tests in the test suite use the Liquid::Template.register_filter
function to register custom filters with Liquid::Strainer. The problem
is that these register_filter calls leave the Liquid::Strainer object in
an altered state.
As an example, the FiltersTest's test_local_filter relies on the default
behavior of Liquid::Strainer operator, and the test was failing if
register_function had been called earlier. The same thing was happening
with FiltersInTemplate's test_local_global.
The problem was present when the Filters test classes were loaded inside
a single ruby process that also loaded HashOrderingTest. One example is
"rake test", which runs "require" on every test file. Another basic
example is the following command:
ruby -Itest -e "require 'integration/hash_ordering_test';
require 'integration/filter_test'"
Update the tests to always reset Liquid::Strainer's filters back to the
default list of filters.
With this change, FiltersTest and FiltersInTemplate now pass.
Two tests in IfElseTagTest each set a custom operator function for the
"contains" comparison operator.
The problem is that IfElseTagTest was clobbering the original operator
in Liquid and leaving it in an altered state.
As an example, ConditionUnitTest's test_contains_works_on_arrays relies
on the specific behavior of the "contains" operator, and its
test_contains_works_on_arrays was failing.
The problem was present when both test classes were require'd inside a
single ruby process. One example is "rake test", which runs "require" on
every test file. Another basic example is the following command:
ruby -Itest -e "require 'integration/tags/if_else_tag_test.rb';
require 'unit/condition_unit_test.rb'"
This would cause test_contains_works_on_arrays to fail.
Update IfElseTagTest to avoid clobbering the "contains" operator.
With this change, ConditionUnitTest's test_contains_works_on_arrays now
passes.
Ruby 1.9+ uses Minitest as the backend for Test::Unit. As of Minitest 5,
the shim has broken some compatibility with Test::Unit::TestCase in some
scenarios.
Adjusts the test suite to support Minitest 5's syntax.
Minitest versions 4 and below do not support the newer Minitest::Test
class that arrived in version 5. For that case, use the
MiniTest::Unit::TestCase class as a fallback
Conflicts:
test/integration/tags/for_tag_test.rb
test/test_helper.rb
Because Liquid keeps a reference to tag classes, Rails class reloading may
cause problems with custom tags. This commit introduces a setting that
allows these classes to be resolved when required.
Update the URL of the docs badge to include it from inch-ci.org instead of inch-pages.github.io (the former being the successor of the Inch Pages project).
[ci skip]
Condition now raises ::ArgumentError when built wrongly.
This patch make it raise Liquid::ArgumentError instead
to indicate a liquid markup error instead of ruby error.
Added '%s' - Number of seconds since 1970-01-01 00:00:00 UTC to included list of flags
Added link to Ruby docs on Time#strftime() to allow easier discovery of unlisted filter options.
That pull request broke raw tags with open variable tags. E.g.
{% raw %}
{{
{% endraw %}
{{ 1 }}
This reverts commit fbaabf3b59, reversing
changes made to af24d2c2ab.
* Strainer has a class cache that creates Strainer subclasses for each filter
set that is used on .create calls.
* Context now creates a list of filters and passes this to Strainer.create to
utilize the class cache in almost all use cases.
* If add_filter was called after a render, then the method cache may still be
invalidated.
Conflicts:
lib/liquid/strainer.rb
1.8.7 compatibility fix
In Ruby 1.8.7, Hash does not preserve insertion ordering as Array does.
This could cause a problem when registering filters which depend on others and
the registration order is important.
So, the @@filters variable was changed to array where the order of the filters is
the same as the insertion order.
After moving the method existence check from Context into Strainer,
updated Strainer to only accept invokation methods that were added via
filter Modules, and done in a way that respond_to? is never called,
preventing unconstrained Symbol table growth.
Class.public_method_defined? ends up diving into Ruby's core looking for
a method with the given method_or_key. This process at some point turns
method_or_key into a Symbol. This change no longer takes that path and
thus doesn't grow the Symbol table.
The regex was using \S+ to match the comma between the filters
arguments, but would continue to match idependent quote characters and
filter separators. This can result in multiple filters being interpreted as
a single one with many arguments.
When a continue or break statement is executed it pushes an interrupt to a
stack in context. If any non-handled interrupts are present blocks will cease
to execute. The for loop can handle the most recent interrupt in the stack.
I had accidentally read slice_collection_using_each as using to as an
inclusive limit rather than exclusive, and no tests covered the offset or
limit parameters.
* 'master' of git://github.com/Shopify/liquid:
* Seperated 'Howto' into 'How to'. * Added periods to the second list as the first item has them. I guess I'm anally retentive like that. :)
Fix conditions using negative number comparisons
A simple attempt, but basically it shifts the parsing of the right hand side of the assign from a simple context lookup to using the Variable parser (that includes filters). Fixes#79.
Portions of the code examples were not being rendered as code because they lacked a leading tab. Also, a missing period on the first sentence made the first paragraph confusing.
Thanks to phaer: https://gist.github.com/1020852
YO DAWG, WE HEARD YOU LIKE LIQUID
SO WE PUT A RAW TAG IN YOUR LIQUID
SO YOU CAN HAVE LIQUID IN YOUR LIQUID
- regexp engines are different from 1.8 to 1.9, fixed the literal shorthand regexp accordingly
- changed the shorthand regexp text from a match to a string scan
- test_helper now loads rubygems unless RUBY_VERSION is > 1.9
- added test to assert that conditions can contain conditions within its value (eg 'a-and-b')
Tags
- indented the if tag
Tests
- added ruby-debug to the test_helper
- indented some tests
- added test that asserts nonexistent filters are ignored
Liquid
- Bill's mind blowing liquid patch to support filter separators (|) in quoted strings (svn r7516).
- This is a consolidation effort based on newrelic's liquid fork commit 88a5b891d009054d56b994c9448725c74e2b1e13
Using an attribute should only cause the corresponding method to be invoked
once. Replacing a lambda with its return value should work for arrays.
Array index syntax shouldn't allow calls to special methods.
* Features which are likely to be useful to the majority of Liquid users
## Things we won't merge
* Code which introduces considerable performance degrations
* Code which touches performance critical parts of Liquid and comes without benchmarks
* Features which are not important for most people (we want to keep the core Liquid code small and tidy)
* Features which can easily be implemented on top of Liquid (for example as a custom filter or custom filesystem)
* Code which comes without tests
* Code which breaks existing tests
## Workflow
* Fork the Liquid repository
* Create a new branch in your fork
* If it makes sense, add tests for your code and run a performance benchmark
* Make sure all tests pass
* Create a pull request
* In the description, ping one of [@boourns](https://github.com/boourns), [@fw42](https://github.com/fw42), [@camilo](https://github.com/camilo), [@dylanahsmith](https://github.com/dylanahsmith), or [@arthurnn](https://github.com/arthurnn) and ask for a code review.
Yanked from rubygems, as it contained too many changes that broke compatibility. Those changes will be on following major releases.
## 2.5.1 / 2013-07-24
*#230: Fix security issue with map filter, Use invoke_drop in map filter [Florian Weingarten, fw42]
## 2.5.0 / 2013-03-06
* Prevent Object methods from being called on drops
* Avoid symbol injection from liquid
* Added break and continue statements
* Fix filter parser for args without space separators
* Add support for filter keyword arguments
## 2.4.0 / 2012-08-03
* Performance improvements
* Allow filters in `assign`
* Add `modulo` filter
* Ruby 1.8, 1.9, and Rubinius compatibility fixes
* Add support for `quoted['references']` in `tablerow`
* Add support for Enumerable to `tablerow`
*`strip_html` filter removes html comments
## 2.3.0 / 2011-10-16
* Several speed/memory improvements
* Numerous bug fixes
* Added support for MRI 1.9, Rubinius, and JRuby
* Added support for integer drop parameters
* Added epoch support to `date` filter
* New `raw` tag that suppresses parsing
* Added `else` option to `for` tag
* New `increment` tag
* New `split` filter
## 2.2.1 / 2010-08-23
* Added support for literal tags
## 2.2.0 / 2010-08-22
* Compatible with Ruby 1.8.7, 1.9.1 and 1.9.2-p0
* Merged some changed made by the community
## 1.9.0 / 2008-03-04
* Fixed gem install rake task
* Improve Error encapsulation in liquid by maintaining a own set of exceptions instead of relying on ruby build ins
## Before 1.9.0
* Added If with or / and expressions
* Implemented .to_liquid for all objects which can be passed to liquid like Strings Arrays Hashes Numerics and Booleans. To export new objects to liquid just implement .to_liquid on them and return objects which themselves have .to_liquid methods.
* Added more tags to standard library
* Added include tag ( like partials in rails )
* [...] Gazillion of detail improvements
* Added strainers as filter hosts for better security [Tobias Luetke]
* Fixed that rails integration would call filter with the wrong "self" [Michael Geary]
* Fixed bad error reporting when a filter called a method which doesn't exist. Liquid told you that it couldn't find the filter which was obviously misleading [Tobias Luetke]
* Removed count helper from standard lib. use size [Tobias Luetke]
* Fixed bug with string filter parameters failing to tolerate commas in strings. [Paul Hammond]
* Improved filter parameters. Filter parameters are now context sensitive; Types are resolved according to the rules of the context. Multiple parameters are now separated by the Liquid::ArgumentSeparator: , by default [Paul Hammond]
{{ 'Typo' | link_to: 'http://typo.leetsoft.com', 'Typo - a modern weblog engine' }}
* Added Liquid::Drop. A base class which you can use for exporting proxy objects to liquid which can acquire more data when used in liquid. [Tobias Luetke]
* [Liquid documentation from Shopify](http://docs.shopify.com/themes/liquid-basics)
* [Liquid Wiki at GitHub](https://github.com/Shopify/liquid/wiki)
* [Website](http://liquidmarkup.org/)
## Introduction
Liquid is a template engine which was written with very specific requirements:
* It has to have beautiful and simple markup. Template engines which don't produce good looking markup are no fun to use.
* It needs to be non evaling and secure. Liquid templates are made so that users can edit them. You don't want to run code on your server which your users wrote.
* It has to be stateless. Compile and render steps have to be separate so that the expensive parsing and compiling can be done once and later on you can just render it passing in a hash with local variables and objects.
## Why you should use Liquid
* You want to allow your users to edit the appearance of your application but don't want them to run **insecure code on your server**.
* You want to render templates directly from the database.
* You like smarty (PHP) style template engines.
* You need a template engine which does HTML just as well as emails.
* You don't like the markup of your current templating engine.
description:Liquid is a template language and accompanying rendering engine. It is built for security, so is perfect for rendering custom templates from your users.
# Build settings
baseurl:/liquid# the subpath of your site, e.g. /blog/
url:http://liquidmarkup.org# the base hostname & protocol for your site
permalink:pretty
exclude:
- README.md
- CNAME
- Gemfile
- Gruntfile.js
- package.json
- node_modules
keep_files:["css"]
# Plugins
gems:
- jekyll-redirect-from
# Front matter defaults
defaults:
- scope:
path:""# an empty string here means all files in the project
description:An overview of objects, tags, and filters in the Liquid template language.
---
Liquid code can be categorized into [**objects**](#objects), [**tags**](#tags), and [**filters**](#filters).
## Objects
**Objects** tell Liquid where to show content on a page. Objects and variable names are denoted by double curly braces: `{% raw %}{{{% endraw %}` and `{% raw %}}}{% endraw %}`.
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ page.title }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
Introduction
```
In this case, Liquid is rendering the content of an object called `page.title`, and that object contains the text `Introduction`.
## Tags
**Tags** create the logic and control flow for templates. They are denoted by curly braces and percent signs: `{% raw %}{%{% endraw %}` and `{% raw %}%}{% endraw %}`.
The markup used in tags does not produce any visible text. This means that you can assign variables and create conditions and loops without showing any of the Liquid logic on the page.
description:An overview of boolean logic in the Liquid template language.
---
In programming, anything that returns `true` in a conditional is called **truthy**. Anything that returns `false` in a conditional is called **falsy**. All object types can be described as either truthy or falsy.
- [Truthy](#truthy)
- [Falsy](#falsy)
- [Summary](#summary)
## Truthy
All values in Liquid are truthy except `nil` and `false`.
In the example below, the string "Tobi" is not a boolean, but it is truthy in a conditional:
```liquid
{% raw %}
{% assign tobi = "Tobi" %}
{% if tobi %}
This condition will always be true.
{% endif %}
{% endraw %}
```
[Strings]({{ "/basics/types/#string" | prepend: site.baseurl }}), even when empty, are truthy. The example below will result in empty HTML tags if `settings.fp_heading` is empty:
<p class="code-label">Input</p>
```liquid
{% raw %}
{% if settings.fp_heading %}
<h1>{{ settings.fp_heading }}</h1>
{% endif %}
{% endraw %}
```
<p class="code-label">Output</p>
```html
<h1></h1>
```
## Falsy
The falsy values in Liquid are [`nil`]({{ "/basics/types/#nil" | prepend: site.baseurl }}) and [`false`]({{ "/basics/types/#boolean" | prepend: site.baseurl }}).
## Summary
The table below summarizes what is truthy or falsy in Liquid.
description:An overview of data types in the Liquid template language.
---
Liquid objects can have one of six types:
- [String](#string)
- [Number](#number)
- [Boolean](#boolean)
- [Nil](#nil)
- [Array](#array)
You can initialize Liquid variables with the [assign]({{ "/tags/variable/#assign" | prepend: site.baseurl }}) or [capture]({{ "/tags/variable/#capture" | prepend: site.baseurl }}) tags.
## String
Declare a string by wrapping a variable's value in single or double quotes:
```liquid
{% raw %}
{% assign my_string = "Hello World!" %}
{% endraw %}
```
## Number
Numbers include floats and integers:
```liquid
{% raw %}
{% assign my_int = 25 %}
{% assign my_float = 39.756 %}
{% endraw %}
```
## Boolean
Booleans are either `true` or `false`. No quotations are necessary when declaring a boolean:
```liquid
{% raw %}
{% assign foo = true %}
{% assign bar = false %}
{% endraw %}
```
## Nil
Nil is a special empty value that is returned when Liquid code has no results. It is **not** a string with the characters "nil".
Nil is [treated as false]({{ "/basics/truthy-and-falsy" | prepend: site.baseurl }}) in the conditions of `if` blocks and other Liquid tags that check the truthfulness of a statement.
In the following example, if the user does not exist (that is, `user` returns `nil`), Liquid will not print the greeting:
```liquid
{% raw %}
{% if user %}
Hello {{ user.name }}!
{% endif %}
{% endraw %}
```
Tags or outputs that return `nil` will not print anything to the page.
<p class="code-label">Input</p>
```liquid
{% raw %}
The current user is {{ user.name }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
The current user is
```
## Array
Arrays hold lists of variables of any type.
### Accessing items in arrays
To access all the items in an array, you can loop through each item in the array using an [iteration tag]({{ "/tags/iteration" | prepend: site.baseurl }}).
<p class="code-label">Input</p>
```liquid
{% raw %}
<!-- if site.users = "Tobi", "Laura", "Tetsuro", "Adam" -->
{% for user in site.users %}
{{ user }}
{% endfor %}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{% raw %}
Tobi Laura Tetsuro Adam
{% endraw %}
```
### Accessing specific items in arrays
You can use square bracket `[``]` notation to access a specific item in an array. Array indexing starts at zero.
<p class="code-label">Input</p>
```liquid
{% raw %}
<!-- if site.users = "Tobi", "Laura", "Tetsuro", "Adam" -->
{{ site.users[0] }}
{{ site.users[1] }}
{{ site.users[3] }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
Tobi
Laura
Adam
```
### Initializing arrays
You cannot initialize arrays using only Liquid.
You can, however, use the [split]({{ "/filters/split" | prepend: site.baseurl }}) filter to break a string into an array of substrings.
description:An overview of the different installations of Liquid and how Liquid can change depending on where you're using it.
---
Liquid is a flexible, safe language, and is used in many different environments. Liquid was created for use in [Shopify](https://www.shopify.com) stores, and is also used extensively on [Jekyll](https://jekyllrb.com) websites. Over time, both Shopify and Jekyll have added their own objects, tags, and filters to Liquid. The most popular versions of Liquid that exist are **Liquid**, **Shopify Liquid**, and **Jekyll Liquid**.
This site documents the latest version of **Liquid** including betas and release candidates — that is, Liquid as it exists outside of Shopify and Jekyll. If you download the Liquid repository or install it as a [gem](https://rubygems.org/gems/liquid), you will get access to whatever objects, tags, and filters are in the version of Liquid that you chose.
## Shopify
Shopify always uses the latest version of Liquid as a base, but Shopify adds a significant number of objects, tags, and filters to Liquid for use in merchants' stores. These include objects representing store, product, and customer information, and filters for displaying store data and manipulating storefront assets like product images.
Shopify's version of Liquid is documented in the [Shopify Help Center](https://help.shopify.com/themes/liquid). If you want to try out Shopify's version of Liquid, you can [start a free trial of Shopify](https://www.shopify.com/signup) or use a sandbox like [DropPen](http://droppen.org/).
## Jekyll
[Jekyll](https://jekyllrb.com) is a static site generator, a command-line tool that creates websites by merging templates with content files. Jekyll uses Liquid as its template language, and adds a few objects, tags, and filters. These include objects representing content pages, tags for including snippets of content in others, and filters for manipulating strings and URLs.
Jekyll also powers [GitHub Pages](https://pages.github.com/), a web hosting service that lets you push a Jekyll installation to a GitHub repository and have the resulting website published. This website is built using GitHub Pages.
Jekyll might not be using the latest version of Liquid. This means that the tags and filters listed on this site may not work in Jekyll. Often the Jekyll project will wait for a stable release of Liquid rather than using a beta or release candidate version. To see what version of Liquid Jekyll is using, check the **runtime dependencies** section of [Jekyll's gem page](https://rubygems.org/gems/jekyll).
Jekyll's version of Liquid is documented in the [Templates section of Jekyll's documentation](http://jekyllrb.com/docs/templates/). If you want to try out Jekyll's version of Liquid, you can clone the Jekyll project or install Jekyll as a gem and test Liquid on a static site.
description:An overview of controlling whitespace between code in the Liquid template language.
---
In Liquid, you can include a hyphen in your tag syntax `{% raw %}{{-{% endraw %}`, `{% raw %}-}}{% endraw %}`, `{% raw %}{%-{% endraw %}`, and `{% raw %}-%}{% endraw %}` to strip whitespace from the left or right side of a rendered tag.
Normally, even if it doesn't output text, any line of Liquid in your template will still output a blank line in your rendered HTML:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{% assign my_variable = "tomato" %}
{{ my_variable }}
```
{% endraw %}
Notice the blank line before "tomato" in the rendered template:
<p class="code-label">Output</p>
``` text
{% assign my_variable = "tomato" %}
{{ my_variable }}
```
By including hyphens in your `assign` tag, you can strip the generated whitespace from the rendered template:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{%- assign my_variable = "tomato" -%}
{{ my_variable }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
tomato
```
If you don't want any of your tags to output whitespace, as a general rule you can add hyphens to both sides of all your tags (`{% raw %}{%-{% endraw %}` and `{% raw %}-%}{% endraw %}`):
<p class="code-label">Input</p>
{% raw %}
``` liquid
{% assign username = "John G. Chalmers-Smith" %}
{% if username and username.size > 10 %}
Wow, {{ username }}, you have a long name!
{% else %}
Hello there!
{% endif %}
```
{% endraw %}
<p class="code-label">Output without whitespace control</p>
``` text
{% assign username = "John G. Chalmers-Smith" %}
{% if username and username.size > 10 %}
Wow, {{ username }}, you have a long name!
{% else %}
Hello there!
{% endif %}
```
<p class="code-label">Input</p>
{% raw %}
``` liquid
{%- assign username = "John G. Chalmers-Smith" -%}
{%- if username and username.size > 10 -%}
Wow, {{ username }}, you have a long name!
{%- else -%}
Hello there!
{%- endif -%}
```
{% endraw %}
<p class="code-label">Output with whitespace control</p>
``` text
Wow, John G. Chalmers-Smith, you have a long name!
[{'name'=>'Arbor Draft','price'=>39900,'description'=>'the *arbor draft* is a excellent product'},
{'name'=>'Arbor Element','price'=>40000,'description'=>'the *arbor element* rocks for freestyling'},
{'name'=>'Arbor Diamond','price'=>59900,'description'=>'the *arbor diamond* is a made up product because im obsessed with arbor and have no creativity'}]
end
defdescription
"List of Products ~ This is a list of products with price and description."
description:Liquid filter that removes nil values from an array.
---
Removes any `nil` values from an array.
For this example, assume `site.pages` is an array of content pages for a website, and some of these pages have an attribute called `category` that specifies their content category. If we `map` those categories to an array, some of the array items might be `nil` if any pages do not have a `category` attribute.
`date` works on strings if they contain well-formatted dates:
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "March 14, 2016" | date: "%b %d, %y" }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "March 14, 2016" | date: "%b %d, %y" }}
```
To get the current time, pass the special word `"now"` (or `"today"`) to `date`:
<p class="code-label">Input</p>
```liquid
{% raw %}
This page was last updated at {{ "now" | date: "%Y-%m-%d %H:%M" }}.
{% endraw %}
```
<p class="code-label">Output</p>
```text
This page was last updated at {{ "now" | date: "%Y-%m-%d %H:%M" }}.
```
Note that the value will be the current time of when the page was last generated from the template, not when the page is presented to a user if caching or static site generation is involved.
description:Liquid filter that divides a number by another number.
---
Divides a number by the specified number.
The result is rounded down to the nearest integer (that is, the [floor]({{ site.baseurl }}/filters/floor)) if the divisor is an integer.
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ 16 | divided_by: 4 }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ 16 | divided_by: 4 }}
```
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ 5 | divided_by: 3 }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ 5 | divided_by: 3 }}
```
### Controlling rounding
`divided_by` produces a result of the same type as the divisor — that is, if you divide by an integer, the result will be an integer. If you divide by a float (a number with a decimal in it), the result will be a float.
For example, here the divisor is an integer:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ 20 | divided_by: 7 }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ 20 | divided_by: 7 }}
```
Here it is a float:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ 20 | divided_by: 7.0 }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ 20 | divided_by: 7.0 }}
```
### Changing variable types
You might want to use a variable as a divisor, in which case you can't simply add `.0` to convert it to a float. In these cases, you can `assign` a version of your variable converted to a float using the `times` filter.
In this example, we're dividing by a variable that contains an integer, so we get an integer:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{% assign my_integer = 7 %}
{{ 20 | divided_by: my_integer }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{% assign my_integer = 7 %}
{{ 20 | divided_by: my_integer }}
```
Here, we [multiply]({{ site.baseurl}}/filters/times) the variable by `1.0` to get a float, then divide by the float instead:
description:Liquid filter that escapes URL-unsafe characters in a string.
---
Escapes a string by replacing characters with escape sequences (so that the string can be used in a URL, for example). It doesn't change strings that don't have anything to escape.
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Have you read 'James & the Giant Peach'?" | escape }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Have you read 'James & the Giant Peach'?" | escape }}
description:Liquid filter that creates an array of values by extracting a named property from an object.
---
Creates an array of values by extracting the values of a named property from another object.
In this example, assume the object `site.pages` contains all the metadata for a website. Using `assign` with the `map` filter creates a variable that contains only the values of the `category` properties of everything in the `site.pages` object.
`reverse` cannot be used directly on a string, but you can split a string into an array, reverse the array, and rejoin it by chaining together filters:
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Ground control to Major Tom." | split: "" | reverse | join: "" }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Ground control to Major Tom." | split: "" | reverse | join: "" }}
description:Liquid filter that returns the number of characters in a string or the number of items in an array.
---
Returns the number of characters in a string or the number of items in an array. `size` can also be used with dot notation (for example, `{% raw %}{{ my_string.size }}{% endraw %}`). This allows you to use `size` inside tags such as conditionals.
description:Liquid filter that returns a substring from a given position in a string.
---
Returns a substring of 1 character beginning at the index specified by the argument passed in. An optional second argument specifies the length of the substring to be returned.
String indices are numbered starting from 0.
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Liquid" | slice: 0 }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Liquid" | slice: 0 }}
```
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Liquid" | slice: 2 }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Liquid" | slice: 2 }}
```
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Liquid" | slice: 2, 5 }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Liquid" | slice: 2, 5 }}
```
If the first parameter is a negative number, the indices are counted from the end of the string:
description:Liquid filter that splits a string into an array using separators.
---
Divides an input string into an array using the argument as a separator. `split` is commonly used to convert comma-separated items from a string to an array.
description:Liquid filter that truncates a string to a given number of characters.
---
`truncate` shortens a string down to the number of characters passed as a parameter. If the number of characters specified is less than the length of the string, an ellipsis (...) is appended to the string and is included in the character count.
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Ground control to Major Tom." | truncate: 20 }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Ground control to Major Tom." | truncate: 20 }}
```
### Custom ellipsis
`truncate` takes an optional second parameter that specifies the sequence of characters to be appended to the truncated string. By default this is an ellipsis (...), but you can specify a different sequence.
The length of the second parameter counts against the number of characters specified by the first parameter. For example, if you want to truncate a string to exactly 10 characters, and use a 3-character ellipsis, use **13** for the first parameter of `truncate`, since the ellipsis counts as 3 characters.
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ "Ground control to Major Tom." | truncate: 25, ", and so on" }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ "Ground control to Major Tom." | truncate: 25, ", and so on" }}
```
### No ellipsis
You can truncate to the exact number of characters specified by the first parameter and show no trailing characters by passing a blank string as the second parameter:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ "Ground control to Major Tom." | truncate: 20, "" }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ "Ground control to Major Tom." | truncate: 20, "" }}
description:Liquid filter that truncates a string to the given number of words.
---
Shortens a string down to the number of words passed as the argument. If the specified number of words is less than the number of words in the string, an ellipsis (...) is appended to the string.
<p class="code-label">Input</p>
```liquid
{% raw %}
{{ "Ground control to Major Tom." | truncatewords: 3 }}
{% endraw %}
```
<p class="code-label">Output</p>
```text
{{ "Ground control to Major Tom." | truncatewords: 3 }}
```
### Custom ellipsis
`truncatewords` takes an optional second parameter that specifies the sequence of characters to be appended to the truncated string. By default this is an ellipsis (...), but you can specify a different sequence.
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ "Ground control to Major Tom." | truncatewords: 3, "--" }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ "Ground control to Major Tom." | truncatewords: 3, "--" }}
```
### No ellipsis
You can avoid showing trailing characters by passing a blank string as the second parameter:
<p class="code-label">Input</p>
{% raw %}
``` liquid
{{ "Ground control to Major Tom." | truncatewords: 3, "" }}
```
{% endraw %}
<p class="code-label">Output</p>
``` text
{{ "Ground control to Major Tom." | truncatewords: 3, "" }}
description:Documentation for the Liquid template language, created by Shopify.
---
{% include home-banner.html %}
Liquid is an open-source template language created by [Shopify](https://www.shopify.com) and written in Ruby. It is the backbone of Shopify themes and is used to load dynamic content on storefronts.
Liquid has been in production use at Shopify since 2006 and is now used by many other hosted web applications.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.