When a site is rendered in Arabic the root HTML element gets the
dir="rtl" attribute, but even Arabic sites might have an English
title or footer, etc so we should set dir="auto" on those elements.
This uses rtlcss to make a right-to-left version of the CSS and then
utilizes Hugo's Language variable to conditionally include it. Also,
we set the "dir" attribute on the HTML tag if the currently rendered
language is Arabic.
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
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".
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
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
* 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.
We are explicitly using the site's RSS feed, but after reading the
Hugo RSS docs I think it's better if we use the contextual version
of the RSSlink. This will make the RSS plumbing show a feed for the
current category, tag, section, etc. The example code also adds a
bit of markup to help browsers find the content more easily.
See: https://gohugo.io/templates/rss/
Sites only need to add their Google Analytics tracking ID to their
config:
googleAnalytics = "UA-123-45"
This uses the async version of the Google Analytics code.
Check if the params.sidebar is defined before checking to see if
params.sidebar.hide is true or false. New sites might not have
their config set up properly, so this avoids an error in the case
that params.sidebar isn't defined yet.
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
Still need to figure out how to determine which page we're on so we
can set the "active" class accordingly (for Home we have the IsHome
variable the we can check).
Use the post's author from frontmatter, or else use the author from
the site's config. You MUST have one of these set or else you will
get an error during site generation. I think it's better to force
the user to define an author tag rather than only printing it if
it is defined because it is a good practice to help bots understand
content.
Alan Orth
Paweł Hofman
TommySprat
Cosmin Humeniuc
Noah Zoschke
zidenis
Mathieu GAUTHIER-LAFAYE
DeedleFake
Rassie Smit
Bjørn Erik Pedersen