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
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
Hugo 0.18 introduced the imageConfig function which allows you to
access the height and width of images, which makes bots consuming
the structured data happy.
.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
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.
Bring the Disqus comments inside the <article> tag. The article has
a sizeable bottom margin seprating it from the blog footer, and if
Disqus comments are active they appear after this margin, and this
looks ugly.
Semantically, I think the comments should actually be inside the
article tag anyways (since they are directly related), as well as
further wrapped in article tags, but we don't control the code that
Disqus injects so we'll have to make do with this.
See: https://www.w3.org/TR/html5/sections.html#the-article-element
Prepending the site's URL to relative links was a hack but at the
time I couldn't understand why href="#" didn't take us to the top
of the page. It turns out that this was because of the <base> tag
that I have now removed.
It was screwing up relative links like the ones in footnotes. I'm
not sure why I added it in the first place, actually, as the docs
specifically say "specifies the base URL to use for all relative
URLs contained within a document".
See: https://developer.mozilla.org/en/docs/Web/HTML/Element/base
