Liquid template engine

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.

What does it look like?


  {% for product in products %}

- ## {{ product.name }}

      Only {{ product.price | price }}

      {{ product.description | prettyprint | paragraph }}
  {% endfor %}

How to use Liquid

Install Liquid by adding gem 'liquid' to your gemfile.

Liquid supports a very simple API based around the Liquid::Template class.
For standard use you can just pass it the content of a file and call render with a parameters hash.

@template = Liquid::Template.parse("hi {{name}}") # Parses and compiles the template
@template.render('name' => 'tobi')                # => "hi tobi"

Concept of Environments

In Liquid, a "Environment" is a scoped environment that encapsulates custom tags, filters, and other configurations. This allows you to define and isolate different sets of functionality for different contexts, avoiding global overrides that can lead to conflicts and unexpected behavior.

By using environments, you can:

Encapsulate Logic: Keep the logic for different parts of your application separate.
Avoid Conflicts: Prevent custom tags and filters from clashing with each other.
Improve Maintainability: Make it easier to manage and understand the scope of customizations.
Enhance Security: Limit the availability of certain tags and filters to specific contexts.

We encourage the use of Environments over globally overriding things because it promotes better software design principles such as modularity, encapsulation, and separation of concerns.

Here's an example of how you can define and use Environments in Liquid:

user_environment = Liquid::Environment.build do |environment|
  environment.register_tag("renderobj", RenderObjTag)
end

Liquid::Template.parse( [#, #]

template = Liquid::Template.parse("{{x | filter1 | upcase}}")
template.render({ 'x' => 'foo' }, { strict_filters: true })
#=> '' # when at least one filter in the filter chain is undefined, a whole expression is rendered as nil
template.errors
#=> [#]

If you want to raise on a first exception instead of pushing all of them in errors, you can use render! method:

template = Liquid::Template.parse("{{x}} {{y}}")
template.render!({ 'x' => 1}, { strict_variables: true })
#=> Liquid::UndefinedVariable: Liquid error: undefined variable y

Usage tracking

To help track usages of a feature or code path in production, we have released opt-in usage tracking. To enable this, we provide an empty Liquid:: Usage.increment method which you can customize to your needs. The feature is well suited to https://github.com/Shopify/statsd-instrument. However, the choice of implementation is up to you.

Once you have enabled usage tracking, we recommend reporting any events through Github Issues that your system may be logging. It is highly likely this event has been added to consider deprecating or improving code specific to this event, so please raise any concerns.

README