UPDATES: All new article

Migrating from Liquid 1.0 to 2.0

This article describes differences and possible required actions for migrating from the Liquid rendering engine v1.0 to v2.0.

Difference #1: Change in letter case for property names

Some properties inside liquid variables changed their naming (case of letters was changed).
Every property is starting with a capital letter.

If the property name consists of several words then the first letter of each word will be capital.

Example

Change in case of letters in property names

Case differences shown in the Event module JSON and when using jsonResponse=1 in a search URL query for AJAX search.

Change in case of letters in property names

Required Actions

This change will not affect property use in liquid implementation because property access in liquid is case insensitive: {{this['ishome']}} and {{this['IsHome']}} would work in both liquids properly regardless the original property name letters case.

This change will not affect ajax responses inside JS functions IF you are using jsonResponse=1 parameter in the forms action. Or if you are using pure output of the this.formSubmissionData to the page and then parsing it’s content as JSON response

However it will affect ajax responses inside JS functions if you are using liquid output of object in order to retrieve it as a JSON string inside an ajax response (for example for ajax pagination that relies on JSON response).
When such JSON will be parsed to the response object - it will consist of the properties which names will have changed letter case (items, pagination, params properties).
So trying to access them using old lowercase naming will cause an JS error and will break the JS.
So the required action in this case will be to fix old lowercase naming usage to new one.

Difference #2: Some null values were changed to empty strings

Null values of the datasource, ItemTags, ItemCategories were changed to empty string "".

Example

null values were changed to empty strings

Required Actions

This change will not require any action (only if you do not expressly use the fact that null == "" is false. In Liquid 2.0 null becomes "" and such comparison would start to return true).
The purpose of this change is to simplify determining empty field states.

In liquid 1.0 if value was not set then property was equal to null. But if you select any options for the field. Then click save, then cancel your selection and click save - value of the field could become an empty string "".
So in order to simplify determining if field is empty or not there is much easier to just write

{% if testEmpty == "" %} instead of {% if testEmpty == null or testEmpty == "" %}

Here is a comparison results for empty values (you can see that null not equal to empty string "" but empty string "" is equal to null as well as for empty string "")

null - empty comparisons

Difference #3: Parsing flow difference

Liquid 1.0 engine starts parsing layouts starting from item detail content. Then if it finds component tags it goes inside and parses list layouts then goes back to detail layout. When it finished parsing the detail layout it set parsed content to the pageContent variable and then parsed the Page template of the item.
So in this case any variables created inside Page template will not be accessible inside the detail layout and deeper (for example if you are using a custom module named Settings and then using a component to generate a variable with this module item data it the very top of the page template in order to use it anywhere than it will be accessible only within Page Template and not inside the Detail layout and deeper).

Liquid 2.0 engine starts parsing layouts starting from Page template. And when it comes to parse {{pageContent}} it goes to the detail layout passing all variables that are generated in the Page template to the detail layout.
In this case the previous scenario of using a custom module named Settings would forked perfectly.

Required Actions

If you have Pages/Detail views passing Liquid variables up to the template (eg: to populate metadata or other HEAD elements, or to add classes to the BODY...) then you will need to use another method of populating that data. Such as using the {{this}} object directly in the template.

Difference #4: Pages load speed

Liquid 2.0 engine much faster renders {% component type:"module" %} then Liquid 1.0.
As a result, entire pages loaded faster.

Required Actions

No Actions required

Examples

this for the page

Examples

Collection Variable for Modules

When outputting module data via collectionVariable

Examples


Related Articles

  • Working with Liquid
    Treepl has implemented the full standard Shopify Liquid library. See the External Resources below for...
  • Liquid Filters
    Liquid Filters allow you to modify the output of a Liquid object, whether that's adding something to it, removing something from it, executing a calculation, creating an array, or a wide variety of other powerful functions.
  • {{ this }} object
    This Liquid object is globally accessible in every liquid template or layout and outputs specific...
  • {{ request }} object
    This Liquid object is globally accessible in every liquid template or layout and outputs various...
  • {{ liquidContext }} object
    This Liquid object is globally accessible in every liquid template or layout and outputs a...
  • {{ member }} object
    This liquid object will output the Member's details of whom submitted a Form. You can...
  • {{ workflow }} object
    This liquid object will output the Workflow details of a submitted Form. You can use...
  • Part 1: Introduction to Liquid
    This free online course covers every aspect of using the Liquid templating language in Treepl CMS - from the very basics right through to advanced implementations.

    You’re welcome.
  • Part 2: Liquid in Treepl CMS
    In this part of the course we’ll explore how Liquid is implemented in treepl CMS and the overall concepts on using it to harness your website data.
  • Part 3: Using Liquid Filters
    In this part of the course we’ll explore using Liquid Filters to transform and manipulate the display of your Treepl CMS website data.
  • Part 4: Advanced Liquid Tags
  • domain_settings
    This module component retrieves settings associated with the current domain, or optionally from another specified domain configured in the site instance.

External Resources

There are currently no external resources available.

Please let us know if you have any other contributions or know of any helpful resources you'd like to see added here.


Questions?

We are always happy to help with any questions you may have.
Send us a message at support@treepl.co and we will consult you as soon as possible.