alanorth/hugo-theme-bootstrap4-blog
1
0
Fork 0
mirror of https://github.com/alanorth/hugo-theme-bootstrap4-blog.git synced 2024-12-19 00:52:19 +01:00
Code Releases Activity
9e0b00038a
hugo-theme-bootstrap4-blog/layouts/_default/single.html

93 lines
2.8 KiB
HTML
Raw Normal View History

layouts/_default/single.html: Markdownify page title 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.
2016-10-06 14:03:35 +02:00
{{ define "title" }}{{ .Title | markdownify }} | {{ .Site.Title }}{{ end }}
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
{{ define "schema-dot-org" }}
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "BlogPosting",
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- /* Google recommends the headline be no more than 110 characters */}}
layouts: Quote some parameters in JSON LD Current Hugo 0.19-DEV doesn't quote these anymore, so we need to add quotes manually. I'm not sure if this is a design decision or not on Hugo's part.
2017-02-21 07:17:19 +01:00
"headline": "{{ substr .Title 0 110 }}",
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
{{- with .Params.images -}}{{ range first 1 . }}
"image": {
"@type": "ImageObject",
layouts/_default/single.html: Only get imageConfig on local images 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.
2017-03-24 15:31:50 +01:00
"url": "{{ . | absURL }}"
{{- /* Don't try to get imageConfig if image param is not local */ -}}
{{- if not (or (hasPrefix . "http://") (hasPrefix . "https://")) -}}
{{- with (imageConfig (printf "/static/%s" .)) -}}
,
Revert "Revert "layouts: Add imageConfig to set height and width"" This reverts commit 5e1b0f40ab55f5fe55f73e26f73974a037eb5855.
2017-03-24 15:02:44 +01:00
"height": "{{ .Height }}",
"width": "{{ .Width }}"
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- end -}}
layouts/_default/single.html: Only get imageConfig on local images 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.
2017-03-24 15:31:50 +01:00
{{ end }}
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
},
{{- end -}}{{ end }}
layouts: Quote some parameters in JSON LD Current Hugo 0.19-DEV doesn't quote these anymore, so we need to add quotes manually. I'm not sure if this is a design decision or not on Hugo's part.
2017-02-21 07:17:19 +01:00
"url": "{{ printf "%s" .Permalink }}",
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
"wordCount": "{{ .WordCount }}",
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- $ISO8601 := "2006-01-02T15:04:05-07:00" }}
{{- if not .PublishDate.IsZero }}
Remove escape characters in formatted date Without the quotes in the template the '+' character will no longer needlessly be escaped as '\x2b'
2019-06-13 00:07:36 +02:00
"datePublished": {{ .PublishDate.Format $ISO8601 }},
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- else }}
Remove escape characters in formatted date Without the quotes in the template the '+' character will no longer needlessly be escaped as '\x2b'
2019-06-13 00:07:36 +02:00
"datePublished": {{ .Date.Format $ISO8601 }},
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- end }}
{{- if not .Lastmod.IsZero }}
Remove escape characters in formatted date Without the quotes in the template the '+' character will no longer needlessly be escaped as '\x2b'
2019-06-13 00:07:36 +02:00
"dateModified": {{ .Lastmod.Format $ISO8601 }},
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- end }}
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
"author": {
"@type": "Person",
layouts: Quote some parameters in JSON LD Current Hugo 0.19-DEV doesn't quote these anymore, so we need to add quotes manually. I'm not sure if this is a design decision or not on Hugo's part.
2017-02-21 07:17:19 +01:00
"name": "{{ .Params.author | default .Site.Params.author }}"
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
}
Configurable keywords for blog posts.
2018-02-02 11:56:19 +01:00
{{- if or (.Params.keywords) (or (.Params.categories) (.Params.tags)) -}}
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
,
layouts: Remove quoting of structured data 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.
2020-03-19 14:22:29 +01:00
"keywords": {{ delimit (union .Params.keywords (union .Params.categories .Params.tags)) ", " }}
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- end }}
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
{{- with .Params.description -}}
,
layouts: Remove quoting of structured data 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.
2020-03-19 14:22:29 +01:00
"description": {{ . }}
Clean up empty whitespace in JSON-LD Use secret formatting feature of Go templates, adding - to blocks to clear whitespace around the tags.
2017-03-24 15:49:26 +01:00
{{- end }}
Add Schema.org implementation based on JSON-LD 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
2017-01-20 14:56:33 +01:00
}
</script>
{{ end }}
Start using Go 1.6's blocks 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
2016-09-01 16:37:27 +02:00
{{ define "main" }}
layouts: Don't assume date_format is defined User can override the date format with date_format, but we should have a default in the case that the user hasn't defined it.
2016-10-18 05:39:41 +02:00
{{ $dateFormat := default "Mon Jan 2, 2006" (index .Site.Params "date_format") }}
layouts: retab after addition of modelines Done in vim using `gg=G` and then `:retab`.
2016-11-24 13:39:39 +01:00
<article class="blog-post">
<header>
Localize "by" and "in" strings in post meta This became a problem when I added right-to-left language support. When you mix RTL languages like Arabic with English (even for just dates and small strings) everything becomes jumbled. For now I have only added translations for English (default), Arabic, and Bulgarian.
2019-04-22 17:51:33 +02:00
<h2 class="blog-post-title" dir="auto"><a href="{{ .Permalink }}">{{ .Title | markdownify }}</a></h2>
<p class="blog-post-meta"><time datetime="{{ .Date.Format "2006-01-02T15:04:05Z07:00" }}">{{ .Date.Format $dateFormat }}</time> {{ i18n "authoredBy" }} {{ .Params.author | default .Site.Params.author }}{{ if or (.Params.categories) (.Params.tags) }} {{ i18n "postedIn" }} {{ partial "meta-terms.html" . }}{{ end }}</p>
layouts: retab after addition of modelines Done in vim using `gg=G` and then `:retab`.
2016-11-24 13:39:39 +01:00
</header>
{{ .Content }}
Add basic sharing icons to the bottom of posts 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.
2016-09-18 16:11:08 +02:00
layouts: retab after addition of modelines Done in vim using `gg=G` and then `:retab`.
2016-11-24 13:39:39 +01:00
{{ if .IsTranslated }}
<h4>{{ i18n "translations" }}</h4>
<ul>
{{ range .Translations }}
<li>
<a href="{{ .Permalink }}">{{ .Lang }}: {{ .Title }}{{ if .IsPage }}{{ end }}</a>
</li>
{{ end }}
</ul>
{{ end }}
layouts/_default/single.html: Adjust Disqus logic 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
2017-01-07 10:22:45 +01:00
layouts/_default/single.html: Simplify sharing icon logic 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".
2017-01-21 18:16:57 +01:00
{{ if or (ne ($.Param "sharingicons") false) (.Site.DisqusShortname) }}
layouts/_default/single.html: Adjust Disqus logic 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
2017-01-07 10:22:45 +01:00
<hr>
<footer>
layouts/_default/single.html: Simplify sharing icon logic 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".
2017-01-21 18:16:57 +01:00
{{ if (ne ($.Param "sharingicons") false) }}
layouts: retab after addition of modelines Done in vim using `gg=G` and then `:retab`.
2016-11-24 13:39:39 +01:00
{{ partial "sharing-icons.html" . }}
Disqus integration for single nodes.
2016-11-01 15:25:44 +01:00
{{ end }}
layouts: retab after addition of modelines Done in vim using `gg=G` and then `:retab`.
2016-11-24 13:39:39 +01:00
layouts/_default/single.html: Adjust Disqus logic 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
2017-01-07 10:22:45 +01:00
{{ if and (.Site.DisqusShortname) (ne .Params.comments false) }}
layouts: Revert to built-in Disqus template Hugo 0.25 improved the embedded Disqus template so we can just use theirs now. See: https://github.com/gohugoio/hugo/pull/3655 See: https://github.com/gohugoio/hugo/pull/3639
2017-07-07 14:31:17 +02:00
{{ template "_internal/disqus.html" . }}
layouts/_default/single.html: Adjust Disqus logic 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
2017-01-07 10:22:45 +01:00
{{ end }}
</footer>
{{ end }}
</article> <!-- /.blog-post -->
Disqus integration for single nodes.
2016-11-01 15:25:44 +01:00
Start using Go 1.6's blocks 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
2016-09-01 16:37:27 +02:00
{{ end }}
Add Vim Modeline Comments to Files (#18) * 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.
2016-11-24 13:33:56 +01:00
{{- /* vim: set ts=2 sw=2 et: */}}
Copy Permalink