Instead of taking the screenshot of the whole window, I used the
screenshot function in Firefox's responsive design mode to specify
the exact dimensions I wanted.
The image seems to be broken any time I look at it on the GitHub
repository page despite being fine if you click it and view the
original on david-dm.org.
.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.
I'm not sure if it really matters to bots who will parse this (it's
much more important on content pages of course), but using .Date on
nodes like the homepage and taxonomy terms pages will set the date
to be that of the latest post in that range—to me this does indeed
seem to be "time when the object was last updated"[0].
[0] https://developers.facebook.com/docs/reference/opengraph/object-type/website/
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
Allowing users to select specific icons they want to show makes the
configuration and logic a bit tricky. A user brought up the case of
disabling sharing icons on certain pages/posts, and it was actaully
not possible without adding lots of extra logic, not to mention the
pain of having to test all possible configurations.
Instead, it is much simpler to just allow sharing icons to be either
on or off as desired in the site config or page/post frontmatter:
sharingicons = false
Otherwise, sharing icons default to being enabled, as this is most
in line with what would be expected on a "blog".
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
Subresource integrity allows user agents to verify that a fetched
resource has been delivered without unexpected manipulation[0]. I
put theme assets in a json configuration file and save the hashes
to a TOML file that Hugo loads via its theme data mechanism[1].
[0] https://www.w3.org/TR/SRI/
[1] https://gohugo.io/extras/datafiles/
It seems this is actually the preferred way to do it, but something
in the Bootstrap v4 Alpha 6 release—perhaps the upgraded version of
Normalize.css with that release—caused our styles to be overridden
and now I realize that it should have never been working before!
The theme really needs some config options in order to look decent,
so I will change the wording here from "optional" to "recommended".
Hopefully some users actually read this rather sparse readme, as
there have been several GitHub issues opened due to misconfigured
sites.
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.
Since we're using cleancss there is no need to compress or optimize
anything in the node-sass step. Also, the Bootstrap project itself
is using the expanded output style as well so we should too.
The Bootstrap project itself uses this, so I think we should just
use it as well. As an added bonus we actually even save 2KiB from
the size of the generated style.css.
Alan Orth
Ardianta Pargo