2017-09-12 07:13:26 +00:00
|
|
|
+++
|
|
|
|
title = "Configuration"
|
2020-01-20 03:02:05 +00:00
|
|
|
weight = 40
|
2017-09-12 07:13:26 +00:00
|
|
|
+++
|
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
The default configuration is sufficient to get Zola running locally but not more than that.
|
2020-08-16 16:25:52 +00:00
|
|
|
It follows the philosophy of paying for only what you need, almost everything is turned off by default.
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
To change the configuration, edit the `config.toml` file.
|
|
|
|
If you are not familiar with TOML, have a look at [the TOML spec](https://github.com/toml-lang/toml).
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2020-09-04 20:53:31 +00:00
|
|
|
⚠️ If you add keys to your `config.toml`, you must pay attention to which TOML section it belongs to.
|
2020-08-16 16:25:52 +00:00
|
|
|
|
|
|
|
Here are the current `config.toml` sections:
|
|
|
|
1. main (unnamed)
|
2021-01-07 09:49:17 +00:00
|
|
|
2. markdown
|
|
|
|
3. link_checker
|
|
|
|
4. slugify
|
|
|
|
5. search
|
|
|
|
6. translations
|
|
|
|
7. extra
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2020-08-16 16:25:52 +00:00
|
|
|
**Only the `base_url` variable is mandatory**. Everything else is optional. All configuration variables
|
|
|
|
used by Zola as well as their default values are listed below:
|
2017-09-27 14:37:17 +00:00
|
|
|
|
|
|
|
```toml
|
2019-11-26 19:30:30 +00:00
|
|
|
# The base URL of the site; the only required configuration variable.
|
2017-09-27 14:37:17 +00:00
|
|
|
base_url = "mywebsite.com"
|
|
|
|
|
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 site title and description; used in feeds by default.
|
2017-09-27 14:37:17 +00:00
|
|
|
title = ""
|
|
|
|
description = ""
|
2019-11-26 19:30:30 +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
|
|
|
# The default language; used in feeds.
|
2018-01-16 12:57:31 +00:00
|
|
|
default_language = "en"
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# The site theme to use.
|
2017-09-27 14:37:17 +00:00
|
|
|
theme = ""
|
|
|
|
|
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
|
|
|
# When set to "true", a feed is automatically generated.
|
|
|
|
generate_feed = false
|
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
|
|
|
# The filename to use for the feed. Used as the template filename, too.
|
2020-09-04 20:53:31 +00:00
|
|
|
# Defaults to "atom.xml", which has a built-in template that renders an Atom 1.0 feed.
|
|
|
|
# There is also a built-in template "rss.xml" that renders an RSS 2.0 feed.
|
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
|
|
|
# feed_filename = "atom.xml"
|
|
|
|
|
|
|
|
# The number of articles to include in the feed. All items are included if
|
2019-11-26 19:30:30 +00:00
|
|
|
# this limit is not set (the default).
|
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
|
|
|
# feed_limit = 20
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# When set to "true", files in the `static` directory are hard-linked. Useful for large
|
|
|
|
# static files. Note that for this to work, both `static` and the
|
|
|
|
# output directory need to be on the same filesystem. Note that the theme's `static`
|
2020-09-04 20:53:31 +00:00
|
|
|
# files are always copied, regardless of this setting.
|
2019-07-10 21:37:19 +00:00
|
|
|
# hard_link_static = false
|
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# The taxonomies to be rendered for the site and their configuration.
|
2018-07-16 08:54:05 +00:00
|
|
|
# Example:
|
|
|
|
# taxonomies = [
|
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
|
|
|
# {name = "tags", feed = true}, # each tag will have its own feed
|
2019-08-10 16:53:16 +00:00
|
|
|
# {name = "tags", lang = "fr"}, # you can have taxonomies with the same name in multiple languages
|
2018-08-29 22:55:49 +00:00
|
|
|
# {name = "categories", paginate_by = 5}, # 5 items per page for a term
|
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
|
|
|
# {name = "authors"}, # Basic definition: no feed or pagination
|
2018-07-16 08:54:05 +00:00
|
|
|
# ]
|
|
|
|
#
|
|
|
|
taxonomies = []
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# The additional languages for the site.
|
2018-12-28 12:24:49 +00:00
|
|
|
# Example:
|
|
|
|
# languages = [
|
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
|
|
|
# {code = "fr", feed = true}, # there will be a feed for French content
|
2019-09-03 14:50:23 +00:00
|
|
|
# {code = "fr", search = true}, # there will be a Search Index for French content
|
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
|
|
|
# {code = "it"}, # there won't be a feed for Italian content
|
2018-12-28 12:24:49 +00:00
|
|
|
# ]
|
|
|
|
#
|
|
|
|
languages = []
|
|
|
|
|
2020-09-16 10:55:41 +00:00
|
|
|
# When set to "true", the Sass files in the `sass` directory in the site root are compiled.
|
|
|
|
# Sass files in theme directories are always compiled.
|
2017-09-27 14:37:17 +00:00
|
|
|
compile_sass = false
|
|
|
|
|
2020-10-15 18:11:55 +00:00
|
|
|
# When set to "true", the generated HTML files are minified.
|
|
|
|
minify_html = false
|
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# A list of glob patterns specifying asset files to ignore when the content
|
|
|
|
# directory is processed. Defaults to none, which means that all asset files are
|
|
|
|
# copied over to the `public` directory.
|
2018-03-01 09:31:51 +00:00
|
|
|
# Example:
|
Filter ignored content in page.rs.
* Add ignored_content to the Config structure.
* Use the GlobSet crate to parse the glob patterns into a matcher, which
is created once at program initialization. If there are no patterns in
ignored_content, an empty globber is created, which excludes no files.
This is consistent with the existing behaviour of Gutenberg, before
this feature was added.
* Bail if there are any errors in the glob patterns.
* Add a call to the globber in page.rs to actually do the filtering.
* Update documentation.
A note on the Config structure
------------------------------
* I had to remove the PartialEq derive from the Config structure as it
does not work for the GlobSet type. No harm is done, Config does not
need to be PartialEq anyway, since there is no need to sort Configs.
* The implementation follows the pattern of the existing config settings
in that it uses an Option<...>. This would appear unnecessary, in that
an empty vec could be used as the default, but it appears to be needed
by the TOML parsing. A better approach would be to use a separate
SerializableConfig and map to/from a Config struct. This would also
allow the elimination of most, if not all, of the other Options in
the Config structure, but that ought to be another PR.
2018-02-25 11:42:31 +00:00
|
|
|
# ignored_content = ["*.{graphml,xlsx}", "temp.*"]
|
|
|
|
ignored_content = []
|
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# A list of directories used to search for additional `.sublime-syntax` files.
|
2018-08-14 14:54:24 +00:00
|
|
|
extra_syntaxes = []
|
|
|
|
|
2020-10-03 14:43:02 +00:00
|
|
|
# You can override the default output directory `public` by setting an another value.
|
|
|
|
# output_dir = "docs"
|
|
|
|
|
2020-11-21 21:20:54 +00:00
|
|
|
# Configuration of the Markdown rendering
|
2020-11-21 11:30:55 +00:00
|
|
|
[markdown]
|
|
|
|
# When set to "true", all code blocks are highlighted.
|
|
|
|
highlight_code = false
|
|
|
|
|
|
|
|
# The theme to use for code highlighting.
|
|
|
|
# See below for list of allowed values.
|
|
|
|
highlight_theme = "base16-ocean-dark"
|
|
|
|
|
|
|
|
# When set to "true", emoji aliases translated to their corresponding
|
|
|
|
# Unicode emoji equivalent in the rendered Markdown files. (e.g.: :smile: => 😄)
|
|
|
|
render_emoji = false
|
|
|
|
|
2020-11-21 21:20:54 +00:00
|
|
|
# Whether external links are to be opened in a new tab
|
|
|
|
# If this is true, a `rel="noopener"` will always automatically be added for security reasons
|
|
|
|
external_links_target_blank = false
|
|
|
|
|
|
|
|
# Whether to set rel="nofollow" for all external links
|
|
|
|
external_links_no_follow = false
|
|
|
|
|
|
|
|
# Whether to set rel="noreferrer" for all external links
|
|
|
|
external_links_no_referrer = false
|
|
|
|
|
2020-11-27 10:11:19 +00:00
|
|
|
# Whether smart punctuation is enabled (changing quotes, dashes, dots in their typographic form)
|
|
|
|
# For example, `...` into `…`, `"quote"` into `“curly”` etc
|
|
|
|
smart_punctuation = false
|
|
|
|
|
2019-11-26 19:30:30 +00:00
|
|
|
# Configuration of the link checker.
|
2019-10-14 16:31:03 +00:00
|
|
|
[link_checker]
|
2019-11-25 11:13:02 +00:00
|
|
|
# Skip link checking for external URLs that start with these prefixes
|
|
|
|
skip_prefixes = [
|
|
|
|
"http://[2001:db8::]/",
|
|
|
|
]
|
|
|
|
|
2019-10-14 16:31:03 +00:00
|
|
|
# Skip anchor checking for external URLs that start with these prefixes
|
|
|
|
skip_anchor_prefixes = [
|
|
|
|
"https://caniuse.com/",
|
|
|
|
]
|
2018-01-16 12:57:31 +00:00
|
|
|
|
2020-02-05 08:13:14 +00:00
|
|
|
# Various slugification strategies, see below for details
|
2020-09-04 20:53:31 +00:00
|
|
|
# Defaults to everything being a slug
|
2020-02-05 08:13:14 +00:00
|
|
|
[slugify]
|
|
|
|
paths = "on"
|
|
|
|
taxonomies = "on"
|
|
|
|
anchors = "on"
|
|
|
|
|
2020-06-29 18:02:05 +00:00
|
|
|
# When set to "true", a search index is built from the pages and section
|
|
|
|
# content for `default_language`.
|
|
|
|
build_search_index = false
|
|
|
|
|
|
|
|
[search]
|
|
|
|
# Whether to include the title of the page/section in the index
|
|
|
|
include_title = true
|
|
|
|
# Whether to include the description of the page/section in the index
|
|
|
|
include_description = false
|
2021-06-02 07:18:39 +00:00
|
|
|
# Whether to include the path of the page/section in the index
|
|
|
|
include_path = false
|
2020-06-29 18:02:05 +00:00
|
|
|
# Whether to include the rendered content of the page/section in the index
|
|
|
|
include_content = true
|
|
|
|
# At which character to truncate the content to. Useful if you have a lot of pages and the index would
|
|
|
|
# become too big to load on the site. Defaults to not being set.
|
|
|
|
# truncate_content_length = 100
|
|
|
|
|
2020-02-05 08:13:14 +00:00
|
|
|
# Optional translation object. Keys should be language codes.
|
2020-08-16 16:25:52 +00:00
|
|
|
# Optional translation object. The key if present should be a language code.
|
|
|
|
# Example:
|
|
|
|
# default_language = "fr"
|
|
|
|
#
|
|
|
|
# [translations]
|
|
|
|
# [translations.fr]
|
|
|
|
# title = "Un titre"
|
|
|
|
#
|
|
|
|
# [translations.en]
|
|
|
|
# title = "A title"
|
|
|
|
#
|
2020-02-05 08:13:14 +00:00
|
|
|
[translations]
|
|
|
|
|
|
|
|
# You can put any kind of data here. The data
|
2020-08-16 16:25:52 +00:00
|
|
|
# will be accessible in all templates
|
|
|
|
# Example:
|
|
|
|
# [extra]
|
|
|
|
# author = "Famous author"
|
|
|
|
#
|
|
|
|
# author value will be available using {{ config.extra.author }} in templates
|
|
|
|
#
|
2017-09-27 14:37:17 +00:00
|
|
|
[extra]
|
|
|
|
```
|
|
|
|
|
|
|
|
## Syntax highlighting
|
|
|
|
|
2018-10-18 21:09:32 +00:00
|
|
|
Zola currently has the following highlight themes available:
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2018-04-02 00:33:59 +00:00
|
|
|
- [1337](https://tmtheme-editor.herokuapp.com/#!/editor/theme/1337)
|
|
|
|
- [agola-dark](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Agola%20Dark)
|
|
|
|
- [ascetic-white](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Ascetic%20White)
|
|
|
|
- [axar](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Axar)
|
2020-02-21 13:14:25 +00:00
|
|
|
- [ayu-dark](https://github.com/dempfi/ayu)
|
|
|
|
- [ayu-light](https://github.com/dempfi/ayu)
|
|
|
|
- [ayu-mirage](https://github.com/dempfi/ayu)
|
2021-03-14 08:49:29 +00:00
|
|
|
- [base16-aterlierdune-light](https://atelierbram.github.io/syntax-highlighting/atelier-schemes/dune/)
|
2019-06-17 08:08:05 +00:00
|
|
|
- [base16-ocean-dark](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Base16%20Ocean%20Dark)
|
|
|
|
- [base16-ocean-light](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Base16%20Ocean%20Light)
|
2018-04-02 00:33:59 +00:00
|
|
|
- [bbedit](https://tmtheme-editor.herokuapp.com/#!/editor/theme/BBEdit)
|
|
|
|
- [boron](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Boron)
|
|
|
|
- [charcoal](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Charcoal)
|
|
|
|
- [cheerfully-light](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Cheerfully%20Light)
|
|
|
|
- [classic-modified](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Classic%20Modified)
|
|
|
|
- [demain](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Demain)
|
|
|
|
- [dimmed-fluid](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Dimmed%20Fluid)
|
2019-01-15 22:20:47 +00:00
|
|
|
- [dracula](https://draculatheme.com/)
|
2018-04-02 00:33:59 +00:00
|
|
|
- [gray-matter-dark](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Gray%20Matter%20Dark)
|
|
|
|
- [gruvbox-dark](https://github.com/morhetz/gruvbox)
|
|
|
|
- [gruvbox-light](https://github.com/morhetz/gruvbox)
|
|
|
|
- [idle](https://tmtheme-editor.herokuapp.com/#!/editor/theme/IDLE)
|
|
|
|
- [inspired-github](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Inspiredgithub)
|
|
|
|
- [ir-white](https://tmtheme-editor.herokuapp.com/#!/editor/theme/IR_White)
|
|
|
|
- [kronuz](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Kronuz)
|
|
|
|
- [material-dark](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Material%20Dark)
|
2020-06-17 09:03:06 +00:00
|
|
|
- [material-light](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Material%20Light)
|
2018-04-02 00:33:59 +00:00
|
|
|
- [monokai](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Monokai)
|
2020-04-29 20:35:28 +00:00
|
|
|
- [nord](https://github.com/crabique/Nord-plist/tree/0d655b23d6b300e691676d9b90a68d92b267f7ec)
|
2020-02-21 13:14:25 +00:00
|
|
|
- [nyx-bold](https://github.com/GalAster/vscode-theme-nyx)
|
|
|
|
- [one-dark](https://github.com/andresmichel/one-dark-theme)
|
2020-08-03 18:08:17 +00:00
|
|
|
- [OneHalf](https://github.com/sonph/onehalf)
|
2018-04-02 00:33:59 +00:00
|
|
|
- [solarized-dark](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Solarized%20(dark))
|
|
|
|
- [solarized-light](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Solarized%20(light))
|
|
|
|
- [subway-madrid](https://github.com/idleberg/Subway.tmTheme)
|
|
|
|
- [subway-moscow](https://github.com/idleberg/Subway.tmTheme)
|
2019-07-16 15:22:02 +00:00
|
|
|
- [Tomorrow](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Tomorrow)
|
2020-04-29 20:35:28 +00:00
|
|
|
- [TwoDark](https://github.com/erremauro/TwoDark)
|
2020-02-21 13:14:25 +00:00
|
|
|
- [visual-studio-dark](https://tmtheme-editor.herokuapp.com/#!/editor/theme/Visual%20Studio%20Dark)
|
2019-10-08 19:31:23 +00:00
|
|
|
- [zenburn](https://github.com/colinta/zenburn)
|
2017-09-27 14:37:17 +00:00
|
|
|
|
2018-10-18 21:09:32 +00:00
|
|
|
Zola uses the Sublime Text themes, making it very easy to add more.
|
2019-11-26 19:30:30 +00:00
|
|
|
If you want a theme not listed above, please open an issue or a pull request on the [Zola repo](https://github.com/getzola/zola).
|
2020-02-05 08:13:14 +00:00
|
|
|
|
|
|
|
## Slugification strategies
|
|
|
|
|
|
|
|
By default, Zola will turn every path, taxonomies and anchors to a slug, an ASCII representation with no special characters.
|
|
|
|
You can however change that strategy for each kind of item, if you want UTF-8 characters in your URLs for example. There are 3 strategies:
|
|
|
|
|
|
|
|
- `on`: the default one, everything is turned into a slug
|
|
|
|
- `safe`: characters that cannot exist in files on Windows (`<>:"/\|?*`) or Unix (`/`) are removed, everything else stays
|
|
|
|
- `off`: nothing is changed, your site might not build on some OS and/or break various URL parsers
|
|
|
|
|
|
|
|
Since there are no filename issues with anchors, the `safe` and `off` strategies are identical in their case: the only change
|
|
|
|
is space being replaced by `_` since a space is not valid in an anchor.
|
|
|
|
|
|
|
|
Note that if you are using a strategy other than the default, you will have to manually escape whitespace and Markdown
|
|
|
|
tokens to be able to link to your pages. For example an internal link to a file named `some space.md` will need to be
|
2020-02-21 13:14:25 +00:00
|
|
|
written like `some%20space.md` in your Markdown files.
|