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."
repository:https://github.com/Shopify/liquid
# Build settings
baseurl:""# the subpath of your site, e.g. /blog/
url:http://liquidmarkup.org# the base hostname & protocol for your site
A handle is used to access the attributes of a Liquid object. By default, the handle is the object's title in lowercase with any spaces and special characters replaced by hyphens (-).
For example, a page with the title "About Us" can be accessed in Liquid via its handle `about-us` as shown below:
{% highlight liquid %}
{% raw %}
<!-- the content of the About Us page -->
{{ pages.about-us.content }}
{% endraw %}
{% endhighlight %}
## Creating handles
An object with the title "Shirt" will automatically be given the handle `shirt`. If there is already an object with the handle `shirt`, the handle will auto-increment. In other words, "Shirt" objects created after the first one will receive the handle `shirt-1`, `shirt-2`, and so on.
Whitespace in titles is replaced by hyphens in handles. For example, the title "My Shiny New Title" will be given the handle `my-shiny-new-title`.
Handles also determine the URL of their corresponding objects. For example, a page with the handle `about-us` would have the url `/pages/about-us`.
Websites often rely on static handles for pages, posts, or objects. To preserve design elements and avoid broken links, if you modify the title of an object, **its handle is not automatically updated**. For example, if you were to change a page title from "About Us" to "About This Website", its handle would still be `about-us`.
You can change an object's handle manually (TK how to change a handle manually)
## Accessing handle attributes
In many cases you may know the handle of a object whose attributes you want to access. You can access its attributes by pluralizing the name of the object, then using either the square bracket ( [ ] ) or dot ( . ) notation.
<div class="code-block code-block--input">
{% highlight liquid %}
{% raw %}
{{ pages.about-us.title }}
{{ pages["about-us"].title }}
{% endraw %}
{% endhighlight %}
</div>
<div class="code-block code-block--output">
{% highlight text %}
About Us
About Us
{% endhighlight %}
</div>
In the example above, notice that we are using `pages` as opposed to `page`.
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 %}`.
```liquid
{% raw %}
{{ page.title }}
{% endraw %}
```
```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.
```liquid
{% raw %}
{% if user %}
Hello {{ user.name }}!
{% endif %}
{% endraw %}
```
```text
Hello Adam!
```
Tags can be categorized into three types:
- [Control flow](/tags/control-flow)
- [Iteration](/tags/iteration)
- [Variable assignments](/tags/variable)
You can read more about each type of tag in their respective sections.
## Filters
**Filters** change the output of a Liquid object. They are using within an output and are separated by a `|`.
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 == true %}
This condition will always be true.
{% endif %}
{% endraw %}
```
[Strings](/basics/types/#string), even when empty, are truthy. The example below will result in empty HTML tags if `settings.fp_heading` is empty:
```liquid
{% raw %}
{% if settings.fp_heading %}
<h1>{{ settings.fp_heading }}</h1>
{% endif %}
{% endraw %}
```
```html
<h1></h1>
```
[EmptyDrops](/basics/types/#emptydrop) are also truthy. In the example below, if `settings.page` is an empty string or set to a hidden or deleted object, you will end up with an EmptyDrop. The result is an empty `div`:
```liquid
{% raw %}
{% if pages[settings.page] %}
<div>{{ pages[settings.page].content }}</div>
{% endif %}
{% endraw %}
```
```html
<div></div>
```
## Falsy
The falsy values in Liquid are [`nil`](/basics/types/#nil) and [`false`](/basics/types/#boolean).
## Summary
The table below summarizes what is truthy or falsy in Liquid.
You can initialize Liquid variables with the [assign](/tags/#assign) or [capture](/tags/#capture) 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) 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.
```liquid
{% raw %}
The current user is {{ user.name }}
{% endraw %}
```
```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/).
```liquid
{% raw %}
<!-- if site.users = "Tobi", "Laura", "Tetsuro", "Adam" -->
{% for user in site.users %}
{{ user }}
{% endfor %}
{% endraw %}
```
```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.
```liquid
{% raw %}
<!-- if site.users = "Tobi", "Laura", "Tetsuro", "Adam" -->
{{ site.users[0] }}
{{ site.users[1] }}
{{ site.users[3] }}
{% endraw %}
```
```text
Tobi
Laura
Adam
```
### Initializing arrays
You cannot initialize arrays using only Liquid.
You can, however, use the [split](/filters/split) filter to break a string into an array of substrings.
## EmptyDrop
An EmptyDrop object is returned if you try to access a deleted object by name. In the example below, `page_1`, `page_2` and `page_3` are all EmptyDrop objects.
EmptyDrop objects only have one attribute, `empty?`, which is always *true*.
Collections and pages that *do* exist do not have an `empty?` attribute. Their `empty?` is "falsy", which means that calling it inside an if statement will return *false*. When using an `unless` statement on existing collections and pages, `empty?` will return `true`.
### Checking for emptiness
Using the `empty?` attribute, you can check to see if an object exists or not before you access any of its attributes.
```liquid
{% raw %}
{% unless pages.about.empty? %}
<!-- This will only print if the page with handle 'about' is not empty -->
<h1>{{ pages.frontpage.title }}</h1>
<div>{{ pages.frontpage.content }}</div>
{% endunless %}
{% endraw %}
```
If you don't check for emptiness first, Liquid might print empty HTML elements to the page:
[{'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."
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.
```liquid
{% raw %}
{{ "Have you read 'James & the Giant Peach'?" | escape }}
{% endraw %}
```
```text
{{ "Have you read 'James & the Giant Peach'?" | escape }}
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:
```liquid
{% raw %}
{{ "Ground control to Major Tom." | split: "" | reverse | join: "" }}
{% endraw %}
```
```text
{{ "Ground control to Major Tom." | split: "" | reverse | join: "" }}
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.
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.
```liquid
{% raw %}
{{ "Liquid" | slice: 0 }}
{% endraw %}
```
```text
{{ "Liquid" | slice: 0 }}
```
```liquid
{% raw %}
{{ "Liquid" | slice: 2 }}
{% endraw %}
```
```text
{{ "Liquid" | slice: 2 }}
```
```liquid
{% raw %}
{{ "Liquid" | slice: 2, 5 }}
{% endraw %}
```
```text
{{ "Liquid" | slice: 2, 5 }}
```
If the first parameter is a negative number, the indices are counted from the end of the string:
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.
`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.
```liquid
{% raw %}
{{ "Ground control to Major Tom." | truncate: 20 }}
{% endraw %}
```
```text
{{ "Ground control to Major Tom." | truncate: 20 }}
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.
```liquid
{% raw %}
{{ "Ground control to Major Tom." | truncatewords: 3 }}
{% endraw %}
```
```text
{{ "Ground control to Major Tom." | truncatewords: 3 }}
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 since June 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.