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
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.
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
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
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
I had overridden it in the theme to improve the metadata generated
by it. Hugo has accepted the changes upstream so we can use theirs
now.
See: https://github.com/spf13/hugo/pull/2984
.Site.LastChange is the date of the last modification on the entire
site, not necessarily on the node we're currently showing, such as
a taxonomy list.
Hugo's current handling of dates in the opengraph partial needs
nome work to be more correct—for example: the usage of published
and updated times. This comes verbatim from the Hugo source tree.
See: tpl/template_embedded.go
This replaces the metadata that Hugo's own schema.html template had
been providing, but does so in JSON-LD notation rather than via the
use of <meta> tags (this is Google's currently recommended form of
specifying this markup). There are a few exceptions where I did not
follow the conventions used in Hugo's template, for example the use
of up to six images from a post's frontmatter, because Google's tool
only recognizes one image, as well as different logic for a post's
publish and modified dates (using enableGitInfo = true).
Using this new markup, Google's Structured Data Testing Tool is now
able to understand site metadata much better (before it was reading
none).
The implementation here is a mix of the elements and types from the
official Schema.org types—for example, Blog and BlogPosting—as well
as from Google's search documentation. Note that Google's docs are
geared towards AMP, where some metadata is required, while for non-
AMP pages the metadata is just recommended.
We will have to re-evaluate this in the future, for example to add
height and width information to image metadata.
See: https://schema.org/Blog
See: https://schema.org/BlogPosting
See: https://developers.google.com/search/docs/data-types/data-type-selector
See: https://search.google.com/structured-data/testing-tool
As of Hugo 0.18 .Site.Pages now returns all pages, including pages,
home, taxonomies, etc, and you are expected to filter them by their
"kind". There is a new variable .Site.RegularPages which returns a
range of "regular" pages like in pre-0.18 Hugo.
In this instance we are limiting the range to pages with the type
"post", so our current behavior works, but I'd rather be consistent
with other ranges we're using, like on the homepage and taxonomy
list pages.
See: https://github.com/spf13/hugo/releases/tag/v0.18
If the user's config doesn't have [params.sidebar] defined they get
errors when trying to build the site. It's better if we just check
that this config block is defined before trying to use it, and then
add something to the docs telling people that the site looks really
bad without this defined.
* Add Vim modeline comments to all relevent template files.
* Add Vim modeline comments to a few other files.
* Move modeline comments inside the template definitions in list and single.
For some odd reason, putting them outside breaks the page generation.
* Use template comments for modeline comments in templates.
* Fix form 2 modelines.
Set the cookie_consent_info_url parameter in your site's config to
display a message about cookie usage to your users. See the config
in `exampleSite/config.toml` for more info.
Instead of writing my own logic for metadata and Twitter cards, I
should be using Hugo's own. This makes my theme code cleaner, but
means I have to adjust some of the configuration conventions that
I have been using. An added bonus is that my theme will work with
more sites now, as long as they are using Hugo's config conventions.
I had added Google Webmaster verify support but it got lost when I
was re-organizing the head meta stuff. I'm adding it back now plus
support for Bing and Yandex.
