Change Log

Improvement

• Protected context.constants: context.constants are now properly protected from accidental leaking. They won’t be visible when you do {{ context }}, you have to explicitly call {{ context.constants }}. Soon, we will add a UI to add/remove them via the Partner Portal.

New Feature

• Added context.device key: It includes information about device type, like desktop, smartphone, etc. Should save you some work.
• Search by ID for admin_* queries: Added the possibility to search by ID for admin_* queries. Also, added metadata to all admin_* resources (possible to set them via GraphQL).
• User session timeout: You can now change the duration of a user session to control when the user timeouts.
• Developer guide icon
• Follow our step-by-step tutorial to learn more about [Updating Instance Configuration and setting the duration of a user session].

Improvement

• Bulk update all data: We have pushed some data import/export improvements. Now, you should be able to use data import to actually bulk update all data, not only the ones which were imported initially.
• Deleting line in yml file: Deleting line in a yml file will work as expected - as if it never has been there, instead of pretending it was not deleted. This bug forced you to explicitly set the property to a blank string instead of just removing it, like for callback_actions in Form, etc. It will be applied only to new Instances, because we did not want to risk breaking your Instances with the next deploy if for some reason you unknowingly relied on this bug. We will add a flag to the Partner Portal soon which would allow you to leverage the bug fix in a controlled way for existing Instances.

New Feature

• Properties for all users: You can now set properties directly in the user object, no need to go through the user profile. You can define properties all users should have via the app/user.yml file.
• Developer guide icon
• Follow our step-by-step tutorial to learn more about [Creating a Property for All Users].
• Liquid in page metadata: Page metadata now accepts Liquid and it will evaluate it for each page render. Same for layout.
• Migration invoked during module installation: Migrations added to the module will now be invoked during module installation, no need to do the full deploy.

Improvement

• Using parse_json filter while keeping your json tidy and formatted forced you to use capture.
• parse_json tag is basically a hybrid of capture and to_hash, it parses json string inside of the tag and converts it to a hash.
• Why would you want to convert your json config to a hash?
• To be able to iterate over it, use filters that will modify the structure, traverse the tree.
• `
• {% parse_json car %}
• {
• "maker": "Honda",
• "model": "CRX",
• "version": "EE8",
• "power": 180
• }
• {% endparse_json %}
• Hash: {{ car }}
• JSON: {{ car | json }}
• Properties:
• {% for property in car -%}
• {{ property[0] }}: {{ property[1] }}
• {% endfor %}
• `
• Result:
• `Hash: {"maker":"Honda","model":"CRX","version":"EE8","power":180}
• JSON: {"maker":"Honda","model":"CRX","version":"EE8","power":180}
• Properties:
• maker: Honda
• model: CRX
• version: EE8
• power: 180
• `
• Usage of parse_json is exactly the same, as a matter of fact, to keep backwards compatibility, to_hash still works.
• `
• {% assign car = '{ "maker": "Honda", "model": "CRX", "version": "EE8", "power": 180 }' %}
• {% assign object = car | parse_json %}
• Maker: {{ car.maker }}
• `
• Result:
• `Maker: Honda
• `

New Feature

• To make your work with json easier we introduced parse_json tag and renamed to_hash filter to parse_json.

Improvement

