2017-09-27 14:37:17 +00:00
+++
title = "Overview"
weight = 10
+++
2019-11-26 19:30:30 +00:00
Zola uses the [Tera ](https://tera.netlify.com ) template engine, which is very similar
to Jinja2, Liquid and Twig.
2017-10-19 11:48:50 +00:00
2018-10-18 21:09:32 +00:00
As this documentation will only talk about how templates work in Zola, please read
2019-12-10 06:00:58 +00:00
the [Tera template documentation ](https://tera.netlify.com/docs#templates ) if you want
2017-10-19 11:48:50 +00:00
to learn more about it first.
2017-09-27 14:37:17 +00:00
2019-11-26 19:30:30 +00:00
All templates live in the `templates` directory. If you are not sure what variables are available in a template,
you can place `{{ __tera_context }}` in the template to print the whole context.
2017-09-27 14:37:17 +00:00
Support and default to generating Atom feeds
This includes several breaking changes, but they’re easy to adjust for.
Atom 1.0 is superior to RSS 2.0 in a number of ways, both technical and
legal, though information from the last decade is hard to find.
http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared
has some info which is probably still mostly correct.
How do RSS and Atom compare in terms of implementation support? The
impression I get is that proper Atom support in normal content websites
has been universal for over twelve years, but that support in podcasts
was not quite so good, but getting there, over twelve years ago. I have
no more recent facts or figures; no one talks about this stuff these
days. I remember investigating this stuff back in 2011–2013 and coming
to the same conclusion. At that time, I went with Atom on websites and
RSS in podcasts. Now I’d just go full Atom and hang any podcast tools
that don’t support Atom, because Atom’s semantics truly are much better.
In light of all this, I make the bold recommendation to default to Atom.
Nonetheless, for compatibility for existing users, and for those that
have Opinions, I’ve retained the RSS template, so that you can escape
the breaking change easily.
I personally prefer to give feeds a basename that doesn’t mention “Atom”
or “RSS”, e.g. “feed.xml”. I’ll be doing that myself, as I’ll be using
my own template with more Atom features anyway, like author information,
taxonomies and making the title field HTML.
Some notes about the Atom feed template:
- I went with atom.xml rather than something like feed.atom (the .atom
file format being registered for this purpose by RFC4287) due to lack
of confidence that it’ll be served with the right MIME type. .xml is a
safer default.
- It might be nice to get Zola’s version number into the <generator>
tag. Not for any particularly good reason, y’know. Just picture it:
<generator uri="https://www.getzola.org/" version="0.10.0">
Zola
</generator>
- I’d like to get taxonomies into the feed, but this requires exposing a
little more info than is currently exposed. I think it’d require
`TaxonomyConfig` to preferably have a new member `permalink` added
(which should be equivalent to something like `config.base_url ~ "/" ~
taxonomy.slug ~ "/"`), and for the feed to get all the taxonomies
passed into it (`taxonomies: HashMap<String, TaxonomyTerm>`).
Then, the template could be like this, inside the entry:
{% for taxonomy, terms in page.taxonomies %}
{% for term in terms %}
<category scheme="{{ taxonomies[taxonomy].permalink }}"
term="{{ term.slug }}" label="{{ term.name }}" />
{% endfor %}
{% endfor %}
Other remarks:
- I have added a date field `extra.updated` to my posts and include that
in the feed; I’ve observed others with a similar field. I believe this
should be included as an official field. I’m inclined to add author to
at least config.toml, too, for feeds.
- We need to have a link from the docs to the source of the built-in
templates, to help people that wish to alter it.
2019-08-11 10:25:24 +00:00
A few variables are available on all templates except feeds and the sitemap:
2017-09-27 14:37:17 +00:00
2019-05-27 12:35:14 +00:00
- `config` : the [configuration ](@/documentation/getting-started/configuration.md ) without any modifications
2020-07-29 18:44:09 +00:00
- `current_path` : the path (full URL without `base_url` ) of the current page, always starting with a `/`
2019-11-26 19:30:30 +00:00
- `current_url` : the full URL for the current page
2020-04-12 17:17:29 +00:00
- `lang` : the language for the current page
2017-09-27 14:37:17 +00:00
2020-04-12 16:48:00 +00:00
Config variables can be accessed like `config.variable` , in HTML for example with `{{ config.base_url }}` .
2019-11-26 19:30:30 +00:00
The 404 template does not get `current_path` and `current_url` (this information cannot be determined).
2019-05-01 21:06:02 +00:00
2019-11-26 19:30:30 +00:00
## Standard templates
2018-10-18 21:09:32 +00:00
By default, Zola will look for three templates: `index.html` , which is applied
2018-07-31 14:35:16 +00:00
to the site homepage; `section.html` , which is applied to all sections (any HTML
page generated by creating a directory within your `content` directory); and
2019-11-26 19:30:30 +00:00
`page.html` , which is applied to all pages (any HTML page generated by creating an
2018-07-16 06:49:26 +00:00
`.md` file within your `content` directory).
The homepage is always a section (regardless of whether it contains other pages).
2018-07-31 14:35:16 +00:00
Thus, the `index.html` and `section.html` templates both have access to the
2018-07-16 06:49:26 +00:00
section variables. The `page.html` template has access to the page variables.
2019-11-26 19:30:30 +00:00
The page and section variables are described in more detail in the next section.
2018-07-16 06:49:26 +00:00
2019-11-26 19:30:30 +00:00
## Built-in templates
Support and default to generating Atom feeds
This includes several breaking changes, but they’re easy to adjust for.
Atom 1.0 is superior to RSS 2.0 in a number of ways, both technical and
legal, though information from the last decade is hard to find.
http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared
has some info which is probably still mostly correct.
How do RSS and Atom compare in terms of implementation support? The
impression I get is that proper Atom support in normal content websites
has been universal for over twelve years, but that support in podcasts
was not quite so good, but getting there, over twelve years ago. I have
no more recent facts or figures; no one talks about this stuff these
days. I remember investigating this stuff back in 2011–2013 and coming
to the same conclusion. At that time, I went with Atom on websites and
RSS in podcasts. Now I’d just go full Atom and hang any podcast tools
that don’t support Atom, because Atom’s semantics truly are much better.
In light of all this, I make the bold recommendation to default to Atom.
Nonetheless, for compatibility for existing users, and for those that
have Opinions, I’ve retained the RSS template, so that you can escape
the breaking change easily.
I personally prefer to give feeds a basename that doesn’t mention “Atom”
or “RSS”, e.g. “feed.xml”. I’ll be doing that myself, as I’ll be using
my own template with more Atom features anyway, like author information,
taxonomies and making the title field HTML.
Some notes about the Atom feed template:
- I went with atom.xml rather than something like feed.atom (the .atom
file format being registered for this purpose by RFC4287) due to lack
of confidence that it’ll be served with the right MIME type. .xml is a
safer default.
- It might be nice to get Zola’s version number into the <generator>
tag. Not for any particularly good reason, y’know. Just picture it:
<generator uri="https://www.getzola.org/" version="0.10.0">
Zola
</generator>
- I’d like to get taxonomies into the feed, but this requires exposing a
little more info than is currently exposed. I think it’d require
`TaxonomyConfig` to preferably have a new member `permalink` added
(which should be equivalent to something like `config.base_url ~ "/" ~
taxonomy.slug ~ "/"`), and for the feed to get all the taxonomies
passed into it (`taxonomies: HashMap<String, TaxonomyTerm>`).
Then, the template could be like this, inside the entry:
{% for taxonomy, terms in page.taxonomies %}
{% for term in terms %}
<category scheme="{{ taxonomies[taxonomy].permalink }}"
term="{{ term.slug }}" label="{{ term.name }}" />
{% endfor %}
{% endfor %}
Other remarks:
- I have added a date field `extra.updated` to my posts and include that
in the feed; I’ve observed others with a similar field. I believe this
should be included as an official field. I’m inclined to add author to
at least config.toml, too, for feeds.
- We need to have a link from the docs to the source of the built-in
templates, to help people that wish to alter it.
2019-08-11 10:25:24 +00:00
Zola comes with four built-in templates: `atom.xml` and `rss.xml` (described in
2020-08-12 07:20:16 +00:00
[Feeds ](@/documentation/templates/feeds/index.md )), `sitemap.xml` (described in [Sitemap ](@/documentation/templates/sitemap.md )),
Support and default to generating Atom feeds
This includes several breaking changes, but they’re easy to adjust for.
Atom 1.0 is superior to RSS 2.0 in a number of ways, both technical and
legal, though information from the last decade is hard to find.
http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared
has some info which is probably still mostly correct.
How do RSS and Atom compare in terms of implementation support? The
impression I get is that proper Atom support in normal content websites
has been universal for over twelve years, but that support in podcasts
was not quite so good, but getting there, over twelve years ago. I have
no more recent facts or figures; no one talks about this stuff these
days. I remember investigating this stuff back in 2011–2013 and coming
to the same conclusion. At that time, I went with Atom on websites and
RSS in podcasts. Now I’d just go full Atom and hang any podcast tools
that don’t support Atom, because Atom’s semantics truly are much better.
In light of all this, I make the bold recommendation to default to Atom.
Nonetheless, for compatibility for existing users, and for those that
have Opinions, I’ve retained the RSS template, so that you can escape
the breaking change easily.
I personally prefer to give feeds a basename that doesn’t mention “Atom”
or “RSS”, e.g. “feed.xml”. I’ll be doing that myself, as I’ll be using
my own template with more Atom features anyway, like author information,
taxonomies and making the title field HTML.
Some notes about the Atom feed template:
- I went with atom.xml rather than something like feed.atom (the .atom
file format being registered for this purpose by RFC4287) due to lack
of confidence that it’ll be served with the right MIME type. .xml is a
safer default.
- It might be nice to get Zola’s version number into the <generator>
tag. Not for any particularly good reason, y’know. Just picture it:
<generator uri="https://www.getzola.org/" version="0.10.0">
Zola
</generator>
- I’d like to get taxonomies into the feed, but this requires exposing a
little more info than is currently exposed. I think it’d require
`TaxonomyConfig` to preferably have a new member `permalink` added
(which should be equivalent to something like `config.base_url ~ "/" ~
taxonomy.slug ~ "/"`), and for the feed to get all the taxonomies
passed into it (`taxonomies: HashMap<String, TaxonomyTerm>`).
Then, the template could be like this, inside the entry:
{% for taxonomy, terms in page.taxonomies %}
{% for term in terms %}
<category scheme="{{ taxonomies[taxonomy].permalink }}"
term="{{ term.slug }}" label="{{ term.name }}" />
{% endfor %}
{% endfor %}
Other remarks:
- I have added a date field `extra.updated` to my posts and include that
in the feed; I’ve observed others with a similar field. I believe this
should be included as an official field. I’m inclined to add author to
at least config.toml, too, for feeds.
- We need to have a link from the docs to the source of the built-in
templates, to help people that wish to alter it.
2019-08-11 10:25:24 +00:00
and `robots.txt` (described in [Robots.txt ](@/documentation/templates/robots.md )).
2018-07-31 14:35:16 +00:00
Additionally, themes can add their own templates, which will be applied if not
2018-07-16 06:49:26 +00:00
overridden. You can override built-in or theme templates by creating a template with
Support and default to generating Atom feeds
This includes several breaking changes, but they’re easy to adjust for.
Atom 1.0 is superior to RSS 2.0 in a number of ways, both technical and
legal, though information from the last decade is hard to find.
http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared
has some info which is probably still mostly correct.
How do RSS and Atom compare in terms of implementation support? The
impression I get is that proper Atom support in normal content websites
has been universal for over twelve years, but that support in podcasts
was not quite so good, but getting there, over twelve years ago. I have
no more recent facts or figures; no one talks about this stuff these
days. I remember investigating this stuff back in 2011–2013 and coming
to the same conclusion. At that time, I went with Atom on websites and
RSS in podcasts. Now I’d just go full Atom and hang any podcast tools
that don’t support Atom, because Atom’s semantics truly are much better.
In light of all this, I make the bold recommendation to default to Atom.
Nonetheless, for compatibility for existing users, and for those that
have Opinions, I’ve retained the RSS template, so that you can escape
the breaking change easily.
I personally prefer to give feeds a basename that doesn’t mention “Atom”
or “RSS”, e.g. “feed.xml”. I’ll be doing that myself, as I’ll be using
my own template with more Atom features anyway, like author information,
taxonomies and making the title field HTML.
Some notes about the Atom feed template:
- I went with atom.xml rather than something like feed.atom (the .atom
file format being registered for this purpose by RFC4287) due to lack
of confidence that it’ll be served with the right MIME type. .xml is a
safer default.
- It might be nice to get Zola’s version number into the <generator>
tag. Not for any particularly good reason, y’know. Just picture it:
<generator uri="https://www.getzola.org/" version="0.10.0">
Zola
</generator>
- I’d like to get taxonomies into the feed, but this requires exposing a
little more info than is currently exposed. I think it’d require
`TaxonomyConfig` to preferably have a new member `permalink` added
(which should be equivalent to something like `config.base_url ~ "/" ~
taxonomy.slug ~ "/"`), and for the feed to get all the taxonomies
passed into it (`taxonomies: HashMap<String, TaxonomyTerm>`).
Then, the template could be like this, inside the entry:
{% for taxonomy, terms in page.taxonomies %}
{% for term in terms %}
<category scheme="{{ taxonomies[taxonomy].permalink }}"
term="{{ term.slug }}" label="{{ term.name }}" />
{% endfor %}
{% endfor %}
Other remarks:
- I have added a date field `extra.updated` to my posts and include that
in the feed; I’ve observed others with a similar field. I believe this
should be included as an official field. I’m inclined to add author to
at least config.toml, too, for feeds.
- We need to have a link from the docs to the source of the built-in
templates, to help people that wish to alter it.
2019-08-11 10:25:24 +00:00
the same name in the correct path. For example, you can override the Atom template by
creating a `templates/atom.xml` file.
2018-07-16 06:49:26 +00:00
2019-11-26 19:30:30 +00:00
## Custom templates
In addition to the standard `index.html` , `section.html` and `page.html` templates,
you may also create custom templates by creating an `.html` file in the `templates`
directory. These custom templates will not be used by default. Instead, a custom template will _only_ be used if you apply it by setting the `template` front-matter variable to the path for that template (or if you `include` it in another template that is applied). For example, if you created a custom template for your site's About page called `about.html` , you could apply it to your `about.md` page by including the following front matter in your `about.md` page:
2018-07-16 06:49:26 +00:00
```md
+++
title = "About Us"
template = "about.html"
+++
```
Custom templates are not required to live at the root of your `templates` directory.
For example, `product_pages/with_pictures.html` is a valid template.
2017-09-27 14:37:17 +00:00
## Built-in filters
2020-03-09 07:15:18 +00:00
Zola adds a few filters in addition to [those ](https://tera.netlify.com/docs/#filters ) already present
2019-11-26 19:30:30 +00:00
in Tera.
2017-09-27 14:37:17 +00:00
### markdown
2021-02-19 19:51:08 +00:00
Converts the given variable to HTML using Markdown. Please note that shortcodes evaluated by this filter cannot access the current rendering context. `config` will be available, but accessing `section` or `page` (among others) from a shortcode called within the `markdown` filter will prevent your site from building. See [this discussion ](https://github.com/getzola/zola/pull/1358 ).
2019-11-26 19:30:30 +00:00
By default, the filter will wrap all text in a paragraph. To disable this behaviour, you can
2018-01-26 15:22:37 +00:00
pass `true` to the inline argument:
```jinja2
{{ some_text | markdown(inline=true) }}
```
2020-04-12 15:25:58 +00:00
You do not need to use this filter with `page.content` or `section.content` , the content is already rendered.
2017-09-27 14:37:17 +00:00
### base64_encode
Encode the variable to base64.
### base64_decode
Decode the variable from base64.
## Built-in global functions
2018-11-07 18:45:03 +00:00
2020-03-11 06:59:54 +00:00
Zola adds a few global functions to [those in Tera ](https://tera.netlify.com/docs#built-in-functions )
2019-11-26 19:30:30 +00:00
to make it easier to develop complex sites.
2018-11-07 18:45:03 +00:00
2017-09-27 14:37:17 +00:00
### `get_page`
2019-11-26 19:30:30 +00:00
Takes a path to an `.md` file and returns the associated page.
2017-09-27 14:37:17 +00:00
```jinja2
{% set page = get_page(path="blog/page2.md") %}
```
### `get_section`
2019-11-26 19:30:30 +00:00
Takes a path to an `_index.md` file and returns the associated section.
2017-09-27 14:37:17 +00:00
```jinja2
2018-01-29 17:40:12 +00:00
{% set section = get_section(path="blog/_index.md") %}
2017-09-27 14:37:17 +00:00
```
2018-10-18 14:49:33 +00:00
If you only need the metadata of the section, you can pass `metadata_only=true` to the function:
```jinja2
{% set section = get_section(path="blog/_index.md", metadata_only=true) %}
```
2020-11-27 09:33:03 +00:00
### `get_url`
2017-09-27 14:37:17 +00:00
Gets the permalink for the given path.
2019-11-26 19:30:30 +00:00
If the path starts with `@/` , it will be treated as an internal
link like the ones used in Markdown, starting from the root `content` directory.
2017-09-27 14:37:17 +00:00
```jinja2
2019-05-27 12:35:14 +00:00
{% set url = get_url(path="@/blog/_index.md") %}
2017-09-27 14:37:17 +00:00
```
2020-09-04 20:53:31 +00:00
It accepts an optional parameter `lang` in order to compute a *language-aware URL* in multilingual websites. Assuming `config.base_url` is `"http://example.com"` , the following snippet will:
2020-04-12 17:23:17 +00:00
- return `"http://example.com/blog/"` if `config.default_language` is `"en"`
- return `"http://example.com/en/blog/"` if `config.default_language` is **not** `"en"` and `"en"` appears in `config.languages`
- fail otherwise, with the error message `"'en' is not an authorized language (check config.languages)."`
```jinja2
{% set url = get_url(path="@/blog/_index.md", lang="en") %}
```
2019-11-26 19:30:30 +00:00
This can also be used to get the permalinks for static assets, for example if
2017-09-27 14:37:17 +00:00
we want to link to the file that is located at `static/css/app.css` :
```jinja2
2018-05-17 16:32:46 +00:00
{{/* get_url(path="css/app.css") */}}
2017-09-27 14:37:17 +00:00
```
2018-10-18 14:49:33 +00:00
By default, assets will not have a trailing slash. You can force one by passing `trailing_slash=true` to the `get_url` function.
An example is:
2017-11-10 16:46:14 +00:00
```jinja2
2018-10-18 14:49:33 +00:00
{{/* get_url(path="css/app.css", trailing_slash=true) */}}
2017-11-10 16:46:14 +00:00
```
2020-05-23 09:46:50 +00:00
In the case of non-internal links, you can also add a cachebust of the format `?h=<sha256>` at the end of a URL
2017-09-27 14:37:17 +00:00
by passing `cachebust=true` to the `get_url` function.
2017-11-16 17:08:06 +00:00
2020-11-27 09:33:03 +00:00
### `get_file_hash`
2020-06-09 20:38:29 +00:00
2021-02-20 12:31:37 +00:00
Returns the hash digest of a static file. Supported hashing algorithms are
SHA-256, SHA-384 (default) and SHA-512. Requires `path` . The `sha_type`
parameter is optional and must be one of 256, 384 or 512.
2020-06-09 20:38:29 +00:00
```jinja2
{{/* get_file_hash(path="js/app.js", sha_type=256) */}}
```
2021-02-20 12:31:37 +00:00
The function can also output a base64-encoded hash value when its `base64`
parameter is set to `true` . This can be used to implement [subresource
integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity).
2020-06-09 20:38:29 +00:00
```jinja2
< script src = "{{/* get_url(path=" js / app . js " ) * / } } "
2021-02-20 12:31:37 +00:00
integrity="sha384-{{ get_file_hash(path="js/app.js", sha_type=384, base64=true) | safe }}">< / script >
2020-06-09 20:38:29 +00:00
```
2021-02-20 12:31:37 +00:00
Do note that subresource integrity is typically used when using external
scripts, which `get_file_hash` does not support.
2020-06-09 20:38:29 +00:00
2021-02-20 12:31:37 +00:00
Whenever hashing files, whether using `get_file_hash` or `get_url(...,
cachebust=true)`, the file is searched for in three places: `static/` ,
`content/` and the output path (so e.g. compiled SASS can be hashed, too.)
2020-06-09 20:38:29 +00:00
2019-05-30 18:06:24 +00:00
### `get_image_metadata`
2021-02-20 12:31:37 +00:00
2020-07-29 18:44:09 +00:00
Gets metadata for an image. This supports common formats like JPEG, PNG, as well as SVG.
2020-06-18 09:36:11 +00:00
Currently, the only supported keys are `width` and `height` .
2019-05-30 18:06:24 +00:00
```jinja2
{% set meta = get_image_metadata(path="...") %}
Our image is {{ meta.width }}x{{ meta.height }}
```
2018-01-16 12:57:31 +00:00
### `get_taxonomy_url`
2018-07-31 14:35:16 +00:00
Gets the permalink for the taxonomy item found.
2017-11-16 17:08:06 +00:00
```jinja2
2020-08-18 11:06:49 +00:00
{% set url = get_taxonomy_url(kind="categories", name=page.taxonomies.category, lang=page.lang) %}
2017-11-16 17:08:06 +00:00
```
2019-11-26 19:30:30 +00:00
`name` will almost always come from a variable but in case you want to do it manually,
the value should be the same as the one in the front matter, not the slugified version.
2018-01-16 12:57:31 +00:00
2020-08-18 11:06:49 +00:00
`lang` (optional) default to `config.default_language` in config.toml
2018-07-31 14:35:16 +00:00
### `get_taxonomy`
Gets the whole taxonomy of a specific kind.
```jinja2
2019-03-25 22:15:51 +00:00
{% set categories = get_taxonomy(kind="categories") %}
2018-07-31 14:35:16 +00:00
```
2020-06-18 20:50:25 +00:00
The type of the output is:
```ts
kind: TaxonomyConfig;
items: Array< TaxonomyTerm > ;
```
See the [Taxonomies documentation ](@/documentation/templates/taxonomies.md ) for a full documentation of those types.
2018-10-18 15:32:30 +00:00
### `load_data`
2020-11-21 10:44:42 +00:00
Loads data from a file or URL. Supported file types include *toml* , *json* , *csv* and *bibtex* .
2019-03-16 09:01:11 +00:00
Any other file type will be loaded as plain text.
2018-10-18 15:32:30 +00:00
2019-03-16 09:01:11 +00:00
The `path` argument specifies the path to the data file relative to your base directory, where your `config.toml` is.
2019-11-26 19:30:30 +00:00
As a security precaution, if this file is outside the main site directory, your site will fail to build.
2018-10-18 15:32:30 +00:00
```jinja2
2019-03-16 09:01:11 +00:00
{% set data = load_data(path="content/blog/story/data.toml") %}
2018-10-18 15:32:30 +00:00
```
2021-02-02 19:19:44 +00:00
The optional `required` boolean argument can be set to false so that missing data (HTTP error or local file not found) does not produce an error, but returns a null value instead. However, permission issues with a local file and invalid data that could not be parsed to the requested data format will still produce an error even with `required=false` .
The snippet below outputs the HTML from a Wikipedia page, or "No data found" if the page was not reachable, or did not return a successful HTTP code:
```jinja2
{% set data = load_data(path="https://en.wikipedia.org/wiki/Commune_of_Paris", required=false) %}
{% if data %}{{ data | safe }}{% else %}No data found{% endif %}
```
2018-10-29 19:13:09 +00:00
The optional `format` argument allows you to specify and override which data type is contained
2020-11-21 10:44:42 +00:00
within the file specified in the `path` argument. Valid entries are `toml` , `json` , `csv` , `bibtex`
2019-11-26 19:30:30 +00:00
or `plain` . If the `format` argument isn't specified, then the path extension is used.
2018-10-18 15:32:30 +00:00
2021-02-02 19:19:44 +00:00
2018-10-18 15:32:30 +00:00
```jinja2
2019-03-16 09:01:11 +00:00
{% set data = load_data(path="content/blog/story/data.txt", format="json") %}
2018-10-18 15:32:30 +00:00
```
2019-03-16 09:01:11 +00:00
Use the `plain` format for when your file has a toml/json/csv extension but you want to load it as plain text.
2019-11-26 19:30:30 +00:00
For *toml* and *json* , the data is loaded into a structure matching the original data file;
however, for *csv* there is no native notion of such a structure. Instead, the data is separated
2018-10-18 21:09:32 +00:00
into a data structure containing *headers* and *records* . See the example below to see
2018-10-18 15:32:30 +00:00
how this works.
In the template:
```jinja2
2019-03-16 09:01:11 +00:00
{% set data = load_data(path="content/blog/story/data.csv") %}
2018-10-18 15:32:30 +00:00
```
2019-03-16 09:01:11 +00:00
In the *content/blog/story/data.csv* file:
2018-10-29 19:13:09 +00:00
```csv
2018-10-18 15:32:30 +00:00
Number, Title
1,Gutenberg
2,Printing
```
The equivalent json value of the parsed data would be stored in the `data` variable in the
template:
```json
{
"headers": ["Number", "Title"],
"records": [
2018-10-18 21:09:32 +00:00
["1", "Gutenberg"],
2018-10-18 15:32:30 +00:00
["2", "Printing"]
],
}
2018-10-29 19:13:09 +00:00
```
2020-11-21 10:44:42 +00:00
The `bibtex` format loads data into a structure matching the format used by the
[nom-bibtex crate ](https://crates.io/crates/nom-bibtex ). The following is an example of data
in bibtex format:
```
@preamble {"A bibtex preamble" # " this is."}
@Comment {
Here is a comment.
}
Another comment!
@string (name = "Vincent Prouillet")
@string (github = "https://github.com/getzola/zola")
@misc {my_citation_key,
author= name,
title = "Zola",
note = "github: " # github
} }
```
The following is the json-equivalent format of the produced bibtex data structure:
```json
{
"preambles": ["A bibtex preamble this is."],
"comments": ["Here is a comment.", "Another comment!"],
"variables": {
"name": "Vincent Prouillet",
"github": "https://github.com/getzola/zola"
},
"bibliographies": [
{
"entry_type": "misc",
"citation_key": "my_citation_key",
"tags": {
"author": "Vincent Prouillet",
"title": "Zola",
"note": "github: https://github.com/getzola/zola"
}
}
]
}
```
Finally, the bibtex data can be accessed from the template as follows:
```jinja2
{% set tags = data.bibliographies[0].tags %}
This was generated using {{ tags.title }}, authored by {{ tags.author }}.
```
2018-10-29 19:13:09 +00:00
#### Remote content
2019-11-26 19:30:30 +00:00
Instead of using a file, you can load data from a remote URL. This can be done by specifying a `url` parameter
to `load_data` rather than `path` .
2018-10-29 19:13:09 +00:00
```jinja2
{% set response = load_data(url="https://api.github.com/repos/getzola/zola") %}
{{ response }}
```
2019-11-26 19:30:30 +00:00
By default, the response body will be returned with no parsing. This can be changed by using the `format` argument
as below.
2018-10-29 19:13:09 +00:00
```jinja2
{% set response = load_data(url="https://api.github.com/repos/getzola/zola", format="json") %}
{{ response }}
```
2021-04-21 19:29:47 +00:00
When no other parameters are specified the URL will always be retrieved using a HTTP GET request.
Using the parameter `method` , since version 0.14.0, you can also choose to retrieve the URL using a POST request.
When using `method="POST"` you can also use the parameters `body` and `contenttype` .
The parameter body is the actual contents sent in the POST request.
The parameter contenttype should be the mimetype of the body.
This example will make a POST request to the kroki service to generate a SVG.
```jinja2
{% set postdata = load_data(url="https://kroki.io/blockdiag/svg", format="plain", method="POST" ,content_type="text/plain", body="blockdiag {
'Doing POST' -> 'using load_data'
'using load_data' -> 'can generate' -> 'block diagrams';
'using load_data' -> is -> 'very easy!';
'Doing POST' [color = 'greenyellow'];
'block diagrams' [color = 'pink'];
'very easy!' [color = 'orange'];
}")%}
{{postdata|safe}}
```
2019-11-26 19:30:30 +00:00
#### Data caching
2018-10-29 19:13:09 +00:00
2019-11-26 19:30:30 +00:00
Data file loading and remote requests are cached in memory during the build, so multiple requests aren't made
to the same endpoint.
URLs are cached based on the URL, and data files are cached based on the file modified time.
The format is also taken into account when caching, so a request will be sent twice if it's loaded with two
different formats.
2018-10-18 15:32:30 +00:00
2018-01-16 12:57:31 +00:00
### `trans`
2019-02-27 13:54:09 +00:00
Gets the translation of the given `key` , for the `default_language` or the `lang` uage given
2018-01-16 12:57:31 +00:00
```jinja2
2018-05-17 16:32:46 +00:00
{{/* trans(key="title") */}}
{{/* trans(key="title", lang="fr") */}}
2018-01-16 12:57:31 +00:00
```
2018-04-08 20:12:39 +00:00
### `resize_image`
Resizes an image file.
2020-09-04 20:53:31 +00:00
Please refer to [_Content / Image Processing_ ](@/documentation/content/image-processing/index.md ) for complete documentation.