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...
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.
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
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
* 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.
In a multilingual context a post's title could be "Title" in English
but «Title» in Bulgarian, and if we apply the Markdown filter to the
title tag, then the language's Black Friday configuration is used,
in this example it would be for the angled quotes.
We already do this everywhere else we can in the post's content, so
let's match it in the page title.
Add categories/tags to front matter and they will be displayed on
summary and post pages, with links to taxonomy pages. Example:
+++
date = "2016-09-24T21:28:31+03:00"
title = "Post title"
categories = ["Nature"]
tags = ["Wetland", "Oasis"]
+++
For some reason if you add tags singularly, like:
categories = "Nature"
you get index errors from Hugo. Not sure if I need to parse the
tags differently or just add more logic to test if the terms are
singular or not.
By default they are on, but you can disable them by adding the
following configuration value:
[params.sharingicons]
hide = true
If this parameter is undefined (or "false") then the icons will be
shown. Furthermore, you can disable specific icons by setting their
value to "false", ie:
[params.sharingicons]
facebook = false
Any icons not named will be shown. Currently there a four icons
configureg: facebook, googleplus, linkedin, and twitter.
The W3C's HTML5 documentation says that header strength (h1–h6) is
only important per section, but their validator[0] recommends only
using one h1.
[0] https://validator.w3.org/
Headers are a semantic element that help computers understand the
content. In general, header tags should follow rank order, but the
most important is that the first header inside a section will serve
as the title in a table of contents, etc, but since article sections
stand alone as independent documents, I like the idea of explicitly
starting with H1 tags.
See: http://diveinto.html5doctor.com/semantics.html
The HTML5 <article> tag represents a complete, or self-contained,
composition in a document. Headers are a semantic HTML5 element
that helps computers understand the content.
Partials are nice, but blocks are a better base construct. Right
now there is basically only layouts/_default/baseof.html that is
doing most of the work.
See: https://gohugo.io/templates/blocks