• Last edit:
• In this release we are answering to community requests and introducing two ways to benchmark performance of your code.
• This filter can be used in many different ways, including:
• calculating how many days from now will an event happen - just pass two dates and unit d for days
• calculating when you have to leave to arrive at train station - just pass two time objects and unit m for minutes
• calculating precisely how long something took - for example, code execution, pass two time objects and unit ms for milliseconds (default)
• You can use time_diff anywhere where liquid is allowed, for example: partials, callbacks.
• You can also measure how long graphql query is taking by putting it between start/stop variables you are measuring.
• To measure speed of code snippet:
• `
• {% assign start = "now" | to_time %}
• {% assign letters = "A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z" | split: "," %}
• {% for letter in letters %}
• • {{ letter }}
• {% endfor %}
• {% assign stop = "now" | to_time %}
• {% assign durationInMS = start | time_diff: stop %}
• {% assign durationInS = start | time_diff: stop, 's' %}
• {% log durationInMS, type: 'render alphabet in a list in milliseconds' %}
• {% log durationInS, type: 'render alphabet in a list in seconds' %}
• `
• Using pos-cli logs command observe what has been logged:
• `[2018-11-15 16:23:33.719Z] - render alphabet in a list in milliseconds: 7.392
• [2018-11-15 16:23:33.741Z] - render alphabet in a list in seconds: 0.007
• `
• [Read more about time_diff filter].
• You can now profile your application per liquid view (including partials) by setting up a enable_profiler: true flag inside your page.

• app/views/pages/my-slow-page.liquid

• `---
• enable_profiler: true

• `
• When the flag is set, whenever you trigger a request to the my-slow-page, two log entries will be added and accessible via the pos-cli logs command.
• The first one shows information about the page, the second one about the layout associated with the page.
• You can use this information to identify slow code and improve it.
• Note
• To avoid noise, the log will include only entries which took longer than 10ms
• `[2018-11-15 17:39:48.733Z] - debug: PROFILING:
• [0.015517108] TOTAL (lvl: 0)
• [0.013081715] if url_params (lvl: 1)
• [0.013057744] include 'designers/all_designers' (lvl: 2)
• [2018-11-15 17:39:48.816Z] - debug: PROFILING:
• [0.067086901] TOTAL (lvl: 0)
• [0.056122558] include 'layouts/header' (lvl: 1)
• [0.055988452] include 'layouts/theme_header' (lvl: 2)
• [0.055747433] if current_user == blank (lvl: 3)
• [0.055718548] include 'layouts/theme_header/signed-in-nav' (lvl: 4)
• [0.050209644] query_graph 'get_unconfirmed_orders_count', result_name: 'g__unconfirmed', receiver_id: context.current_user.id (lvl: 5)
• `
• Warning
• Try to not profile a page on production, as it can result in performance hit. If you absolutely have to, make sure to disable it right after you trigger the request to the page, to minimize the risk of leaving profiling enabled for a long period of time.

Improvement

• Some users reported issues with running very long tasks in async_callback_actions because the task was too slow to execute.
• Before, you had no control or information about limits, errors, timeouts.
• You have full control over priority of your async_callback_actions.
• If you don't set priority at all, it will be set to default.
• You can also set maximum number of attempts if job fails for whatever reason - timeout, error in the code, 3rd party api not responding
• Default is 1. Use it with caution, as every attempt uses resources.
• `
• [...]
• async_callback_actions:
• delay: 10
• priority: low
• max_attempts: 2
• content: >
• {% graphql res = 'long_running_task' %}
• [...]
• `
• Priority
• Timeout
• high
• 1 minute
• default
• 5 minutes
• low
• 4 hours
• Keep them in mind when writing code so that it runs fast enough for its priority.
• Additionally, when a job fails or timeouts it will be logged so you will know when something goes wrong.
• You can access the log using pos-cli logs command.

Improvement

