Previously we showed the Cookie Usage banner if the site's config
had a cookie consent URL specified. As of 2018-05 (GDPR) it makes
more sense to only display this banner if the site has a Google
Analytics ID set. Because we are using Haven for consent manage-
ment we can now inject Google Analytics automatically after the
user has agreed, so we no longer need to use Hugo's internal te-
mplate.
Haven is newer and more well maintained (and also it is actually
open source instead of open core with an upsell to a paid subscrip-
tion). Haven is configured to be 100% *opt-in* for Google Analytics,
which means it does not load or send a hit until the user agrees.
This is mostly a drop-in replacement, but translations need to make
sure the following strings are updated:
- cookieAccept
- cookieDecline
This reverts commit faa3c3cf5b.
Build took over six minutes for each Node.js version because NVM
had to build each from source. So yeah, let's go back to amd64 VMs.
We need to specify OS and Arch in order to use an LXD container in-
stead of a VM. This should theoretically be much faster according
to the Travis docs. Here we are building on arm64 because there is
no amd64 container support right now, but it shouldn't matter beca-
use we are only doing npm build.
See: https://docs.travis-ci.com/user/reference/overview/
Remove deprecated sudo, update Node.js versions to current actively
maintained and LTS versions, use Ubuntu 18.04 "Bionic" environment
instead of 16.04 "Xenial".
This is similar to other encoding issues we have fixed lately where
we need to make sure Hugo (or Golang's HTML template library) does
not escape our non-ASCII content.
For example, this is how our datetimes end up currently:
<p class="blog-post-meta"><time datetime="2020-01-16T09:23:20+02:00">Thu Jan 16, 2020</time> by Alan Orth
After printing them with `printf` and filtering them with the Hugo
built-in function `safeHTMLAttr` they look like this:
<p class="blog-post-meta"><time datetime="2020-01-16T09:23:20+02:00">Thu Jan 16, 2020</time> by Alan Orth
See: https://github.com/gohugoio/hugo/blob/master/tpl/tplimpl/embedded/templates/opengraph.html
See: https://github.com/alanorth/hugo-theme-bootstrap4-blog/pull/111
I think we actually only need to quote string literals. Otherwise,
it seems that Hugo automatically adds quoting for us, and doesn't
use funny escaping of URLs, special characters, etc.
I don't understand it, but quoting these values causes Hugo to use
escape codes for non-ASCII (?) characters. For example:
"description": "A thriving oasis in Jordan\x27s desert is at risk of disappearing."
Google's Search Console shows the following error:
Unparsable structured data > Bad escape sequence in string
We had a similar issue with dates that was fixed in #111 and the
solution is the same here.
Hard code a trailing slash in URLs for categories and tags to avoid
an HTTP 301 redirect at the very least, and an HTTP 404 at the very
worst (depending on web server configuration).
This is a workaround for a problem caused by our manual construction
of URLs using the categories and tags strings in post front matter.
Hugo's own taxonomy tooling always uses a trailing slash.
See: https://github.com/alanorth/hugo-theme-bootstrap4-blog/issues/128
Nothing really new as far as how we're using Font Awesome, but it is
good to keep up with the times and the tooling. Users that have used
custom fonts in their content or layouts will need to update their
icon prefixes from "fa" to "fas" or "fab" depending on which font
their icon comes from.
See: https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4
I've been using version 10 for a year or so. Looking at the Node.js
LTS schedule I see that version 12 is the latest LTS release so I
guess I'll start using that locally at least.
See: https://nodejs.org/en/about/releases/
Alan Orth
Marcel Mellor
xekon