Pages
Last edit: Jan 18, 2019
Contributors:
Pages are the most essential components of our platform, that define content displayed at a given path. All pages have to be located in the views/pages directory. Each page is represented by a single file with liquid extension.
Page configuration
See below a sample page configuration file, with explanations for each element:
views/pages/my-page.html.liquid
---
slug: my-page
layout_name: my_custom_layout
---
<h1>Welcome to My Page</h1>
<p>A paragraph explaining what I do.</p>
Available properties
| Property | Description | Options | Default | Required |
|---|---|---|---|---|
| authorization_policies | Array of authorization policies run before rendering the page | No | ||
| converter | markdown | No | ||
| format | html xml csv json rss css js txt |
html | No | |
| handler | No | |||
| layout_name | Defines which layout from views/layouts/ you would like to use. If you don't want to use any layout, set it to empty string. It will be equivalent to just rendering page content. Note: Currently, excluding this property altogether will cause the page to use the layout last used for the current page. If no layout has been used, it will use the default application layout. |
application |
No | |
| max_deep_level | Defines what is the intended nesting level of the slug. For example, if the slug is test and you set max deep level to 1, then path like /test/something will raise 404. However, if you set it to 2, then it will render the page. This is useful for SEO to avoid duplicated content. |
positive integer | No | |
| metadata | Object that you can define and access via context.page.metadata in different places |
No | ||
| method | get post put delete |
get | No | |
| redirect_code | Status that should be added to http response | 301 302 |
302 | No |
| redirect_to | URL to a page you want to redirect | No | ||
| response_headers | JSON object that you can define to override most of the http headers | No | ||
| searchable | Indication that this page should be indexed and accessed via graphql query | true | false | No |
| slug | Defines the URL at which this page will be accessible. Assuming your site domain is https://example.com, you will be able to access the page at https://example.com/[slug] |
n/a | Yes |
Everything after the front matter is the body of the page.
Homepage
The Homepage slug is /, which will work for both https://example.com and https://example.com/. See this sample file for configuring the home page:
views/pages/home.html.liquid
---
slug: /
---
<h1>Welcome to my home page</h1>
<p>A paragraph explaining what we do</p>
Formats
To define which format the endpoint will be available for, place .<format> before the file extension.
| Format name | Example filename |
|---|---|
| html | about-us.html.liquid |
| xml | orders.xml.liquid |
| csv | users-report.csv.liquid |
| json | coordinates.json.liquid |
| rss | feed.rss.liquid |
| css | datepicker.css.liquid |
| js | server-constants.js.liquid |
| purchase-order.pdf.liquid | |
| txt | notes.txt.liquid |
Accessing different formats
You can have multiple pages with the same slug, but with different formats, and access them at the same time.
For example, you can have both html, pdf and txt version of a page with Hello world:
views/pages/hello.html.liquid
---
slug: hello
---
Hello world
views/pages/hello.pdf.liquid
---
slug: hello
---
Hello world
views/pages/hello.txt.liquid
---
slug: hello
---
Hello world
Those will be accessible under the URLs:
https://example.com/hellohttps://example.com/hello.pdfhttps://example.com/hello.txt
Note that the html format is implicit, default, you don't need to specify it in the URL.
Related topics
Questions?
We are always happy to help with any questions you may have. Check out our Help page, or contact us.