• In this release notes we will focus on new liquid filters, fixed filter and one new feature.
• This filter allows you to add new key-value pairs into existing hash.
• `
• {% assign accountants = "Angela,Kevin,Oscar" | split: "," %}
• {% assign management = "David,Jan,Michael" | split: "," %}
• {% assign company = '{}' | to_hash %}
• {% assign company = company | assign_to_hash_key: "name", "Dunder Mifflin" %}
• {% assign company = company | assign_to_hash_key: "accountants", accountants %}
• {% assign company = company | assign_to_hash_key: "management", management %}
• {{ company }}
• `
• Result:
• `{"name"=>"Dunder Mifflin", "accountants"=>["Angela", "Kevin", "Oscar"], "management"=>["David", "Jan", "Michael"]}
• `
• This filter allows you to sanitize user input before rendering it and at the same time decide which attributes should not be sanitized.
• `
• {% capture link %}
• Link
• {% endcapture %}
• {{ link | sanitize }} => Link
• {% assign whitelist_attributes = 'target' | split: '|' %}
• {{ link | sanitize: whitelist_attributes }}
• `
• Result:
• `Link
• `
• There was a community request to make it easier to access useragent and parse it, so here it is.
• You can access useragent string (as you normally could in the past)
• This filter takes useragent string as an input and returns object with parsed data about it.
• `
• {{ context.headers.HTTP_USER_AGENT | useragent }}
• `
• You can use json filter for readability:
• `
• {{ context.headers.HTTP_USER_AGENT | useragent | json }}
• `
• This filter was returning string that was longer than expected. Now it returns string of length that you want.
• `
• {{ 10 | random_string }} => '6a1e7e2629'
• {{ 2 | random_string }} => '8b'
• `
• You have the possibility to send binary files in API call. This might be useful when integrating your system with external APIs that require additional data from your users, for example photo.
• Read guide [Sending a Binary File Using an API Call Notification] to learn more.

New Feature

• Last edit:

Improvement

• We are introducing two filters to allow you usage of [JSON Web Tokens].
• Valid options for algorithm:
• none - unsigned token
• HS256 - HMAC using SHA-256
• HS384 - HMAC using SHA-384
• HS512 - HMAC using SHA-512
• RS256 - RSA using SHA-256
• RS384 - RSA using SHA-384
• RS512 - RSA using SHA-512
• Example:
• `
• {{ payload | jwt_encode: 'HS256', 'this-is-secret' }} => 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkiOiJ2YWx1ZSIsImFub3RoZXJfa2V5IjoiYW5vdGhlciB2YWx1ZSJ9.XT8sHXyPTA9DoHzssXh1q6Uv2D1ENosW0F3Ixle85L0'
• `
• Valid options for algorithm:
• none - unsigned token
• HS256 - HMAC using SHA-256
• HS384 - HMAC using SHA-384
• HS512 - HMAC using SHA-512
• RS256 - RSA using SHA-256
• RS384 - RSA using SHA-384
• RS512 - RSA using SHA-512
• Examples:
• `
• {% assign original_payload = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkiOiJ2YWx1ZSIsImFub3RoZXJfa2V5IjoiYW5vdGhlciB2YWx1ZSJ9.XT8sHXyPTA9DoHzssXh1q6Uv2D1ENosW0F3Ixle85L0' | jwt_decode: 'HS256', 'this-is-secret' }} =>
• [
• {
• "key" => "value",
• "another_key" => "another value"
• },
• {
• "typ" => "JWT",
• "alg" => "HS256"
• }
• ]
• `
• `
• {% capture public_key %}
  -----BEGIN PUBLIC KEY-----
• MIIBI...
  -----END PUBLIC KEY-----
• {% endcapture %}
• {% assign original_payload = 'some encoded token' | jwt_decode: 'RS256', public_key %}
• `
• Read more at our [Liquid filters documentation].
• Errors shown by [pos-cli logs] are now more detailed. It should help you debug your application.
• Example:
• `
• [2018-09-03 13:59:29.049Z] - Liquid::ArgumentError: jwt_encode filter - first argument must be a hash or a string, received:
• page: pages/release-notes/2018-09-03
• `

Improvement

• New tag allows you to use normal liquid syntax to pass variables. render_form tag is now deprecated.
• `
• {% render_form edit_user, id: @user.id %}
• `
• now should be written with
• `
• {% include_form 'edit_user', id: user.id %}
• `
• Warning
• You have to quote form name and you do not include "@" when passing variable.
• Until now you had log mutation at your disposal, but it was a lot of work to use for such a simple task.
• From now on please use log tag to print something to logs.
• `
• {% log "hello world" %}
• {% log params %}
• {% log params, type: 'error' %}
• `
• Note
• Default type is info.

New Feature

• Last edit: