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 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
This makes Hugo only list "Regular" pages in the sidebar. Otherwise
if you have very few posts, for example, you might see one entry in
the list called "Posts".
See: https://gohugo.io/functions/where/#mainsections
This became a problem when I added right-to-left language support.
When you mix RTL languages like Arabic with English (even for just
dates and small strings) everything becomes jumbled. For now I have
only added translations for English (default), Arabic, and Bulgarian.
When a site is rendered in Arabic the root HTML element gets the
dir="rtl" attribute, but even Arabic sites might have an English
title or footer, etc so we should set dir="auto" on those elements.
This uses rtlcss to make a right-to-left version of the CSS and then
utilizes Hugo's Language variable to conditionally include it. Also,
we set the "dir" attribute on the HTML tag if the currently rendered
language is Arabic.
The default list template was used for paginating posts on the homepage
as well as the taxonomies and terms pages, but actually those two cases
are different. This introduces a taxonomy template that paginates based
on the current context (ie, when displaying posts for a certain tag).
Hugo 0.32 or so added the quasi-magical .Site.Params.mainSections slice
that returns a range over the section that has the most number of pages.
This way we don't need to hard code the "post" type, and instead simply
use the pages that the user has created. Hugo's quickstart, for example,
recommends users create "posts", which currently doesn't work with this
theme!
Closes#89
Use delimit function over a union of Categories and Tags. This is
much easier to read, results in correct delimiting with no trailing
comma, and works even if one of the slices is nil.
Use delimit function over a union of Categories and Tags. This is
much easier to read, results in correct delimiting with no trailing
comma, and works even if one of the slices is nil.
Some sites using edge caching like that on a CDN or S3 might have
issues with assets being cached too long, causing user agents to
refuse to load assets due to SRI hash mismatch. These sites should
disable the use of sub-resource integrity hashes using this config
option in their config:
disable_sri = true
On sites with multiple languages we need to use the absolute URL in
the test to determine if the current page should be marked "active"
in the menu bar. Perhaps a bug with Hugo that relative links end up
like "/bg/bg/about" instead of "/bg/about".
Don't try to get image information when the image isn't local. We
generally expect that images are in the local filesystem's static
directory, but if the user has specified a remote image—ie, with
an http:// or https:// prefix—then we shouldn't try imageConfig.
This reverts commit bf9bca9656.
If the user specifies a non-local image then the build generates
an error. See #56. We need to have a way to only get imageInfo for
local images...
I had overridden Hugo's OpenGraph template to improve it, but those
changes have been upstreamed in Hugo 0.19. We can use theirs now.
See: https://github.com/spf13/hugo/pull/3073