* Replace hack for newline support in shortcodes with new hack
* Be a bit more space efficient/accurate with naming
* Boil newline/whitespace shortcode test down to the essentials
* Make sure the new \n and \s chars in old tests are properly represented
* Support markdown templates and shortcodes
* Refactoring .md/.html shortcode behaviour
* Add test for markdown shortcodes
* Add an html output test for markdown based shortcodes
* Add documentation for Markdown based shortcodes
* Tables in config.extra can be merged with those in theme.extra
* Don't panic with invalid config type, but propagate an error
* Recursively merge config/theme extra sections
Co-authored-by: southerntofu <southerntofu@thunix.net>
* Update sitemap.rs
When paginate_by is zero, set number_pagers to 1 so at least 1 sitemap section is pushed
* paginate_by updates
Introduce section.paginate_by, use value if it exists, removes now
unnecessary filter
Co-authored-by: Justin Turpin <justinturpin@pop-os.localdomain>
Prior to this change, only sass files starting with _ were ignored by
Zola's sass compiler. This made using sass frameworks incredibly
inconvenient, as Zola attempted to compile every single sass file in the
framework, and inevitably errored due to them not being standalone. For
example, to use the Bulma framework, you had to manually add an
underscore to the beginning of *every* sass file in it so Zola would
stop trying to compile them as standalone css files. Now you can change
the directory name to _bulma and have the same result.
* Site templates can replace theme templates
* Integrate test case within test_site/
* Full backwards-compatibility with testcase in test_site
* Refine test case
* Call parent's block in child template for test case
* Check both templates are applied
* Follow testing advice
* Test for 'include' in themes and shortcodes
* Documentation for themes and how to extend them
Co-authored-by: Vincent Prouillet <balthek@gmail.com>
* Add support for SVG files to `get_image_metadata`
* Add support for SVG files to `get_image_metadata`
* Update documentation after adding SVG support
* Don't panic on bad date strings
Instead, show a helpful error message explaining only RFC3339 is
supported.
Fixes#993.
* Try to parse the full range of TOML date formats
* Fix get_url(cachebust=true)
The previous implementation looked for static files in the wrong place.
Look in static_path, output_path and content_path. If file can't be
found in any of them, print a warning to stderr and fall back to using
a timestamp.
Add a test to ensure it also works in practice, not just in theory.
* Implement get_file_hash
If there is no response from the server, `load_data` would panic
with: `response status`.
This patch removes the `expect` in favor of an error message that we
couldn't get a response from the server for a given url.
Cache-busting was previously done with a compile-time timestamp. Change
to the SHA-256 hash of the file to avoid refreshing unchanged files.
The implementation could be used to add a new global fn (say,
get_file_hash) for subresource integrity use, but that's for another
commit.
Fixes#519.
Co-authored-by: Vincent Prouillet <balthek@gmail.com>
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.
Two main purposes of changes here:
- To make the formatting and indentation of the raw output prettier;
- To simplify the HTML yielded by dropping unnecessary bits.
The 404 changes are a tad more extensive, altering the actual wording to
match conventional stub 404 pages a little more.
The HTML spec doesn’t require it, and I prefer to omit it. This has been
bothering me for ages, but I hadn’t gotten round to fixing it yet.
This can cause nominally invalid HTML to be emitted, if `</body>` was
omitted but `</html>` was present, but that’s unlikely to happen, and
this is for development purposes only, and the right thing will happen
anyway in all environments (per browser behaviour and spec).
I don’t think this warrants a changelog entry.
* get_url takes an optionnal parameter
* Documentation about the 'lang' parameter of 'get_url'
Co-authored-by: Gaëtan Caillaut <gaetan.caillaut@live.com>
