* mention code block output change
* Update snap
* Update themes gallery (#1082)
Co-authored-by: GitHub Action <action@github.com>
* Deployment guide for Vercel
* Change wording a bit
* Update themes gallery (#1122)
Co-authored-by: GitHub Action <action@github.com>
* Add feed autodiscovery documentation (#1123)
* Add feed autodiscovery documentation
* Fix link in template
* Docs/configuration update (#1126)
* Update configuration documentation
- Attempt to split the configuration file into sections to make it more readable and
avoid configuration mistakes (#1056).
- Move translation instructions to the right part.
- Add a bit more explanations to the extra section.
* Take into account @Keats feedbacks
* Remove short notice about translation usage
- A i18n page should be created to better explain it.
* add fix for (#1135) Taxonomies with identical slugs now get merged (#1136)
* add test and implementation for reverse pagination
* incorporate review changes
Co-authored-by: Michael Plotke <bdjnks@gmail.com>
Co-authored-by: Vincent Prouillet <balthek@gmail.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: Samyak Bakliwal <w3bcode@gmail.com>
Co-authored-by: René Ribaud <uggla@free.fr>
* Per section/subsection feeds
* Added `generate_feed` variable to section front matter.
* Generate atom/rss feeds for sections/subsections that have the
`generate_feed` variable set to true (false by default); this works
independent of the `generate_feed` variable in the root `config.toml`
file, however, the name (and template) of the feed file for each section
is the same as `feed_filename` in `config.toml`, just located in the
root of each section.
* Slightly edited `atom.xml` and `rss.xml` so that they include the
section title (if any), and the url of a section, if it's a section
feed.
* Section feeds: tests
* Changed a couple of sections' front matter in order to generate feeds
for them for the test.
* Changed the can_build_feed test in site package to can_build_feeds and
included some assertions to make sure that section feeds are generated
when requested.
* Section feeds: documentation
* Added information about the section front matter variable
`generate_feed` in the section content page.
* Added information about section feeds in the feeds template page.
* Section feeds fix: use section.path for feed path
* Make {section, page}.path always start with a slash
Change tests accordingly
* Fix missing leading/trailing slash in current_path of Taxonomy ("tags") and TaxonomyItem ("some-tag")
* Make {Paginator, Pager}.path always start with a slash
Fix Paginator.path missing trailing slash in from_taxonomy()
Change tests accordingly
* Update documentation regarding current_path now always starting with a slash
* Fix asymptomatic inverted logic in filter() for {section, page}.assets
* Add to 3 integration tests several checks for current_path in different templates
* Add a check for current_path in a paginated index section, "/page/2/"
This requires adding two dummy pages in the content root.
* Fix false passing of test on paginator.last due to URL prefix matching
A string formatting such as {name: value} can help prevent this.
* 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>
* 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
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
* Change the behavior of the template rendering:
* Check if the template bare name is present
* Check if the template is part of a theme
* Fallback to defaults
* Change the behavior of the shortcode rendering:
* Call the template rendering function
* Prepend `__zola_builtins/` to most of the default elements in `ZOLA_TERA`
* Add a test to verify the presence and content of a `404.html` page
from a theme's template
This commit removes the option to sort by order and also removes
`page.next` and `page.previous` variables. Instead, pages can be sorted
by two methods `date` and `weight`. The Tera `reverse` filter will
reverse either of those sorts, so the old `order` behavior can be
achieved by using the `reverse` filter with `weight`.
In place of the `previous`/`next` variables, this commit adds the
`page.earlier`/`page.later` variables (which are set when the page is
sorted by date) and the `page.heavier`/`page.lighter` variables (which
are set when the page is sorted by weight). These variables have the
advantage of not having confusing semantics when the `reverse` filter is
used.
