* Add YAML to formats supported by load_data()
A fairly trivial addition; JSON and YAML are handled so similarly
that this was a matter of copying the JSON-relevant handlers and
editing the copies to handle YAML as well. The test file was
literally generated with 'json2yaml'.
The documentation has been updated to indicate that load_data() now
handles YAML code.
The CHANGELOG has been updated as well.
* After checking, I found that it's generally agreed the mime type is still application/x-yaml.
* Update comment, unify library importing.
I noticed one more place where the list of formats was supported,
and added YAML to that list.
I noticed that there's a singular place to load the `libs::` crate,
and unified by importing of serde_yaml in that place.
* Next version
* Added ask prompt for output-dir flag
Added `ask_bool` prompt for `--output-dir` for when the output directory
targeted already exists in the file system.
[Issue: #1378]
* Updated the documentation for #1378
* Added missing "sure" in prompt text
* Added timeout to prompt + dirname
* Fixed complication errors
Co-authored-by: Vincent Prouillet <balthek@gmail.com>
* Internal links are resolved in tera markdown filter (close#1296#1316)
* Add a test for internal links in markdown filter
Co-authored-by: southerntofu <southerntofu@thunix.net>
* Next version
* Remove lines forcing minify_html to false
* Update documentation about minify_html
* Update changelog
Co-authored-by: Vincent Prouillet <balthek@gmail.com>
* Change zola serve to load HTML from memory instead of disk
* Be smart about assets copying
* Be a tiny bit smarter on template changes
* Add zola serve --fast
* Add support for SVG files to `get_image_metadata`
* Add support for SVG files to `get_image_metadata`
* Update documentation after adding SVG support
Also change a few other things to use it, as noted in CHANGELOG.md.
TODO:
- Write a couple of tests: updated field, last_updated template variable
One slight open questions: should `updated` default to the value of
`date` rather than to None? Then pages with `date` could safely assume
`updated`.
The variable name matched the RSS tag it ended up in, but was misleading
about what it actually was—because if you actually want “last build
date”, you should use `now()`. (Due to the potential for edits, I think
that either there should be an official `updated` field on pages, or
that these templates should use `now()`.)
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.
