* Detect empty links on markdown rendering and issue an error
* Add a test for empty links stopping rendering with an error
* Assert error message is the expected one
When testing for empty links detection compare the error message
to make sure it's the correct error that stopped the process
and not some unrelated issue.
* 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
Links that start with a scheme (e.g., `tel:18008675309`) inadvertently
had a URL prefix prepended. Previously, only `mailto:` was handled, but
given the sheer number of [registered URI schemes][uri-schemes], a loose
pattern matcher is used to detect schemes instead.
External links, as identified by the renderer, are now limited to `http`
and `https` schemes.
Fixes#747 and fixes#816.
[uri-schemes]: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
* Add check subcommand
* Add some brief documentation for the check subcommand
* Start working on parallel link checks
* Check all external links in Site
* Return *all* dead links in site
Justification for this feature is added in the docs.
Precedent for the precise syntax: Hugo.
Hugo puts this syntax behind a preference named headerIds, and automatic
header ID generation behind a preference named autoHeaderIds, with both
enabled by default. I have not implemented a switch to disable this.
My suggestion for a workaround for the improbable case of desiring a
literal “{#…}” at the end of a header is to replace `}` with `}`.
The algorithm I have used is not identical to [that
which Hugo uses][0], because Hugo’s looks to work at the source level,
whereas here we work at the pulldown-cmark event level, which is
generally more sane, but potentially limiting for extremely esoteric
IDs.
Practical differences in implementation from Hugo (based purely on
reading [blackfriday’s implementation][0], not actually trying it):
- I believe Hugo would treat `# Foo {#*bar*}` as a heading with text
“Foo” and ID `*bar*`, since it is working at the source level; whereas
this code turns it into a heading with HTML `Foo {#<em>bar</em>}`, as
it works at the pulldown-cmark event level and doesn’t go out of its
way to make that work (I’m not familiar with pulldown-cmark, but I get
the impression that you could make it work Hugo’s way on this point).
The difference should be negligible: only *very* esoteric hashes would
include magic Markdown characters.
- Hugo will automatically generate an ID for `{#}`, whereas what I’ve
coded here will yield a blank ID instead (which feels more correct to
me—`None` versus `Some("")`, and all that).
In practice the results should be identical.
Fixes#433.
[0]: a477dd1646/block.go (L218-L234)
* 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
