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.
* maybe_slugify() only does simple sanitation if config.slugify is false
* slugify is disabled by default, turn on for backwards-compatibility
* First docs changes for optional slugification
* Remove # from slugs but not &
* Add/fix tests for utf8 slugs
* Fix test sites for i18n slugs
* fix templates tests for i18n slugs
* Rename slugify setting to slugify_paths
* Default slugify_paths
* Update documentation for slugify_paths
* quasi_slugify removes ?, /, # and newlines
* Remove forbidden NTFS chars in quasi_slugify()
* Slugification forbidden chars can be configured
* Remove trailing dot/space in quasi_slugify
* Fix NTFS path sanitation
* Revert configurable slugification charset
* Remove \r for windows newlines and \t tabulations in quasi_slugify()
* Update docs for output paths
* Replace slugify with slugify_paths
* Fix test
* Default to not slugifying
* Move slugs utils to utils crate
* Use slugify_paths for anchors as well
* fix the issue of generating the search index for multiple language
* updat docs for generating the search index for multiple language
* fix failed tests
* add tests for the search index of multiple language
* Add hard_link_static config option.
* Copy or hardlink file depending on an argument.
Modify the call sites for `copy_file` to account for the extra argument.
* Plug the config setting through to copy_file.
Don't apply the config option to theme's static directory.
* Update documentation.
* Backticks make no sense in this comment.
* Addressing PR comments.
* Be consistent with argument naming.
Switch to an `Option<usize>` for the serialized value of `rss_items`.
This lets us just set a blank value in the configuration and thereby
include *all* items.
This is a backwards-compatible change; it does not affect the behavior
of existing configurations.
Fixes#468. Closes#471.
* 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.
