Change Log

  • 15-May-2022 | v6.6.0 | Added section explaining use of `params` in the `request` object.
  • 16-Apr-2021 | v5.9.0 | Added instructions for accessing secure zone data from the `currentmember` object and updated the `currentmember` object data output.
  • Added more detail for the 'device_type' property. Added examples of viewing Liquid object data while developing.

Contributors:

Adam Wilson - Logo Pogo

{{ request }} object

This Liquid object is globally accessible in every liquid template or layout and outputs various data relating to your site.

{{ request }}

Liquid Output

An live render of the data output is below.

{
  "cookies": {},
  "request_url": {
    "href": "https://treepl-docs-v7.treepl.co/liquid/request-object",
    "origin": "https://treepl-docs-v7.treepl.co",
    "protocol": "https",
    "hostname": "treepl-docs-v7.treepl.co",
    "path": "/liquid/request-object",
    "params": {},
    "originalParams": {}
},
  "request_data": {
    "ip": "3.73.58.164",
    "is_mobile": 0,
    "user_agent": "axios/1.8.2",
    "referrer": ""
},
  "currentmember": "",
  "is_logged": false,
  "device_type": "Desktop",
  "timezone": {
    "label": "(UTC-06:00) Central Time (Chicago)",
    "offset": -5.0
},
  "system_recaptcha_sitekey": "6Lf2cGcUAAAAABbL4aDrclASNZx9S3uaI9EvpvlI"
}

currentmember

When a user is logged in to a secure zone, the request.currentmember property (part of the request object) will return the logged in member's data. An example is below:

{
    "is_logged": true,
    "currentmember": {
        "id": 162,
        "email": "asmith@example.com",
        "firstname": "Alex",
        "lastname": "Smith",
        "address": null,
        "city": null,
        "state": null,
        "zipcode": null,
        "country": "Australia",
        "site": null,
        "phone": null,
        "status": "",
        "notes": "",
        "type": 2,
        "stripecustomerportallink": "https://YOUR-SITE.webinone.com/public/api/stripe/create-customer-portal-session",
        "isDataUsingAllowed": true,
        "createddatetime": "9/11/2019 3:32:23 AM",
        "updateddatetime": "3/24/2021 2:44:32 AM",
        "securezones": [
            {
            "id": 2,
            "name": "Members Secure Zone",
            "landingpageid": 2541,
            "createddatetime": "2018-11-21T15:17:23.037",
            "updateddatetime": "2018-11-21T15:17:23.037",
            "expirydatetime": "9999-12-30T13:00:00"
            }
        ]
    }
}

To access data within the securezones array you can use a forloop to loop through each secure zone item.
So we might render a list of available secure zones and their expiry dates, like so:

<ul>
{% for zone in request.currentmember.securezones %}
    <li>{{zone.name}} (Expiry: {{zone.expirydatetime | date}})</li>
{% endfor %}
</ul>

Rendering the following details:

  • Members Secure Zone (Expiry: 30-Dec-9999)

device_type

The possible values provided by the device_type property are:

  • Desktop: when a desktop browser is rendering the page.
  • Tablet: when a tablet browser is rendering the page.
  • Mobile: when a mobile/smart phone browser is rendering the page.

A typical use case for this property is to display different content depending on the users device.

The following Liquid example will render different results on the three different device types:

{% case request.device_type %}
{% when 'Mobile' %}
    <p>I'm mobile</p>
{% when 'Tablet' %}
    <p>I'm an iPad or similar tablet.</p>
{% else %}
    <p>I must be a desktop.</p>
{% endcase %}

When using the output values in Liquid logic they are case sensitive. So, {% if request.device_type == "desktop" %}... will not work, whereas {% if request.device_type == "Desktop" %}... will work.

params

‘Params’ refers to any URL Parameters being passed in the current page URL. These are also sometimes called ‘Query Strings’.

URL Parameters can be used to pass addition or variable information to a page. This information might be specific to the user or carry some data from the previous page the user has come from.

A common use case is for analytical tracking and/or personalisation of the page based on a marketing campaign link, say, from an email campaign.

So the user might receive an email campaign with a link to your landing page and the link has been constructed to contain the user's name and campaign ID - so you can use their name to personalise your website landing page and use the ID in your analytics tracking script.

Using Liquid we can extract those URL parameters and render them into your page at time of page load.

Constructed link example:

<a href="https://www.yoursite.com/landing-page?fname=Joe&lname=Smith&campid=12345">Visit Landing Page</a>

Take particular notice of the URL Parameter structure added to the landing page path:

?fname=Joe&lname=Smith&campid=12345

The request object will contain each of the URL Parameter’s key/value pairs.

So using the following Liquid tag will give us access to all the URL Parameters:

{{request.request_url.params}}
{
    "fname": "Joe",
    "lname": "Smith",
    "campid": "12345"
}

Therefore, you could render the user’s first name into the page heading, for example:

<h1>Welcome {{request.request_url.params.fname}}</h1>
<h1>Welcome Joe</h1>

For more information on URL Parameters/Query Strings check the External Resources section below for relevant links.

Accessing the Data

JSON Output

You can output the full JSON for your component data by referencing the root Liquid object {{this}} in your module’s layouts, or directly on your page, if using the collectionVariable parameter in your component tag.

For example:

{% component type: ... collectionVariable: "myData" %}

You can then render the JSON like so:

{{myData}}

For more details on using this approach, see Part 2 of the free ‘Learning Liquid Course’.

Rendering Property Values

As an example of rendering a desired value to the page you could use the following Liquid:

{{ request.request_data.is_mobile }}

This would output the value 0 to the page based on the above example data.

By the way, the is_mobile property is a boolean indicating whether the device being used is a mobile device or not. Where 0 indicated it is not a mobile device and 1 indicated it is a mobile device.

Extending on this example, we can use this value in a conditional Liquid statement to display different content on a page for mobile devices like so:

{% if request.request_data.is_mobile == 1 %}
    <p>You're viewing mobile enabled content!</p>
{% else %}
    <p>You're viewing desktop content!</p>
{% endif %}

Viewing Data while Developing

It is often desirable to see all the data that is available to you on a page while developing your applications and there are two common techniques for doing this.

1. Rendering JSON to the Page

You can quickly and easily render the full JSON output directly to the page you are working on in order to view all the data and its structure in an easy to read format.
Simply wrap your desired Liquid object in <pre> tags like so; <pre>{{request}}</pre>

A JSON representation of the available data will be rendered to the page similar to the output examples above.

This of course is a temporary technique as you would not want to leave the JSON data visible on the page.

2. Rendering JSON to the Console

Perhaps a cleaner and more persistent way of viewing this data while in development, is to log the JSON output to your browser's console (in the browser's Developer Tools).

To do this, add some javascript code to your template file (just before the closing </body> tag) like this:

<script>
    console.log({{request}});
</script>

What this will do is output the JSON data into a structured data tree in your browser's Developer Tools console.

You can actually use this method to log any Liquid data to the console, such as a custom collection, for example:

<script>
    console.log({{myCustomCollection | strip_html}});
</script>

You might notice the Liquid filter | strip_html added here. This is optional, however, in some cases the JSON data will contain HTML code and this can break the Javascript, causing a scripting error.
So, keep in mind that, when using this filter, any fields containing HTML code in your JSON will not actually show the HTML in the console, however, the data is still there and accessible via Liquid when rendering to the page.

Remember to remove this code for production as it could pose a data security risk and it is best practice not to leave console logs in your scripts.