mirror of
https://github.com/getzola/zola
synced 2024-12-13 13:52:28 +00:00
No description
e25915b231
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. |
||
|---|---|---|
| .github | ||
| completions | ||
| components | ||
| docs | ||
| src | ||
| sublime_syntaxes | ||
| sublime_themes | ||
| test_site | ||
| test_site_i18n | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| azure-pipelines.yml | ||
| build.rs | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| EXAMPLES.md | ||
| is-ehh.svg | ||
| is-no.svg | ||
| is-yes.svg | ||
| LICENSE | ||
| netlify.toml | ||
| README.md | ||
| rustfmt.toml | ||
| snapcraft.yaml | ||
zola (né Gutenberg)
A fast static site generator in a single binary with everything built-in.
Documentation is available on its site or
in the docs/content folder of the repository and the community can use its forum.
Comparisons with other static site generators
| Zola | Cobalt | Hugo | Pelican | |
|---|---|---|---|---|
| Single binary |  |
|
|
 |
| Language | Rust | Rust | Go | Python |
| Syntax highlighting | |
|
|
|
| Sass compilation | |
|
|
|
| Assets co-location | |
|
|
|
| Multilingual site |  |
|
|
|
| Image processing | |
|
|
|
| Sane & powerful template engine | |
|
|
|
| Themes | |
|
|
|
| Shortcodes | |
|
|
|
| Internal links | |
|
|
|
| Link checker | |
|
|
|
| Table of contents | |
|
|
|
| Automatic header anchors | |
|
|
|
| Aliases | |
|
|
|
| Pagination | |
|
|
|
| Custom taxonomies | |
|
|
|
| Search | |
|
|
|
| Data files | |
|
|
|
| LiveReload | |
|
|
|
| Netlify support | |
|
|
|
| ZEIT Now support | |
|
|
|
| Breadcrumbs | |
|
|
|
| Custom output formats | |
|
|
|
Supported content formats
- Zola: markdown
- Cobalt: markdown
- Hugo: markdown, asciidoc, org-mode
- Pelican: reStructuredText, markdown, asciidoc, org-mode, whatever-you-want
explanations
Hugo gets for the template engine because while it is probably the most powerful template engine in the list (after Jinja2) it personally drives me insane, to the point of writing my own template engine and static site generator. Yes, this is a bit biased.
Zola gets for multi-language support as it only has a basic support and does not (yet) offer things like i18n in templates.
Pelican notes
Many features of Pelican come from plugins, which might be tricky to use because of a version mismatch or inadequate documentation. Netlify supports Python and Pipenv but you still need to install your dependencies manually.