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.
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
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/
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
* 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.
Hugo's own pagination stuff works just as well and probably covers
even more corner cases. Also, this is one less config variable to
have to check because you can just use Paginate (Default: 10).
Both work effectively the same for my use case, but the "type" is
more obvious when looking at the code. See the documentation for
Hugo's page variables for more info[0].
[0] http://gohugo.io/templates/variables/#page-variables
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
