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.
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.
Uses basic data like title, description, author, and date that we
are using with existing vanilla meta tags, but extends them to OG
and Twitter Card tags. See [0] and [1].
For the Twitter summary cards specifically, you can optionally add
attribution for your username by adding something like this to your
configuration:
[params.social]
twitter_username = "@mralanorth"
... and for posts with images, you can specify an "image" in the
post's front matter like so:
image = "/2016/09/IMG_20160916_174409.jpg"
And then the theme will opt to use Twitter's "large" summary card.
[0] http://ogp.me/
[1] https://dev.twitter.com/cards/getting-started
By default it shows the latest five posts, but you can set this
property in your config to override it:
[params.sidebar]
num_recent_posts = 7
Still no way to disable it, as I don't understand golang's HTML
templating stuff yet. The Hugo docs are a bit confusing, but it
seems like conditionals are a bit tricky because both false and
0 return a boolean false... hmm.
See: https://gohugo.io/templates/go-templates/
Add something like the following to your config to enable the about
block in the sidebar:
[params.sidebar]
about = "*My site* is really cool. Adios!"
Can be formatted in Markdown.
I need to figure out how to generate a list of posts grouped by
month, ie "August 2016", as well as a list template to show the
posts for each month for when the user clicks the link.
The HTML5 aside tag is for content that is tangentially related to
the content around the aside tag, but is considered separate from
that content. Section tags are semantic HTML5 elements that inform
computers about content structure, as opposed to div tags which
can be used for structure OR style.
See: http://diveinto.html5doctor.com/semantics.html
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
I think this should be an H1 since it's in a standalone article tag
but for some reason WordPress' latest themes use an H2, so I'll use
one too until I go read the W3C docs.
