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>
Remove a link tag mistakenly imported from Atom XML namespace. The tag
was used to specify the link to the feed itself which is not supported
by RSS 2.0:
https://cyber.harvard.edu/rss/rss.htmlFixes#967
Many servers will return errors (e.g. 400/403) to requests that do not
set a User-Agent header. This results in issues in both the link_checker
and load_data components. With the link_checker these are false positive
dead links. In load_data, remote data fails to be fetched. To mitigate
this issue, this sets a default User-Agent of
$CARGO_PKG_NAME/$CARGO_PKG_VERSION
Note that the root cause of this regression from zola v0.9.0 is that
reqwest 0.10 changed their default behavior and no longer sets a
User-Agent by default:
https://github.com/seanmonstar/reqwest/pull/751Fixes#950.
For the site integration tests, we have a file of common code which is
used by multiple files in `tests/`. However, not all functions in
this file are used by all files in `tests/`.
As Cargo compiles each `tests/*.rs` file as a separate crate, this
means that some of these crates end up with unused code. Rust notices
this and prints a warning.
Let's tell Rust that we don't care about dead code in this file so
that the warning is not printed.
* 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.
The issue with the check_site test hanging and timing out seems to
be related to a similar reqwest issue, which was ultimately due to
an upstream bug in tokio and may be fixed in tokio 0.2.7 onward.
