mirror of
https://github.com/gohugoio/hugo.git
synced 2026-08-26 00:08:53 +00:00
next: Final step of merge
This commit is contained in:
@@ -0,0 +1,3 @@
|
||||
[submodule "themes/gohugoioTheme"]
|
||||
path = themes/gohugoioTheme
|
||||
url = https://github.com/gohugoio/gohugoioTheme.git
|
||||
+13
-6
@@ -1,6 +1,13 @@
|
||||
+++
|
||||
weight = 5
|
||||
[menu]
|
||||
[menu.main]
|
||||
parent = "x"
|
||||
+++
|
||||
---
|
||||
linktitle: ""
|
||||
description: ""
|
||||
godocref: ""
|
||||
publishdate: ""
|
||||
lastmod: ""
|
||||
categories: []
|
||||
tags: []
|
||||
weight: 00
|
||||
slug: ""
|
||||
aliases: []
|
||||
toc: false
|
||||
---
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
linktitle: ""
|
||||
description: ""
|
||||
godocref: ""
|
||||
publishdate: ""
|
||||
lastmod: ""
|
||||
categories: [functions]
|
||||
tags: []
|
||||
ns: ""
|
||||
signature: []
|
||||
workson: []
|
||||
hugoversion: ""
|
||||
aliases: []
|
||||
relatedfuncs: []
|
||||
toc: false
|
||||
deprecated: false
|
||||
needsexamples: true
|
||||
---
|
||||
+9
-10
@@ -1,14 +1,13 @@
|
||||
---
|
||||
date: 2013-07-01T07:32:00Z
|
||||
description: ""
|
||||
lastmod: ""
|
||||
license: ""
|
||||
licenseLink: ""
|
||||
sitelink: http://spf13.com/
|
||||
sourceLink: https://github.com/spf13/spf13.com
|
||||
tags:
|
||||
- personal
|
||||
- blog
|
||||
thumbnail: /img/spf13-tn.jpg
|
||||
title: spf13.com
|
||||
---
|
||||
|
||||
sitelink: ""
|
||||
sourcelink: ""
|
||||
categories: [showcase]
|
||||
tags: []
|
||||
image: ""
|
||||
toc: false
|
||||
notesforauthors: "Go to gohugo.io/contribute/documentation for more info"
|
||||
---
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
linktitle: ""
|
||||
description: ""
|
||||
godocref: ""
|
||||
publishdate: ""
|
||||
lastmod: ""
|
||||
categories: [tutorials]
|
||||
tags: []
|
||||
author: ""
|
||||
authorurl: ""
|
||||
originalurl: ""
|
||||
draft: false
|
||||
aliases: []
|
||||
notesforauthors: "Go to gohugo.io/contribute/documentation for more info."
|
||||
---
|
||||
|
||||
+217
-121
@@ -1,135 +1,231 @@
|
||||
title = "Hugo: A Fast and Flexible Website Generator"
|
||||
baseurl = "http://gohugo.io/"
|
||||
MetaDataFormat = "yaml"
|
||||
pluralizeListTitles = false
|
||||
# We do redirects via Netlify's _redirects file, generated by Hugo (see "outputs" below).
|
||||
disableAliases = true
|
||||
baseurl = "/"
|
||||
canonifyurls = true
|
||||
# Pointing to this file
|
||||
config = "config.toml"
|
||||
enableGitInfo = true
|
||||
paginate= 100
|
||||
copyright = ""
|
||||
defaultContentLanguage = "en"
|
||||
# Set to true to keep url path preserve casing (eg, for sections)
|
||||
disablePathToLower = false
|
||||
# Allows use of emoji shorthand directly in content
|
||||
enableEmoji = true
|
||||
# Set the unicode character used for the "return" link in page footnotes.
|
||||
footnotereturnlinkcontents = "↩"
|
||||
# Create an array of files you don't want hugo to build
|
||||
ignoreFiles = []
|
||||
languageCode = "en-us"
|
||||
# Enable Logging
|
||||
log = true
|
||||
# Log Filepath (if set, logging enabled automatically)
|
||||
logFile = ""
|
||||
# This accepts yaml, toml, or json
|
||||
metaDataFormat = "yaml"
|
||||
# This intelligently adds an "s" to the titles of list pages
|
||||
pluralizelisttitles = false
|
||||
relativeURLs = true
|
||||
# Display memory and timing of different steps of the program
|
||||
stepAnalysis = true
|
||||
# This is the top-level, global site title
|
||||
title = "Hugo"
|
||||
theme = "gohugoioTheme"
|
||||
|
||||
[blackfriday]
|
||||
plainIDAnchors = true
|
||||
# Change this once you've created your theme
|
||||
|
||||
[outputs]
|
||||
home = [ "HTML", "RSS", "REDIR" ]
|
||||
# Set to true to convert mysite/section/ to mysite/section.html
|
||||
uglyURLs = false
|
||||
verbose = false
|
||||
verboseLog = false
|
||||
# Setting this to false will keep hugo from watching for changes during local development
|
||||
watch = true
|
||||
# Add GA Tracking Code Here. This leverages a built-in (ie, "internal") partial from HUGO: https://gohugo.io/extras/analytics#configuring-google-analytics
|
||||
googleAnalytics = "UA-76549364-1"
|
||||
|
||||
[mediaTypes]
|
||||
[mediaTypes."text/netlify"]
|
||||
suffix = ""
|
||||
delimiter = ""
|
||||
[social]
|
||||
twitter = "GoHugoIO"
|
||||
|
||||
[outputFormats]
|
||||
[outputFormats.REDIR]
|
||||
mediatype = "text/netlify"
|
||||
baseName = "_redirects"
|
||||
isPlainText = true
|
||||
notAlternative = true
|
||||
|
||||
#CUSTOM PARAMS
|
||||
[params]
|
||||
description = "Documentation of Hugo, a fast and flexible static site generator built with love by spf13, bep and friends in Go"
|
||||
author = "Steve Francia (spf13) and friends"
|
||||
release = "0.25.1"
|
||||
description = "The world’s fastest framework for building websites"
|
||||
## Used for views in rendered HTML (i.e., rather than using the .Hugo variable)
|
||||
release = "0.20"
|
||||
## Setting this to true will add a "noindex" to *EVERY* page on the site
|
||||
removefromexternalsearch = false
|
||||
## This is used when the BaseURL does not need to modified (eg, in share links or in prerender, prefetch, etc to control for relativeURLs setting); do *not* include trailing slash
|
||||
siteaddress = "https://hugodocs.info"
|
||||
## Gh repo for site footer (include trailing slash)
|
||||
ghrepo = "https://github.com/gohugoio/hugo/"
|
||||
### Edit content repo (set to automatically enter "edit" mode; this is good for "improve this page" links)
|
||||
ghdocsrepo = "https://github.com/gohugoio/hugo/tree/master/docs"
|
||||
## Gitter URL
|
||||
gitter = "https://gitter.im/spf13/hugo"
|
||||
## Discuss Forum URL
|
||||
forum = "https://discourse.gohugo.io/"
|
||||
## Google Tag Manager
|
||||
gtmid = ""
|
||||
|
||||
flex_box_interior_classes = "flex-auto w-100 w-40-l mr3 mb3 bg-white ba b--moon-gray nested-copy-line-height"
|
||||
|
||||
#sidebar_direction = "sidebar_left"
|
||||
|
||||
# MARKDOWN
|
||||
## Configuration for BlackFriday markdown parser: https://github.com/russross/blackfriday
|
||||
[blackfriday]
|
||||
plainIDAnchors = true
|
||||
hrefTargetBlank = true
|
||||
angledQuotes = false
|
||||
latexDashes = true
|
||||
|
||||
## As of v0.20, all content files include a default "categories" value that's the same as the section. This was a cheap future-proofing method and should/could be changed accordingly.
|
||||
[taxonomies]
|
||||
tag = "tags"
|
||||
group = "groups"
|
||||
category = "categories"
|
||||
|
||||
[[menu.main]]
|
||||
name = "Download Hugo"
|
||||
pre = "<i class='fa fa-download'></i>"
|
||||
url = "https://github.com/gohugoio/hugo/releases"
|
||||
weight = -200
|
||||
[[menu.main]]
|
||||
name = "Site Showcase"
|
||||
pre = "<i class='fa fa-cubes'></i>"
|
||||
url = "/showcase/"
|
||||
weight = -180
|
||||
[[menu.main]]
|
||||
name = "Theme Showcase"
|
||||
pre = "<i class='fa fa-puzzle-piece'></i>"
|
||||
url = "http://themes.gohugo.io"
|
||||
weight = -170
|
||||
[[menu.main]]
|
||||
name = "Press & Articles"
|
||||
pre = "<i class='fa fa-bullhorn'></i>"
|
||||
url = "/community/press/"
|
||||
weight = -160
|
||||
[[menu.main]]
|
||||
name = "Discuss Hugo"
|
||||
pre = "<i class='fa fa-comments'></i>"
|
||||
url = "https://discourse.gohugo.io/"
|
||||
weight = -150
|
||||
[[menu.main]]
|
||||
name = "About Hugo"
|
||||
identifier = "about"
|
||||
pre = "<i class='fa fa-heart'></i>"
|
||||
weight = -110
|
||||
[[menu.main]]
|
||||
name = "Release Notes"
|
||||
url = "/release-notes/"
|
||||
pre = "<i class='fa fa-newspaper-o'></i>"
|
||||
weight = -111
|
||||
[[menu.main]]
|
||||
name = "Getting Started"
|
||||
identifier = "getting started"
|
||||
pre = "<i class='fa fa-road'></i>"
|
||||
weight = -100
|
||||
[[menu.main]]
|
||||
name = "Content"
|
||||
identifier = "content"
|
||||
pre = "<i class='fa fa-file-text'></i>"
|
||||
weight = -90
|
||||
[[menu.main]]
|
||||
# High level items
|
||||
|
||||
[[menu.docs]]
|
||||
name = "About Hugo"
|
||||
weight = 1
|
||||
identifier = "about"
|
||||
url = "/about/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Getting Started"
|
||||
weight = 5
|
||||
identifier = "getting-started"
|
||||
url = "/getting-started/"
|
||||
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Themes"
|
||||
weight = 15
|
||||
identifier = "themes"
|
||||
post = "break"
|
||||
url = "/themes/"
|
||||
|
||||
# Core Menus
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Content Management"
|
||||
weight = 20
|
||||
identifier = "content-management"
|
||||
post = "expanded"
|
||||
url = "/content-management/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Templates"
|
||||
weight = 25
|
||||
identifier = "templates"
|
||||
|
||||
url = "/templates/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Functions"
|
||||
weight = 30
|
||||
identifier = "functions"
|
||||
url = "/functions/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Variables"
|
||||
weight = 35
|
||||
identifier = "variables"
|
||||
url = "/variables/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "CLI"
|
||||
weight = 40
|
||||
post = "break"
|
||||
identifier = "commands"
|
||||
url = "/commands/"
|
||||
|
||||
|
||||
|
||||
# LOW LEVEL ITEMS
|
||||
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Troubleshooting"
|
||||
weight = 60
|
||||
identifier = "troubleshooting"
|
||||
url = "/troubleshooting/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Tools"
|
||||
weight = 70
|
||||
identifier = "tools"
|
||||
url = "/tools/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Hosting & Deployment"
|
||||
weight = 80
|
||||
identifier = "hosting-and-deployment"
|
||||
url = "/hosting-and-deployment/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Contribute"
|
||||
weight = 100
|
||||
post = "break"
|
||||
identifier = "contribute"
|
||||
url = "/contribute/"
|
||||
|
||||
[[menu.docs]]
|
||||
name = "Tags"
|
||||
weight = 120
|
||||
identifier = "tags"
|
||||
url = "/tags/"
|
||||
|
||||
|
||||
# [[menu.docs]]
|
||||
# name = "Categories"
|
||||
# weight = 140
|
||||
# identifier = "categories"
|
||||
# url = "/categories/"
|
||||
|
||||
######## QUICKLINKS
|
||||
|
||||
[[menu.quicklinks]]
|
||||
name = "Fundamentals"
|
||||
weight = 1
|
||||
identifier = "fundamentals"
|
||||
url = "/tags/fundamentals/"
|
||||
|
||||
|
||||
|
||||
|
||||
######## GLOBAL ITEMS TO BE SHARED WITH THE HUGO siteaddress
|
||||
|
||||
[[menu.global]]
|
||||
name = "News"
|
||||
weight = 1
|
||||
identifier = "news"
|
||||
url = "/news/"
|
||||
|
||||
[[menu.global]]
|
||||
name = "Docs"
|
||||
weight = 5
|
||||
identifier = "docs"
|
||||
url = "/documentation/"
|
||||
|
||||
[[menu.global]]
|
||||
name = "Themes"
|
||||
weight = 10
|
||||
identifier = "themes"
|
||||
pre = "<i class='fa fa-desktop'></i>"
|
||||
weight = -85
|
||||
[[menu.main]]
|
||||
parent = "themes"
|
||||
name = "Theme Showcase"
|
||||
url = "http://themes.gohugo.io"
|
||||
weight = -170
|
||||
[[menu.main]]
|
||||
name = "Templates"
|
||||
identifier = "layout"
|
||||
pre = "<i class='fa fa-columns'></i>"
|
||||
weight = -80
|
||||
[[menu.main]]
|
||||
name = "Taxonomies"
|
||||
identifier = "taxonomy"
|
||||
pre = "<i class='fa fa-tags'></i>"
|
||||
weight = -70
|
||||
[[menu.main]]
|
||||
name = "Extras"
|
||||
identifier = "extras"
|
||||
pre = "<i class='fa fa-gift'></i>"
|
||||
weight = -60
|
||||
[[menu.main]]
|
||||
url = "https://themes.gohugo.io/"
|
||||
|
||||
# Anything with a weight > 100 gets an external icon
|
||||
[[menu.global]]
|
||||
name = "Community"
|
||||
identifier = "community"
|
||||
pre = "<i class='fa fa-group'></i>"
|
||||
weight = -50
|
||||
[[menu.main]]
|
||||
parent = "community"
|
||||
name = "Discussion Forum"
|
||||
url = "https://discourse.gohugo.io/"
|
||||
weight = 150
|
||||
[[menu.main]]
|
||||
name = "Tutorials"
|
||||
identifier = "tutorials"
|
||||
pre = "<i class='fa fa-book'></i>"
|
||||
weight = -40
|
||||
[[menu.main]]
|
||||
name = "Troubleshooting"
|
||||
identifier = "troubleshooting"
|
||||
pre = "<i class='fa fa-wrench'></i>"
|
||||
weight = -30
|
||||
[[menu.main]]
|
||||
name = "Tools"
|
||||
url = "/tools/"
|
||||
pre = "<i class='fa fa-cogs'></i>"
|
||||
weight = -25
|
||||
[[menu.main]]
|
||||
name = "Hugo Cmd Reference"
|
||||
identifier = "commands"
|
||||
pre = "<i class='fa fa-space-shuttle'></i>"
|
||||
weight = -20
|
||||
url = "/commands/"
|
||||
icon = true
|
||||
identifier = "community"
|
||||
post = "external"
|
||||
url = "https://discourse.gohugo.io/"
|
||||
|
||||
|
||||
[[menu.global]]
|
||||
name = "GitHub"
|
||||
weight = 200
|
||||
identifier = "github"
|
||||
post = "external"
|
||||
url = "https://github.com/gohugoio/hugo"
|
||||
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "Hugo"
|
||||
date: 2017-03-02T12:00:00-05:00
|
||||
features:
|
||||
- heading: Blistering Speed
|
||||
image_path: /images/icon-fast.svg
|
||||
tagline: What's modern about waiting for your site to build?
|
||||
copy: Hugo is the fastest tool of its kind. At <1 ms per page, the average site builds in less than a second.
|
||||
|
||||
- heading: Robust Content Management
|
||||
image_path: /images/icon-content-management.svg
|
||||
tagline: Flexibility rules. Hugo is a content strategist's dream.
|
||||
copy: Hugo supports unlimited content types, taxonomies, menus, dynamic API-driven content, and more, all without plugins.
|
||||
|
||||
- heading: Shortcodes
|
||||
image_path: /images/icon-shortcodes.svg
|
||||
tagline: Hugo's shortcodes are Markdown's hidden superpower.
|
||||
copy: We love the beautiful simplicity of markdown’s syntax, but there are times when we want more flexibility. Hugo shortcodes allow for both beauty and flexibility.
|
||||
|
||||
- heading: Built-in Templates
|
||||
image_path: /images/icon-built-in-templates.svg
|
||||
tagline: Hugo has common patterns to get your work done quickly.
|
||||
copy: Hugo ships with pre-made templates to make quick work of SEO, commenting, analytics and other functions. One line of code, and you're done.
|
||||
|
||||
- heading: Multilingual and i18n
|
||||
image_path: /images/icon-multilingual2.svg
|
||||
tagline: Polyglot baked in.
|
||||
copy: Hugo provides full i18n support for multi-language sites with the same straightforward development experience Hugo users love in single-language sites.
|
||||
|
||||
- heading: Custom Outputs
|
||||
image_path: /images/icon-custom-outputs.svg
|
||||
tagline: HTML not Enough?
|
||||
copy: Hugo allows you to output your content in multiple formats, including JSON or AMP, and makes it easy to create your own.
|
||||
sections:
|
||||
- heading: "100s of Themes"
|
||||
cta: Check out the Hugo's themes.
|
||||
link: http://themes.gohugo.io/
|
||||
color_classes: bg-accent-color white
|
||||
image: /images/homepage-screenshot-hugo-themes.jpg
|
||||
copy: "Hugo provides a robust theming system that is easy to implement but capable of producing even the most complicated websites."
|
||||
- heading: "Capable Templating"
|
||||
cta: Get Started.
|
||||
link: https://hugodocs.info/templates/
|
||||
color_classes: bg-primary-color-light black
|
||||
image: /images/home-page-templating-example.png
|
||||
copy: "Hugo's Go-based templating provides just the right amount of logic to build anything from the simple to complex. If you prefer Jade/Pug-like syntax, you can also use Amber, Ace, or any combination of the three."
|
||||
---
|
||||
|
||||
Hugo is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: About Hugo
|
||||
linktitle: Overview
|
||||
description: Hugo's features, roadmap, license, and motivation.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: []
|
||||
tags: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "about"
|
||||
weight: 1
|
||||
weight: 1
|
||||
draft: false
|
||||
aliases: [/about-hugo/,/docs/]
|
||||
toc: false
|
||||
---
|
||||
|
||||
Hugo is not your average static site generator.
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: The Benefits of Static Site Generators
|
||||
linktitle: The Benefits of Static
|
||||
description: Improved performance, security, ease of use, and exportability of content are just a few of the reasons static site generators are so appealing.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
tags: [ssg,static,performance,security]
|
||||
menu:
|
||||
docs:
|
||||
parent: "about"
|
||||
weight: 30
|
||||
weight: 30
|
||||
sections_weight: 30
|
||||
draft: false
|
||||
aliases: []
|
||||
toc: false
|
||||
---
|
||||
|
||||
The purpose of website generators is to render content into HTML files. Most are "dynamic site generators." That means the HTTP server---i.e., the program that sends files to the browser to be viewed---runs the generator to create a new HTML file every time an end user requests a page.
|
||||
|
||||
Creating the page dynamically requires the HTTP server to have enough memory and CPU to effectively run the generator nonstop. If not, your end user will wait in a queue for the page to be generated.
|
||||
|
||||
Over time, dynamic site generators were programmed to cache their HTML files to prevent unnecessary delays in delivering pages to end users. A cached page is a static version of a web page that is temporarily stored on a server. Sending a cached copy of a web page is faster than generating a new page at the time of request because the majority of the work is already done.
|
||||
|
||||
Hugo is in a family of generators that take caching a step further. All HTML files are rendered on your computer. You can review the files locally before copying them to the computer hosting the HTTP server. Since the HTML files aren't generated dynamically, we say that Hugo is a *static site generator*.
|
||||
|
||||
Not running a website generator on your HTTP server has many benefits. The most noticeable is performance. HTTP servers are *very* good at sending files---so good, in fact, that you can effectively serve the same number of pages with a fraction of the memory and CPU needed for a dynamic site.
|
||||
|
||||
## More on Static Site Generators
|
||||
|
||||
* ["An Introduction to Static Site Generators", David Walsh][]
|
||||
* ["Hugo vs. Wordpress page load speed comparison: Hugo leaves WordPress in its dust", GettingThingsTech][hugovwordpress]
|
||||
* ["Static Site Generators", O-Reilly][]
|
||||
* [StaticGen: Top Open-Source Static Site Generators (GitHub Stars)][]
|
||||
* ["Top 10 Static Website Generators", Netlify blog][]
|
||||
* ["The Resurgence of Static", dotCMS][dotcms]
|
||||
|
||||
|
||||
["An Introduction to Static Site Generators", David Walsh]: https://davidwalsh.name/introduction-static-site-generators
|
||||
["Static Site Generators", O-Reilly]: /documents/oreilly-static-site-generators.pdf
|
||||
["Top 10 Static Website Generators", Netlify blog]: https://www.netlify.com/blog/2016/05/02/top-ten-static-website-generators/
|
||||
[hugovwordpress]: https://gettingthingstech.com/hugo-vs.-wordpress-page-load-speed-comparison-hugo-leaves-wordpress-in-its-dust/
|
||||
[StaticGen: Top Open-Source Static Site Generators (GitHub Stars)]: https://www.staticgen.com/
|
||||
[dotcms]: https://dotcms.com/blog/post/the-resurgence-of-static
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: Hugo Features
|
||||
linktitle: Hugo Features
|
||||
description: Hugo boasts blistering speed, robust content management, and a powerful templating language that make it appropriate for all kinds of static websites.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
menu:
|
||||
docs:
|
||||
parent: "about"
|
||||
weight: 20
|
||||
weight: 20
|
||||
sections_weight: 20
|
||||
draft: false
|
||||
aliases: [/about/features]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## General
|
||||
|
||||
* [Extremely fast][] build times (< .7 ms per page)
|
||||
* Completely cross platform, with [easy installation][install] on macOS, Linux, Windows, and more
|
||||
* Renders changes on the fly with [LiveReload][] as you develop
|
||||
* [Powerful theming][]
|
||||
* [Host your site anywhere][hostanywhere]
|
||||
|
||||
## Organization
|
||||
|
||||
* Straightforward [organization for your projects][], including website sections
|
||||
* Customizable [URLs][]
|
||||
* Support for configurable [taxonomies][], including categories and tags
|
||||
* Ability to [sort content][] as you desire through powerful template [functions][]
|
||||
* Automatic [table of contents][] generation
|
||||
* [Dynamic menu][] creation
|
||||
* [Pretty URLs][] support
|
||||
* [Permalink][] pattern support
|
||||
* Redirects via [aliases][]
|
||||
|
||||
## Content
|
||||
|
||||
* Native Markdown support, as well as other languages through *external helpers* (see [supported formats][])
|
||||
* Support for TOML, YAML, and JSON metadata in [front matter][]
|
||||
* Customizable [homepage][]
|
||||
* Multiple [content types][]
|
||||
* Automatic and user defined [content summaries][]
|
||||
* [Shortcodes][] to enable rich content inside of Markdown
|
||||
* ["Minutes to Read"][pagevars] functionality
|
||||
* ["Wordcount"][pagevars] functionality
|
||||
|
||||
## Additional Features
|
||||
|
||||
* Integrated [Disqus][] comment support
|
||||
* Integrated [Google Analytics][] support
|
||||
* Automatic [RSS][] creation
|
||||
* Support for [Golang][], [Amber], and [Ace][] HTML templates
|
||||
* [Syntax highlighting][] powered by [Pygments][]
|
||||
|
||||
See what's coming next in the [Hugo roadmap][].
|
||||
|
||||
[Ace]: /templates/alternatives/
|
||||
[aliases]: /content-management/urls/#aliases
|
||||
[Amber]: https://github.com/eknkc/amber
|
||||
[content summaries]: /content-management/summaries/
|
||||
[content types]: /content-management/types/
|
||||
[Disqus]: https://disqus.com/
|
||||
[Dynamic menu]: /templates/menus/
|
||||
[Extremely fast]: https://github.com/bep/hugo-benchmark
|
||||
[front matter]: /content-management/front-matter/
|
||||
[functions]: /functions/
|
||||
[Golang]: http://golang.org/pkg/html/template/
|
||||
[Google Analytics]: https://google-analytics.com/
|
||||
[homepage]: /templates/homepage/
|
||||
[hostanywhere]: /hosting-and-deployment/
|
||||
[Hugo roadmap]: /about/roadmap
|
||||
[install]: /getting-started/installing/
|
||||
[LiveReload]: /getting-started/usage/
|
||||
[organization for your projects]: /getting-started/directory-structure/
|
||||
[pagevars]: /variables/page/
|
||||
[Permalink]: /content-management/urls/#permalinks
|
||||
[Powerful theming]: /themes/
|
||||
[Pretty URLs]: /content-management/urls/
|
||||
[Pygments]: http://pygments.org/
|
||||
[RSS]: /templates/rss/
|
||||
[Shortcodes]: /content-management/shortcodes/
|
||||
[sort content]: /templates/
|
||||
[supported formats]: /content-management/formats/
|
||||
[Syntax highlighting]: /tools/syntax-highlighting/
|
||||
[table of contents]: /content-management/toc/
|
||||
[taxonomies]: /content-management/taxonomies/
|
||||
[URLs]: /content-management/urls/
|
||||
@@ -1,29 +1,33 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/license/
|
||||
- /license/
|
||||
- /meta/license/
|
||||
lastmod: 2015-11-25
|
||||
date: 2013-07-01
|
||||
title: Apache License
|
||||
linktitle: License
|
||||
description: Hugo v0.15 and later are released under the Apache 2.0 license.
|
||||
date: 2016-02-01
|
||||
publishdate: 2016-02-01
|
||||
lastmod: 2016-03-02
|
||||
categories: ["about hugo"]
|
||||
tags: ["License","apache"]
|
||||
menu:
|
||||
main:
|
||||
parent: about
|
||||
title: License
|
||||
weight: 50
|
||||
docs:
|
||||
parent: "about"
|
||||
weight: 60
|
||||
weight: 60
|
||||
sections_weight: 60
|
||||
aliases: [/meta/license]
|
||||
toc: true
|
||||
---
|
||||
|
||||
{{% note %}}
|
||||
Hugo v0.15 and later are released under the Apache 2.0 license.
|
||||
Earlier releases were under the Simple Public License.
|
||||
Earlier versions of Hugo were released under the [Simple Public License](https://opensource.org/licenses/Simple-2.0).
|
||||
{{% /note %}}
|
||||
|
||||
Apache License
|
||||
==============
|
||||
_Version 2.0, January 2004_ <br>
|
||||
<http://www.apache.org/licenses/LICENSE-2.0>
|
||||
|
||||
_Version 2.0, January 2004_
|
||||
_<<http://www.apache.org/licenses/>>_
|
||||
*Terms and Conditions for use, reproduction, and distribution*
|
||||
|
||||
### Terms and Conditions for use, reproduction, and distribution
|
||||
|
||||
#### 1. Definitions
|
||||
## 1. Definitions
|
||||
|
||||
“License” shall mean the terms and conditions for use, reproduction, and
|
||||
distribution as defined by Sections 1 through 9 of this document.
|
||||
@@ -77,7 +81,7 @@ owner as “Not a Contribution.”
|
||||
of whom a Contribution has been received by Licensor and subsequently
|
||||
incorporated within the Work.
|
||||
|
||||
#### 2. Grant of Copyright License
|
||||
## 2. Grant of Copyright License
|
||||
|
||||
Subject to the terms and conditions of this License, each Contributor hereby
|
||||
grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free,
|
||||
@@ -85,7 +89,7 @@ irrevocable copyright license to reproduce, prepare Derivative Works of,
|
||||
publicly display, publicly perform, sublicense, and distribute the Work and such
|
||||
Derivative Works in Source or Object form.
|
||||
|
||||
#### 3. Grant of Patent License
|
||||
## 3. Grant of Patent License
|
||||
|
||||
Subject to the terms and conditions of this License, each Contributor hereby
|
||||
grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free,
|
||||
@@ -100,7 +104,7 @@ Contribution incorporated within the Work constitutes direct or contributory
|
||||
patent infringement, then any patent licenses granted to You under this License
|
||||
for that Work shall terminate as of the date such litigation is filed.
|
||||
|
||||
#### 4. Redistribution
|
||||
## 4. Redistribution
|
||||
|
||||
You may reproduce and distribute copies of the Work or Derivative Works thereof
|
||||
in any medium, with or without modifications, and in Source or Object form,
|
||||
@@ -110,102 +114,54 @@ provided that You meet the following conditions:
|
||||
this License; and
|
||||
* **(b)** You must cause any modified files to carry prominent notices stating that You
|
||||
changed the files; and
|
||||
* **(c)** You must retain, in the Source form of any Derivative Works that You distribute,
|
||||
* **\(c)** You must retain, in the Source form of any Derivative Works that You distribute,
|
||||
all copyright, patent, trademark, and attribution notices from the Source form
|
||||
of the Work, excluding those notices that do not pertain to any part of the
|
||||
Derivative Works; and
|
||||
* **(d)** If the Work includes a “NOTICE” text file as part of its distribution, then any
|
||||
Derivative Works that You distribute must include a readable copy of the
|
||||
attribution notices contained within such NOTICE file, excluding those notices
|
||||
that do not pertain to any part of the Derivative Works, in at least one of the
|
||||
following places: within a NOTICE text file distributed as part of the
|
||||
Derivative Works; within the Source form or documentation, if provided along
|
||||
with the Derivative Works; or, within a display generated by the Derivative
|
||||
Works, if and wherever such third-party notices normally appear. The contents of
|
||||
the NOTICE file are for informational purposes only and do not modify the
|
||||
License. You may add Your own attribution notices within Derivative Works that
|
||||
You distribute, alongside or as an addendum to the NOTICE text from the Work,
|
||||
provided that such additional attribution notices cannot be construed as
|
||||
modifying the License.
|
||||
* **(d)** If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
|
||||
|
||||
You may add Your own copyright statement to Your modifications and may provide
|
||||
additional or different license terms and conditions for use, reproduction, or
|
||||
distribution of Your modifications, or for any such Derivative Works as a whole,
|
||||
provided Your use, reproduction, and distribution of the Work otherwise complies
|
||||
with the conditions stated in this License.
|
||||
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
|
||||
|
||||
#### 5. Submission of Contributions
|
||||
## 5. Submission of Contributions
|
||||
|
||||
Unless You explicitly state otherwise, any Contribution intentionally submitted
|
||||
for inclusion in the Work by You to the Licensor shall be under the terms and
|
||||
conditions of this License, without any additional terms or conditions.
|
||||
Notwithstanding the above, nothing herein shall supersede or modify the terms of
|
||||
any separate license agreement you may have executed with Licensor regarding
|
||||
such Contributions.
|
||||
Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
|
||||
|
||||
#### 6. Trademarks
|
||||
## 6. Trademarks
|
||||
|
||||
This License does not grant permission to use the trade names, trademarks,
|
||||
service marks, or product names of the Licensor, except as required for
|
||||
reasonable and customary use in describing the origin of the Work and
|
||||
reproducing the content of the NOTICE file.
|
||||
This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
|
||||
|
||||
#### 7. Disclaimer of Warranty
|
||||
## 7. Disclaimer of Warranty
|
||||
|
||||
Unless required by applicable law or agreed to in writing, Licensor provides the
|
||||
Work (and each Contributor provides its Contributions) on an “AS IS” BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied,
|
||||
including, without limitation, any warranties or conditions of TITLE,
|
||||
NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are
|
||||
solely responsible for determining the appropriateness of using or
|
||||
redistributing the Work and assume any risks associated with Your exercise of
|
||||
permissions under this License.
|
||||
Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
|
||||
|
||||
#### 8. Limitation of Liability
|
||||
## 8. Limitation of Liability
|
||||
|
||||
In no event and under no legal theory, whether in tort (including negligence),
|
||||
contract, or otherwise, unless required by applicable law (such as deliberate
|
||||
and grossly negligent acts) or agreed to in writing, shall any Contributor be
|
||||
liable to You for damages, including any direct, indirect, special, incidental,
|
||||
or consequential damages of any character arising as a result of this License or
|
||||
out of the use or inability to use the Work (including but not limited to
|
||||
damages for loss of goodwill, work stoppage, computer failure or malfunction, or
|
||||
any and all other commercial damages or losses), even if such Contributor has
|
||||
been advised of the possibility of such damages.
|
||||
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
|
||||
|
||||
#### 9. Accepting Warranty or Additional Liability
|
||||
## 9. Accepting Warranty or Additional Liability
|
||||
|
||||
While redistributing the Work or Derivative Works thereof, You may choose to
|
||||
offer, and charge a fee for, acceptance of support, warranty, indemnity, or
|
||||
other liability obligations and/or rights consistent with this License. However,
|
||||
in accepting such obligations, You may act only on Your own behalf and on Your
|
||||
sole responsibility, not on behalf of any other Contributor, and only if You
|
||||
agree to indemnify, defend, and hold each Contributor harmless for any liability
|
||||
incurred by, or claims asserted against, such Contributor by reason of your
|
||||
accepting any such warranty or additional liability.
|
||||
While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
|
||||
|
||||
_END OF TERMS AND CONDITIONS_
|
||||
|
||||
### APPENDIX: How to apply the Apache License to your work
|
||||
## APPENDIX: How to apply the Apache License to your work
|
||||
|
||||
To apply the Apache License to your work, attach the following boilerplate
|
||||
notice, with the fields enclosed by brackets `[]` replaced with your own
|
||||
identifying information. (Don't include the brackets!) The text should be
|
||||
enclosed in the appropriate comment syntax for the file format. We also
|
||||
recommend that a file or class name and description of purpose be included on
|
||||
the same “printed page” as the copyright notice for easier identification within
|
||||
third-party archives.
|
||||
To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets `[]` replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same “printed page” as the copyright notice for easier identification within third-party archives.
|
||||
|
||||
Copyright [yyyy] [name of copyright owner]
|
||||
{{% code file="apache-notice.txt" download="apache-notice.txt" %}}
|
||||
```
|
||||
Copyright [yyyy] [name of copyright owner]
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
```
|
||||
{{% /code %}}
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Roadmap
|
||||
linktitle: Roadmap
|
||||
description: Take a look at what's in the pipeline for future versions of the Hugo project.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [about hugo]
|
||||
tags: [about,contribute,roadmap]
|
||||
menu:
|
||||
docs:
|
||||
parent: "about"
|
||||
weight: 50
|
||||
weight: 50
|
||||
sections_weight: 50
|
||||
draft: false
|
||||
aliases: [/meta/roadmap]
|
||||
toc: false
|
||||
---
|
||||
|
||||
To track Hugo's progress, see our [GitHub Milestones][milestones].
|
||||
|
||||
In no particular order, here are some other features currently being worked on:
|
||||
|
||||
* Even easier deployment to S3, SSH, GitHub, rsync. Give the [hosting and deployment][] section a shot.
|
||||
* Import from other website systems. There are already [existing migration tools][migrate], but they don’t cover all major platforms.
|
||||
* An interactive web-based editor (See the [related forum thread][])
|
||||
* Additional [themes][], which are always ongoing and [contributions are welcome][themescontrib]!
|
||||
* Dynamic image resizing via shortcodes ({{< gh 1014 >}})
|
||||
* Native support for additional content formats (AsciiDoc {{< gh 1435>}}, reST {{< gh 1436 >}})
|
||||
* And, last but not least, [***your*** best ideas!][]
|
||||
|
||||
## Contributions Welcome
|
||||
|
||||
Feel free to [contribute to Hugo's development][devcontribute], [improve Hugo's documentation][doccontribute], or [open a new issue][newissue] if you have an idea for a new feature.
|
||||
|
||||
[#98]: https://github.com/spf13/hugo/issues/98
|
||||
[#1014]: https://github.com/spf13/hugo/issues/1014
|
||||
[#1435]: https://github.com/spf13/hugo/issues/1435
|
||||
[#1436]: https://github.com/spf13/hugo/issues/1436
|
||||
[devcontribute]: /contribute/development/
|
||||
[doccontribute]: /contribute/documentation/
|
||||
[hosting and deployment]: /hosting-and-deployment/
|
||||
[migrate]: /tools/migrations/
|
||||
[milestones]: https://github.com/spf13/hugo/milestone/14
|
||||
[newissue]: https://github.com/spf13/hugo/issues/
|
||||
[related forum thread]: https://disourse.gohugo.io/t/web-based-editor/155
|
||||
[themes]: /themes/
|
||||
[themescontrib]: /contribute/themes/
|
||||
[tutorials]: /tutorials
|
||||
[***your*** best ideas!]: /contribute/
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: What is Hugo
|
||||
linktitle: What is Hugo
|
||||
description: Hugo is a fast and modern static site generator written in Go and designed to make website creation fun again.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
layout: single
|
||||
menu:
|
||||
main:
|
||||
parent: "about"
|
||||
weight: 10
|
||||
weight: 10
|
||||
sections_weight: 10
|
||||
draft: false
|
||||
aliases: [/overview/introduction/,/about/why-i-built-hugo/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo is a general-purpose website framework. Technically speaking, Hugo is a [static site generator][]. Unlike systems that dynamically build a page with each visitor request, Hugo builds pages when you create or update your content. Since websites are viewed far more often than they are edited, Hugo is designed to provide an optimal viewing experience for your website's end users and an ideal writing experience for website authors.
|
||||
|
||||
Websites built with Hugo are extremely fast and secure. Hugo sites can be hosted anywhere, including [Netlify][], [Heroku][], [GoDaddy][], [DreamHost][], [GitHub Pages][], [Surge][], [Aerobatic][], [Firebase][], [Google Cloud Storage][], [Amazon S3][], [Rackspace][], [Azure][], and [CloudFront][] and work well with CDNs. Hugo sites run without the need for a database or dependencies on expensive runtimes like Ruby, Python, or PHP.
|
||||
|
||||
We think of Hugo as the ideal website creation tool. Hugo provides nearly instant build times and the ability to rebuild whenever a change is made, which is invaluable when you are designing websites and creating content.
|
||||
|
||||
## How Fast is Hugo?
|
||||
|
||||
{{< youtube "CdiDYZ51a2o" >}}
|
||||
|
||||
## What Does Hugo Do?
|
||||
|
||||
In technical terms, Hugo takes a source directory of files and templates and uses these as input to create a complete website.
|
||||
|
||||
## Who Should Use Hugo?
|
||||
|
||||
Hugo is for people that prefer writing in a text editor over a browser.
|
||||
|
||||
Hugo is for people who want to hand code their own website without worrying about setting up complicated runtimes, dependencies and databases.
|
||||
|
||||
Hugo is for people building a blog, a company site, a portfolio site, documentation, a single landing page, or a website with thousands of pages.
|
||||
|
||||
## Why I Built Hugo
|
||||
|
||||
I wrote Hugo ultimately for a few reasons. First, I was disappointed with WordPress, my then website solution. With it, I couldn't create content as efficiently as I wanted to.
|
||||
|
||||
WordPress sites rendered slowly and required I be online to write posts. WordPress is known for its constant security updates and horror stories of hacked blogs. I hated writing content in HTML instead of the much simpler Markdown. Overall, I felt like WordPress hindered more than helped. It kept me from writing great content.
|
||||
|
||||
I looked at existing static site generators like [Jekyll][], [Middleman][], and [Nanoc][]. All had complicated installation dependencies and an unacceptably long time to render my blog with hundreds of posts. I wanted a framework that would give me rapid feedback while making changes to the templates, and the 5-minute-plus render times were just too slow. In general, the static site generators were very blog-minded and didn't provide for other content types and flexible URLs.
|
||||
|
||||
I wanted to develop a fast and full-featured website framework without any dependencies. The [Go language][] seemed to have all the features I needed. I began developing Hugo in Go and fell in love with the language. I hope you will enjoy using Hugo (and [contributing to it][]) as much as I have writing it.
|
||||
|
||||
―Steve Francia ([@spf13][])
|
||||
|
||||
|
||||
[@spf13]: https://twitter.com/@spf13
|
||||
[Aerobatic]: https://www.aerobatic.com/
|
||||
[Amazon S3]: http://aws.amazon.com/s3/
|
||||
[Azure]: https://blogs.msdn.microsoft.com/acoat/2016/01/28/publish-a-static-web-site-using-azure-web-apps/
|
||||
[CloudFront]: http://aws.amazon.com/cloudfront/ "Amazon CloudFront"
|
||||
[contributing to it]: https://github.com/spf13/hugo
|
||||
[DreamHost]: http://www.dreamhost.com/
|
||||
[Firebase]: https://firebase.google.com/docs/hosting/ "Firebase static hosting"
|
||||
[GitHub Pages]: https://pages.github.com/
|
||||
[GitLab]: https://about.gitlab.com
|
||||
[Go language]: https://golang.org/
|
||||
[GoDaddy]: https://www.godaddy.com/ "Godaddy.com Hosting"
|
||||
[Google Cloud Storage]: http://cloud.google.com/storage/
|
||||
[Heroku]: https://www.heroku.com/
|
||||
[Jekyll]: http://jekyllrb.com/
|
||||
[Jekyll]: https://jekyllrb.com/
|
||||
[Middleman]: https://middlemanapp.com/
|
||||
[Middleman]: https://middlemanapp.com/
|
||||
[Nanoc]: http://nanoc.ws/
|
||||
[Nanoc]: https://nanoc.ws/
|
||||
[Netlify]: https://netlify.com
|
||||
[rackspace]: https://www.rackspace.com/cloud/files
|
||||
[static site generator]: /about/benefits/
|
||||
[Rackspace]: https://www.rackspace.com/cloud/files
|
||||
[static site generator]: /about/benefits/
|
||||
[Surge]: https://surge.sh
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Command Line Reference
|
||||
linktitle: CLI Overview
|
||||
description: Comprehensive list of Hugo templating functions, including basic and advanced usage examples.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [commands]
|
||||
tags: [cli,command line]
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
weight: 1
|
||||
weight: 01 #rem
|
||||
draft: false
|
||||
aliases: [/cli/]
|
||||
---
|
||||
|
||||
The following list contains auto-generated and up-to-date (thanks to [Cobra][]) documentation for all the CLI commands in Hugo.
|
||||
|
||||
|
||||
[Cobra]: https://github.com/spf13/cobra
|
||||
+22
-20
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo
|
||||
url: /commands/hugo/
|
||||
---
|
||||
@@ -19,7 +22,7 @@ built with love by spf13 and friends in Go.
|
||||
Complete documentation is available at http://gohugo.io/.
|
||||
|
||||
```
|
||||
hugo [flags]
|
||||
hugo
|
||||
```
|
||||
|
||||
### Options
|
||||
@@ -31,26 +34,25 @@ hugo [flags]
|
||||
-F, --buildFuture include content with publishdate in the future
|
||||
--cacheDir string filesystem path to cache directory. Defaults: $TMPDIR/hugo_cache/
|
||||
--canonifyURLs if true, all relative URLs will be canonicalized using baseURL
|
||||
--cleanDestinationDir remove files from destination not found in static directories
|
||||
--cleanDestinationDir Remove files from destination not found in static directories
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
-c, --contentDir string filesystem path to content directory
|
||||
-d, --destination string filesystem path to write files to
|
||||
--disable404 do not render 404 page
|
||||
--disableKinds stringSlice disable different kind of pages (home, RSS etc.)
|
||||
--disableRSS do not build RSS files
|
||||
--disableSitemap do not build Sitemap file
|
||||
--enableGitInfo add Git revision, date and author info to the pages
|
||||
--forceSyncStatic copy all files when static is changed.
|
||||
-h, --help help for hugo
|
||||
--i18n-warnings print missing translations
|
||||
--ignoreCache ignores the cache directory
|
||||
--disable404 Do not render 404 page
|
||||
--disableKinds stringSlice Disable different kind of pages (home, RSS etc.)
|
||||
--disableRSS Do not build RSS files
|
||||
--disableSitemap Do not build Sitemap file
|
||||
--enableGitInfo Add Git revision, date and author info to the pages
|
||||
--forceSyncStatic Copy all files when static is changed.
|
||||
--i18n-warnings Print missing translations
|
||||
--ignoreCache Ignores the cache directory
|
||||
-l, --layoutDir string filesystem path to layout directory
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--noChmod don't sync permission mode of files
|
||||
--noTimes don't sync modification time of files
|
||||
--pluralizeListTitles pluralize titles in lists using inflect (default true)
|
||||
--preserveTaxonomyNames preserve taxonomy names as written ("Gérard Depardieu" vs "gerard-depardieu")
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--noChmod Don't sync permission mode of files
|
||||
--noTimes Don't sync modification time of files
|
||||
--pluralizeListTitles Pluralize titles in lists using inflect (default true)
|
||||
--preserveTaxonomyNames Preserve taxonomy names as written ("Gérard Depardieu" vs "gerard-depardieu")
|
||||
--quiet build in quiet mode
|
||||
--renderToMemory render to memory (only useful for benchmark testing)
|
||||
-s, --source string filesystem path to read files relative from
|
||||
@@ -74,7 +76,7 @@ hugo [flags]
|
||||
* [hugo list](/commands/hugo_list/) - Listing out various types of content
|
||||
* [hugo new](/commands/hugo_new/) - Create new content for your site
|
||||
* [hugo server](/commands/hugo_server/) - A high performance webserver
|
||||
* [hugo undraft](/commands/hugo_undraft/) - Undraft resets the content's draft status
|
||||
* [hugo undraft](/commands/hugo_undraft/) - Undraft changes the content's draft status from 'True' to 'False'
|
||||
* [hugo version](/commands/hugo_version/) - Print the version number of Hugo
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo benchmark"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_benchmark
|
||||
url: /commands/hugo_benchmark/
|
||||
---
|
||||
@@ -15,7 +18,7 @@ Hugo can build a site many times over and analyze the running process
|
||||
creating a benchmark.
|
||||
|
||||
```
|
||||
hugo benchmark [flags]
|
||||
hugo benchmark
|
||||
```
|
||||
|
||||
### Options
|
||||
@@ -27,26 +30,25 @@ hugo benchmark [flags]
|
||||
-F, --buildFuture include content with publishdate in the future
|
||||
--cacheDir string filesystem path to cache directory. Defaults: $TMPDIR/hugo_cache/
|
||||
--canonifyURLs if true, all relative URLs will be canonicalized using baseURL
|
||||
--cleanDestinationDir remove files from destination not found in static directories
|
||||
--cleanDestinationDir Remove files from destination not found in static directories
|
||||
-c, --contentDir string filesystem path to content directory
|
||||
-n, --count int number of times to build the site (default 13)
|
||||
--cpuprofile string path/filename for the CPU profile file
|
||||
-d, --destination string filesystem path to write files to
|
||||
--disable404 do not render 404 page
|
||||
--disableKinds stringSlice disable different kind of pages (home, RSS etc.)
|
||||
--disableRSS do not build RSS files
|
||||
--disableSitemap do not build Sitemap file
|
||||
--enableGitInfo add Git revision, date and author info to the pages
|
||||
--forceSyncStatic copy all files when static is changed.
|
||||
-h, --help help for benchmark
|
||||
--i18n-warnings print missing translations
|
||||
--ignoreCache ignores the cache directory
|
||||
--disable404 Do not render 404 page
|
||||
--disableKinds stringSlice Disable different kind of pages (home, RSS etc.)
|
||||
--disableRSS Do not build RSS files
|
||||
--disableSitemap Do not build Sitemap file
|
||||
--enableGitInfo Add Git revision, date and author info to the pages
|
||||
--forceSyncStatic Copy all files when static is changed.
|
||||
--i18n-warnings Print missing translations
|
||||
--ignoreCache Ignores the cache directory
|
||||
-l, --layoutDir string filesystem path to layout directory
|
||||
--memprofile string path/filename for the memory profile file
|
||||
--noChmod don't sync permission mode of files
|
||||
--noTimes don't sync modification time of files
|
||||
--pluralizeListTitles pluralize titles in lists using inflect (default true)
|
||||
--preserveTaxonomyNames preserve taxonomy names as written ("Gérard Depardieu" vs "gerard-depardieu")
|
||||
--noChmod Don't sync permission mode of files
|
||||
--noTimes Don't sync modification time of files
|
||||
--pluralizeListTitles Pluralize titles in lists using inflect (default true)
|
||||
--preserveTaxonomyNames Preserve taxonomy names as written ("Gérard Depardieu" vs "gerard-depardieu")
|
||||
--renderToMemory render to memory (only useful for benchmark testing)
|
||||
-s, --source string filesystem path to read files relative from
|
||||
--stepAnalysis display memory and timing of different steps of the program
|
||||
@@ -59,8 +61,8 @@ hugo benchmark [flags]
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -69,4 +71,4 @@ hugo benchmark [flags]
|
||||
### SEE ALSO
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo check"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_check
|
||||
url: /commands/hugo_check/
|
||||
---
|
||||
@@ -13,18 +16,12 @@ Contains some verification checks
|
||||
|
||||
Contains some verification checks
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for check
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -34,4 +31,4 @@ Contains some verification checks
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
* [hugo check ulimit](/commands/hugo_check_ulimit/) - Check system ulimit settings
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo check ulimit"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_check_ulimit
|
||||
url: /commands/hugo_check_ulimit/
|
||||
---
|
||||
@@ -15,21 +18,15 @@ Hugo will inspect the current ulimit settings on the system.
|
||||
This is primarily to ensure that Hugo can watch enough files on some OSs
|
||||
|
||||
```
|
||||
hugo check ulimit [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for ulimit
|
||||
hugo check ulimit
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -38,4 +35,4 @@ hugo check ulimit [flags]
|
||||
### SEE ALSO
|
||||
* [hugo check](/commands/hugo_check/) - Contains some verification checks
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo config"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_config
|
||||
url: /commands/hugo_config/
|
||||
---
|
||||
@@ -14,21 +17,15 @@ Print the site configuration
|
||||
Print the site configuration, both default and custom settings.
|
||||
|
||||
```
|
||||
hugo config [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for config
|
||||
hugo config
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -37,4 +34,4 @@ hugo config [flags]
|
||||
### SEE ALSO
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo convert"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_convert
|
||||
url: /commands/hugo_convert/
|
||||
---
|
||||
@@ -18,7 +21,6 @@ See convert's subcommands toJSON, toTOML and toYAML for more information.
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for convert
|
||||
-o, --output string filesystem path to write files to
|
||||
-s, --source string filesystem path to read files relative from
|
||||
--unsafe enable less safe operations, please backup first
|
||||
@@ -28,8 +30,8 @@ See convert's subcommands toJSON, toTOML and toYAML for more information.
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -41,4 +43,4 @@ See convert's subcommands toJSON, toTOML and toYAML for more information.
|
||||
* [hugo convert toTOML](/commands/hugo_convert_totoml/) - Convert front matter to TOML
|
||||
* [hugo convert toYAML](/commands/hugo_convert_toyaml/) - Convert front matter to YAML
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo convert toJSON"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_convert_toJSON
|
||||
url: /commands/hugo_convert_tojson/
|
||||
---
|
||||
@@ -15,21 +18,15 @@ toJSON converts all front matter in the content directory
|
||||
to use JSON for the front matter.
|
||||
|
||||
```
|
||||
hugo convert toJSON [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for toJSON
|
||||
hugo convert toJSON
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
-o, --output string filesystem path to write files to
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
@@ -41,4 +38,4 @@ hugo convert toJSON [flags]
|
||||
### SEE ALSO
|
||||
* [hugo convert](/commands/hugo_convert/) - Convert your content to different formats
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo convert toTOML"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_convert_toTOML
|
||||
url: /commands/hugo_convert_totoml/
|
||||
---
|
||||
@@ -15,21 +18,15 @@ toTOML converts all front matter in the content directory
|
||||
to use TOML for the front matter.
|
||||
|
||||
```
|
||||
hugo convert toTOML [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for toTOML
|
||||
hugo convert toTOML
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
-o, --output string filesystem path to write files to
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
@@ -41,4 +38,4 @@ hugo convert toTOML [flags]
|
||||
### SEE ALSO
|
||||
* [hugo convert](/commands/hugo_convert/) - Convert your content to different formats
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo convert toYAML"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_convert_toYAML
|
||||
url: /commands/hugo_convert_toyaml/
|
||||
---
|
||||
@@ -15,21 +18,15 @@ toYAML converts all front matter in the content directory
|
||||
to use YAML for the front matter.
|
||||
|
||||
```
|
||||
hugo convert toYAML [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for toYAML
|
||||
hugo convert toYAML
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
-o, --output string filesystem path to write files to
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
@@ -41,4 +38,4 @@ hugo convert toYAML [flags]
|
||||
### SEE ALSO
|
||||
* [hugo convert](/commands/hugo_convert/) - Convert your content to different formats
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo env"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_env
|
||||
url: /commands/hugo_env/
|
||||
---
|
||||
@@ -14,21 +17,15 @@ Print Hugo version and environment info
|
||||
Print Hugo version and environment info. This is useful in Hugo bug reports.
|
||||
|
||||
```
|
||||
hugo env [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for env
|
||||
hugo env
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -37,4 +34,4 @@ hugo env [flags]
|
||||
### SEE ALSO
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo gen"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_gen
|
||||
url: /commands/hugo_gen/
|
||||
---
|
||||
@@ -13,18 +16,12 @@ A collection of several useful generators.
|
||||
|
||||
A collection of several useful generators.
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for gen
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -36,4 +33,4 @@ A collection of several useful generators.
|
||||
* [hugo gen doc](/commands/hugo_gen_doc/) - Generate Markdown documentation for the Hugo CLI.
|
||||
* [hugo gen man](/commands/hugo_gen_man/) - Generate man pages for the Hugo CLI
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo gen autocomplete"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_gen_autocomplete
|
||||
url: /commands/hugo_gen_autocomplete/
|
||||
---
|
||||
@@ -30,23 +33,22 @@ or just source them in directly:
|
||||
$ . /etc/bash_completion
|
||||
|
||||
```
|
||||
hugo gen autocomplete [flags]
|
||||
hugo gen autocomplete
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--completionfile string autocompletion file (default "/etc/bash_completion.d/hugo.sh")
|
||||
-h, --help help for autocomplete
|
||||
--type string autocompletion type (currently only bash supported) (default "bash")
|
||||
--completionfile string Autocompletion file (default "/etc/bash_completion.d/hugo.sh")
|
||||
--type string Autocompletion type (currently only bash supported) (default "bash")
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -55,4 +57,4 @@ hugo gen autocomplete [flags]
|
||||
### SEE ALSO
|
||||
* [hugo gen](/commands/hugo_gen/) - A collection of several useful generators.
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo gen doc"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_gen_doc
|
||||
url: /commands/hugo_gen_doc/
|
||||
---
|
||||
@@ -20,22 +23,21 @@ It creates one Markdown file per command with front matter suitable
|
||||
for rendering in Hugo.
|
||||
|
||||
```
|
||||
hugo gen doc [flags]
|
||||
hugo gen doc
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--dir string the directory to write the doc. (default "/tmp/hugodoc/")
|
||||
-h, --help help for doc
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -44,4 +46,4 @@ hugo gen doc [flags]
|
||||
### SEE ALSO
|
||||
* [hugo gen](/commands/hugo_gen/) - A collection of several useful generators.
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo gen man"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_gen_man
|
||||
url: /commands/hugo_gen_man/
|
||||
---
|
||||
@@ -16,22 +19,21 @@ command-line interface. By default, it creates the man page files
|
||||
in the "man" directory under the current directory.
|
||||
|
||||
```
|
||||
hugo gen man [flags]
|
||||
hugo gen man
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--dir string the directory to write the man pages. (default "man/")
|
||||
-h, --help help for man
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -40,4 +42,4 @@ hugo gen man [flags]
|
||||
### SEE ALSO
|
||||
* [hugo gen](/commands/hugo_gen/) - A collection of several useful generators.
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo import"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_import
|
||||
url: /commands/hugo_import/
|
||||
---
|
||||
@@ -15,18 +18,12 @@ Import your site from other web site generators like Jekyll.
|
||||
|
||||
Import requires a subcommand, e.g. `hugo import jekyll jekyll_root_path target_path`.
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for import
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -36,4 +33,4 @@ Import requires a subcommand, e.g. `hugo import jekyll jekyll_root_path target_p
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
* [hugo import jekyll](/commands/hugo_import_jekyll/) - hugo import from Jekyll
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo import jekyll"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_import_jekyll
|
||||
url: /commands/hugo_import_jekyll/
|
||||
---
|
||||
@@ -16,22 +19,21 @@ hugo import from Jekyll.
|
||||
Import from Jekyll requires two paths, e.g. `hugo import jekyll jekyll_root_path target_path`.
|
||||
|
||||
```
|
||||
hugo import jekyll [flags]
|
||||
hugo import jekyll
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--force allow import into non-empty target directory
|
||||
-h, --help help for jekyll
|
||||
--force Allow import into non-empty target directory
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -40,4 +42,4 @@ hugo import jekyll [flags]
|
||||
### SEE ALSO
|
||||
* [hugo import](/commands/hugo_import/) - Import your site from others.
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo list"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_list
|
||||
url: /commands/hugo_list/
|
||||
---
|
||||
@@ -18,7 +21,6 @@ List requires a subcommand, e.g. `hugo list drafts`.
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for list
|
||||
-s, --source string filesystem path to read files relative from
|
||||
```
|
||||
|
||||
@@ -26,8 +28,8 @@ List requires a subcommand, e.g. `hugo list drafts`.
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -39,4 +41,4 @@ List requires a subcommand, e.g. `hugo list drafts`.
|
||||
* [hugo list expired](/commands/hugo_list_expired/) - List all posts already expired
|
||||
* [hugo list future](/commands/hugo_list_future/) - List all posts dated in the future
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo list drafts"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_list_drafts
|
||||
url: /commands/hugo_list_drafts/
|
||||
---
|
||||
@@ -14,21 +17,15 @@ List all drafts
|
||||
List all of the drafts in your content directory.
|
||||
|
||||
```
|
||||
hugo list drafts [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for drafts
|
||||
hugo list drafts
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
-v, --verbose verbose output
|
||||
@@ -38,4 +35,4 @@ hugo list drafts [flags]
|
||||
### SEE ALSO
|
||||
* [hugo list](/commands/hugo_list/) - Listing out various types of content
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo list expired"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_list_expired
|
||||
url: /commands/hugo_list_expired/
|
||||
---
|
||||
@@ -15,21 +18,15 @@ List all of the posts in your content directory which has already
|
||||
expired.
|
||||
|
||||
```
|
||||
hugo list expired [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for expired
|
||||
hugo list expired
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
-v, --verbose verbose output
|
||||
@@ -39,4 +36,4 @@ hugo list expired [flags]
|
||||
### SEE ALSO
|
||||
* [hugo list](/commands/hugo_list/) - Listing out various types of content
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo list future"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_list_future
|
||||
url: /commands/hugo_list_future/
|
||||
---
|
||||
@@ -15,21 +18,15 @@ List all of the posts in your content directory which will be
|
||||
posted in the future.
|
||||
|
||||
```
|
||||
hugo list future [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for future
|
||||
hugo list future
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
-v, --verbose verbose output
|
||||
@@ -39,4 +36,4 @@ hugo list future [flags]
|
||||
### SEE ALSO
|
||||
* [hugo list](/commands/hugo_list/) - Listing out various types of content
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo new"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_new
|
||||
url: /commands/hugo_new/
|
||||
---
|
||||
@@ -19,15 +22,15 @@ You can also specify the kind with `-k KIND`.
|
||||
If archetypes are provided in your theme or site, they will be used.
|
||||
|
||||
```
|
||||
hugo new [path] [flags]
|
||||
hugo new [path]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--editor string edit new content with this editor, if provided
|
||||
-h, --help help for new
|
||||
-k, --kind string content type to create
|
||||
-f, --format string frontmatter format (default "toml")
|
||||
-k, --kind string Content type to create
|
||||
-s, --source string filesystem path to read files relative from
|
||||
```
|
||||
|
||||
@@ -35,8 +38,8 @@ hugo new [path] [flags]
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -47,4 +50,4 @@ hugo new [path] [flags]
|
||||
* [hugo new site](/commands/hugo_new_site/) - Create a new site (skeleton)
|
||||
* [hugo new theme](/commands/hugo_new_theme/) - Create a new theme
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo new site"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_new_site
|
||||
url: /commands/hugo_new_site/
|
||||
---
|
||||
@@ -16,23 +19,22 @@ The new site will have the correct structure, but no content or theme yet.
|
||||
Use `hugo new [contentPath]` to create new content.
|
||||
|
||||
```
|
||||
hugo new site [path] [flags]
|
||||
hugo new site [path]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
--force init inside non-empty directory
|
||||
--force Init inside non-empty directory
|
||||
-f, --format string config & frontmatter format (default "toml")
|
||||
-h, --help help for site
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
-v, --verbose verbose output
|
||||
@@ -42,4 +44,4 @@ hugo new site [path] [flags]
|
||||
### SEE ALSO
|
||||
* [hugo new](/commands/hugo_new/) - Create new content for your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo new theme"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_new_theme
|
||||
url: /commands/hugo_new_theme/
|
||||
---
|
||||
@@ -17,21 +20,15 @@ name to the copyright line in the license and adjust the theme.toml file
|
||||
as you see fit.
|
||||
|
||||
```
|
||||
hugo new theme [name] [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for theme
|
||||
hugo new theme [name]
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-s, --source string filesystem path to read files relative from
|
||||
-v, --verbose verbose output
|
||||
@@ -41,4 +38,4 @@ hugo new theme [name] [flags]
|
||||
### SEE ALSO
|
||||
* [hugo new](/commands/hugo_new/) - Create new content for your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo server"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_server
|
||||
url: /commands/hugo_server/
|
||||
---
|
||||
@@ -25,7 +28,7 @@ and push the latest content to them. As most Hugo sites are built in a fraction
|
||||
of a second, you will be able to save and see your changes nearly instantly.
|
||||
|
||||
```
|
||||
hugo server [flags]
|
||||
hugo server
|
||||
```
|
||||
|
||||
### Options
|
||||
@@ -39,28 +42,26 @@ hugo server [flags]
|
||||
-F, --buildFuture include content with publishdate in the future
|
||||
--cacheDir string filesystem path to cache directory. Defaults: $TMPDIR/hugo_cache/
|
||||
--canonifyURLs if true, all relative URLs will be canonicalized using baseURL
|
||||
--cleanDestinationDir remove files from destination not found in static directories
|
||||
--cleanDestinationDir Remove files from destination not found in static directories
|
||||
-c, --contentDir string filesystem path to content directory
|
||||
-d, --destination string filesystem path to write files to
|
||||
--disable404 do not render 404 page
|
||||
--disableKinds stringSlice disable different kind of pages (home, RSS etc.)
|
||||
--disable404 Do not render 404 page
|
||||
--disableKinds stringSlice Disable different kind of pages (home, RSS etc.)
|
||||
--disableLiveReload watch without enabling live browser reload on rebuild
|
||||
--disableRSS do not build RSS files
|
||||
--disableSitemap do not build Sitemap file
|
||||
--enableGitInfo add Git revision, date and author info to the pages
|
||||
--forceSyncStatic copy all files when static is changed.
|
||||
-h, --help help for server
|
||||
--i18n-warnings print missing translations
|
||||
--ignoreCache ignores the cache directory
|
||||
--disableRSS Do not build RSS files
|
||||
--disableSitemap Do not build Sitemap file
|
||||
--enableGitInfo Add Git revision, date and author info to the pages
|
||||
--forceSyncStatic Copy all files when static is changed.
|
||||
--i18n-warnings Print missing translations
|
||||
--ignoreCache Ignores the cache directory
|
||||
-l, --layoutDir string filesystem path to layout directory
|
||||
--meminterval string interval to poll memory usage (requires --memstats), valid time units are "ns", "us" (or "µs"), "ms", "s", "m", "h". (default "100ms")
|
||||
--memstats string log memory usage to this file
|
||||
--navigateToChanged navigate to changed content file on live browser reload
|
||||
--noChmod don't sync permission mode of files
|
||||
--noTimes don't sync modification time of files
|
||||
--pluralizeListTitles pluralize titles in lists using inflect (default true)
|
||||
--noChmod Don't sync permission mode of files
|
||||
--noTimes Don't sync modification time of files
|
||||
--pluralizeListTitles Pluralize titles in lists using inflect (default true)
|
||||
-p, --port int port on which the server will listen (default 1313)
|
||||
--preserveTaxonomyNames preserve taxonomy names as written ("Gérard Depardieu" vs "gerard-depardieu")
|
||||
--preserveTaxonomyNames Preserve taxonomy names as written ("Gérard Depardieu" vs "gerard-depardieu")
|
||||
--renderToDisk render to Destination path (default is render to memory & serve from there)
|
||||
-s, --source string filesystem path to read files relative from
|
||||
--stepAnalysis display memory and timing of different steps of the program
|
||||
@@ -74,8 +75,8 @@ hugo server [flags]
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -84,4 +85,4 @@ hugo server [flags]
|
||||
### SEE ALSO
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,36 +1,33 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo undraft"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_undraft
|
||||
url: /commands/hugo_undraft/
|
||||
---
|
||||
## hugo undraft
|
||||
|
||||
Undraft resets the content's draft status
|
||||
Undraft changes the content's draft status from 'True' to 'False'
|
||||
|
||||
### Synopsis
|
||||
|
||||
|
||||
Undraft resets the content's draft status
|
||||
Undraft changes the content's draft status from 'True' to 'False'
|
||||
and updates the date to the current date and time.
|
||||
If the content's draft status is 'False', nothing is done.
|
||||
|
||||
```
|
||||
hugo undraft path/to/content [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for undraft
|
||||
hugo undraft path/to/content
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -39,4 +36,4 @@ hugo undraft path/to/content [flags]
|
||||
### SEE ALSO
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
date: 2017-07-06T10:34:39+02:00
|
||||
date: 2017-02-25T10:01:37+01:00
|
||||
title: "hugo version"
|
||||
menu:
|
||||
docs:
|
||||
parent: "commands"
|
||||
slug: hugo_version
|
||||
url: /commands/hugo_version/
|
||||
---
|
||||
@@ -14,21 +17,15 @@ Print the version number of Hugo
|
||||
All software has versions. This is Hugo's.
|
||||
|
||||
```
|
||||
hugo version [flags]
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for version
|
||||
hugo version
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
--config string config file (default is path/config.yaml|json|toml)
|
||||
--log enable Logging
|
||||
--logFile string log File path (if set, logging enabled automatically)
|
||||
--log Enable Logging
|
||||
--logFile string Log File path (if set, logging enabled automatically)
|
||||
--quiet build in quiet mode
|
||||
-v, --verbose verbose output
|
||||
--verboseLog verbose logging
|
||||
@@ -37,4 +34,4 @@ hugo version [flags]
|
||||
### SEE ALSO
|
||||
* [hugo](/commands/hugo/) - hugo builds your site
|
||||
|
||||
###### Auto generated by spf13/cobra on 6-Jul-2017
|
||||
###### Auto generated by spf13/cobra on 25-Feb-2017
|
||||
|
||||
@@ -1,51 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-05-25
|
||||
date: 2013-07-01
|
||||
menu:
|
||||
main:
|
||||
parent: community
|
||||
next: /community/contributing
|
||||
prev: /extras/urls
|
||||
title: Mailing List
|
||||
weight: 10
|
||||
---
|
||||
|
||||
## Discussion Forum
|
||||
|
||||
Hugo has its own [discussion forum](https://discourse.gohugo.io/) powered by [Discourse](http://www.discourse.org/).
|
||||
|
||||
Please use this for all discussions, questions, etc.
|
||||
|
||||
### Twitter
|
||||
|
||||
Get the latest bite-sized news and themes from the Hugo community on Twitter by following [@gohugoio](http://twitter.com/gohugoio).
|
||||
|
||||
## Mailing List
|
||||
|
||||
Hugo has two mailing lists:
|
||||
|
||||
### Announcements
|
||||
Very low traffic. Only releases will be emailed here.
|
||||
|
||||
https://groups.google.com/forum/#!forum/hugo-announce
|
||||
|
||||
### Discussion (Archive)
|
||||
|
||||
**This has been replaced with the [Hugo discussion forum](https://discourse.gohugo.io/).**
|
||||
|
||||
It is available for archival purposes.
|
||||
|
||||
https://groups.google.com/forum/#!forum/hugo-discuss
|
||||
|
||||
|
||||
## Other Resources
|
||||
|
||||
### GoNuts
|
||||
|
||||
For general Go questions or discussion please refer to the Go mailing list.
|
||||
|
||||
https://groups.google.com/forum/#!forum/golang-nuts
|
||||
|
||||
### GitHub Issues
|
||||
|
||||
https://github.com/gohugoio/hugo/issues
|
||||
@@ -1,142 +0,0 @@
|
||||
---
|
||||
lastmod: 2017-03-02
|
||||
date: 2014-03-24T20:00:00Z
|
||||
linktitle: Press
|
||||
notoc: true
|
||||
title: Press, Blogs and Media Coverage
|
||||
weight: 20
|
||||
---
|
||||
|
||||
### Help keep this list up to date
|
||||
|
||||
Know of a post, article or tutorial on Hugo? [Add it to this list](https://github.com/gohugoio/hugoDocs/edit/master/content/community/press.md).
|
||||
|
||||
## Press and Articles
|
||||
|
||||
Hugo has been featured in the following Blog Posts, Press and Media.
|
||||
|
||||
|
||||
| Title | Author | Date |
|
||||
| ------ | ------ | -----: |
|
||||
| [Build, Test, And Deploy Statically Generated Websites With Hugo & CircleCI](https://circleci.com/blog/build-test-deploy-hugo-sites/)| Ricardo N Feliciano | 2017-05-31 |
|
||||
| [Hugo Easy Gallery - Automagical PhotoSwipe image gallery with a one-line shortcode](https://www.liwen.id.au/heg/)| Li-Wen Yip | 2017-03-25 |
|
||||
| [Hugo Tutorial: How to Build & Host a (Very Fast) Static E-Commerce Site](https://snipcart.com/blog/hugo-tutorial-static-site-ecommerce) | Snipcart | 2017-03-12 |
|
||||
| [Automagical image gallery in Hugo with PhotoSwipe and jQuery](https://www.liwen.id.au/photoswipe/)| Li-Wen Yip | 2017-03-04 |
|
||||
| [Adding Isso Comments to Hugo](https://stiobhart.net/2017-02-24-isso-comments/) | Stíobhart Matulevicz | 2017-02-24 |
|
||||
| [Zero to HTTP/2 with AWS and Hugo](https://habd.as/zero-to-http-2-aws-hugo/) | Josh Habdas | 2017-02-16 |
|
||||
| [How to Password Protect a Hugo Site](https://www.aerobatic.com/blog/password-protect-a-hugo-site/) | Aerobatic | 2017-02-19 |
|
||||
| [Switching from Wordpress to Hugo](http://schnuddelhuddel.de/switching-from-wordpress-to-hugo/) | Mario Martelli | 2017-02-19 | ]
|
||||
| [Deploy a Hugo site to Aerobatic with CircleCI ](https://www.aerobatic.com/blog/hugo-github-circleci/) | Aerobatic | 2017-02-14 |
|
||||
| [NPM scripts for building and deploying Hugo site](https://www.aerobatic.com/blog/hugo-npm-buildtool-setup/) | Aerobatic | 2017-02-12 |
|
||||
| [Getting started with Hugo and the plain-blog theme, on NearlyFreeSpeech.Net](https://www.penwatch.net/cms/get_started_plain_blog/) | Li-aung “Lewis” Yip | 2017-02-12 |
|
||||
| [Build a Hugo site using Cloud9 IDE and host on App Engine](https://loyall.ch/lab/2017/01/build-a-static-website-with-cloud9-hugo-and-app-engine/)| Pascal Aubort | 2017-02-05 |
|
||||
| [Hugo Continuous Deployment with Bitbucket Pipelines and Aerobatic](https://www.aerobatic.com/blog/hugo-bitbucket-pipelines/) | Aerobatic | 2017-02-04 |
|
||||
| [How to use Firebase to host a Hugo site](https://www.m0d3rnc0ad.com/post/static-site-firebase/) | Andrew Cuga | 2017-02-04 |
|
||||
| [A publishing workflow for teams using static site generators](https://www.keybits.net/post/publishing-workflow-for-teams-using-static-site-generators/) | Tom Atkins | 2017-01-02 |
|
||||
| [How To Dynamically Use Google Fonts In A Hugo Website](https://stoned.io/web-development/hugo/How-To-Dynamically-Use-Google-Fonts-In-A-Hugo-Website/) | Hash Borgir | 2016-10-27 |
|
||||
| [Embedding Facebook In A Hugo Template](https://stoned.io/web-development/hugo/Embedding-Facebook-In-A-Hugo-Template/) | Hash Borgir | 2016-10-22 |
|
||||
| [通过 Gitlab-cl 将 Hugo blog 自动部署至 GitHub](https://zetaoyang.github.io/post/2016/10/17/gitlab-cl.html) <small>(Chinese, Continious integration)</small> | Zetao Yang | 2016-10-17 |
|
||||
| [A Step-by-Step Guide: Hugo on Netlify](https://www.netlify.com/blog/2016/09/21/a-step-by-step-guide-hugo-on-netlify/) | Eli Williamson | 2016-09-21 |
|
||||
| [Building our site: From Django & Wordpress to a static generator (Part I)](https://tryolabs.com/blog/2016/09/20/building-our-site-django-wordpress-to-static-part-i/) | Alan Descoins | 2016-09-20 |
|
||||
| [A visit to the Workshop: Hugo/Unix/Vim integration](https://blog.afoolishmanifesto.com/posts/hugo-unix-vim-integration/) | fREW Schmidt | 2016-07-22 |
|
||||
| [Webseitenmaschine - Statische Websites mit Hugo erzeugen](http://www.heise.de/ct/ausgabe/2016-12-Statische-Websites-mit-Hugo-erzeugen-3211704.html) <small>(German, $)</small> | Christian Helmbold | 2016-05-27 |
|
||||
| [Cómo hacer sitios web estáticos con Hugo y Go - Platzi](https://www.youtube.com/watch?v=qaXXpdiCHXE) <small>(Video tutorial)</small> | Verónica López | 2016-04-06 |
|
||||
| [CDNOverview: A CDN comparison site made with Hugo](https://www.cloakfusion.com/cdnoverview-cdn-comparison-site-made-hugo/) | Thijs de Zoete | 2016-02-23 |
|
||||
| [Hugo: A Modern WebSite Engine That Just Works](https://github.com/shekhargulati/52-technologies-in-2016/blob/master/07-hugo/README.md) | Shekhar Gulati | 2016-02-14 |
|
||||
| [Minify Hugo Generated HTML](http://ratson.name/blog/minify-hugo-generated-html/) | Ratson | 2016-02-02 |
|
||||
| [<span lang="ja">HugoのデプロイをWerckerからCircle CIに変更した</span> - log](http://log.deprode.net/logs/2016-01-17/) | Deprode | 2016-01-17 |
|
||||
| [Static site generators: el futuro de las webs estáticas<br>(Hugo, Jekyll, Flask y otros)](http://sitelabs.es/static-site-generators-futuro-las-webs-estaticas/) | Eneko Sarasola | 2016-01-09 |
|
||||
| [Writing a Lambda Function for Hugo](https://blog.jolexa.net/post/writing-a-lambda-function-for-hugo/) | Jeremy Olexa | 2016-01-01 |
|
||||
| [Ein Blog mit Hugo erstellen - Tutorial](http://privat.albicker.org/tags/hugo.html) <small>(Deutsch/German)</small> | Bernhard Albicker | 2015-12-30 |
|
||||
| [How to host Hugo static website generator on AWS Lambda](http://bezdelev.com/post/hugo-aws-lambda-static-website/) | Ilya Bezdelev | 2015-12-15 |
|
||||
| [Migrating from Pelican to Hugo](http://www.softinio.com/post/migrating-from-pelican-to-hugo/) | Salar Rahmanian | 2015-11-29 |
|
||||
| [Static Website Generators Reviewed: Jekyll, Middleman, Roots, Hugo](http://www.smashingmagazine.com/2015/11/static-website-generators-jekyll-middleman-roots-hugo-review/) | Mathias Biilmann Christensen | 2015-11-16 |
|
||||
| [How To Deploy a Hugo Site to Production with Git Hooks on Ubuntu 14.04](https://www.digitalocean.com/community/tutorials/how-to-deploy-a-hugo-site-to-production-with-git-hooks-on-ubuntu-14-04) | Justin Ellingwood | 2015-11-12 |
|
||||
| [How To Install and Use Hugo, a Static Site Generator, on Ubuntu 14.04](https://www.digitalocean.com/community/tutorials/how-to-install-and-use-hugo-a-static-site-generator-on-ubuntu-14-04) | Justin Ellingwood | 2015-11-09 |
|
||||
| [Switching from Wordpress to Hugo](http://justinfx.com/2015/11/08/switching-from-wordpress-to-hugo/) | Justin Israel | 2015-11-08 |
|
||||
| [Hands-on Experience with Hugo as a Static Site Generator](http://usersnap.com/blog/hands-on-experience-with-hugo-static-site-generator/) | Thomas Peham | 2015 -10-15 |
|
||||
| [Statische Webseites mit Hugo erstellen/Vortrag mit Foliensatz (deutsch)](http://sfd.koelnerlinuxtreffen.de/2015/HaraldWeidner/) | Harald Weidner | 2015-09-19 |
|
||||
| [Moving from WordPress to Hugo](http://abhipandey.com/2015/09/moving-to-hugo/) | Abhishek Pandey | 2015-09-15 |
|
||||
| [<span lang="zh-CN">通过webhook将Hugo自动部署至GitHub Pages和GitCafe Pages</span> <small>(Automated deployment)</small>](http://blog.coderzh.com/2015/09/13/use-webhook-automated-deploy-hugo/) | CoderZh | 2015-09-13 |
|
||||
| [<span lang="zh-CN">使用hugo搭建个人博客站点</span> <small>(Using Hugo to build a personal blog site)</small>](http://blog.coderzh.com/2015/08/29/hugo/) | CoderZh | 2015-08-29 |
|
||||
| [Good-Bye Wordpress, Hello Hugo!](http://blog.arminhanisch.de/2015/08/blog-migration-zu-hugo/) <small>(German)</small> | Armin Hanisch | 2015-08-18 |
|
||||
| [Générer votre site web statique avec Hugo <small>(Generate your static site with Hugo)<small>](http://www.linux-pratique.com/?p=191) | Benoît Benedetti | 2015-06-26 |
|
||||
| [<span lang="ja">Hugo向けの新しいテーマを作った</span> <small>(I created a new theme for Hugo)<small>](https://yet.unresolved.xyz/blog/2016/10/03/how-to-make-of-hugo-theme/) | Daisuke Tsuji | 2015-06-20 |
|
||||
| [Hugo - Gerando um site com conteúdo estático. (Portuguese Brazil)](http://blog.ffrizzo.com/posts/hugo/) | Fabiano Frizzo | 2015-06-02 |
|
||||
| [An Introduction to Static Site Generators](http://davidwalsh.name/introduction-static-site-generators) | Eduardo Bouças | 2015-05-20 |
|
||||
| [Hugo Still Rules](http://cheekycoder.com/2015/05/hugo-still-rules/) | Cheeky Coder | 2015-05-18 |
|
||||
| [hugo - Static Site Generator](http://gscacco.github.io/post/hugo/) | G Scaccoio | 2015-05-04 |
|
||||
| [<span lang="ja">WindowsでHugoを使う</span>](http://ureta.net/2015/05/hugo-on-windows/) | <span lang="ja">うれ太郎</span> | 2015-05-01 |
|
||||
| [<span lang="ja">Hugoのshortcodesを用いてサイトにスライドなどを埋め込む</span>](http://blog.yucchiy.com/2015/04/29/hugo-shortcode/) | Yucchiy | 2015-04-29 |
|
||||
| [<span lang="ja">HugoとCircleCIでGitHub PagesにBlogを公開してみたら超簡単だった</span>](http://hori-ryota.github.io/blog/create-blog-with-hugo-and-circleci/) | Hori Ryota | 2015-04-17 |
|
||||
| [10 Best Static Site Generators](http://beebom.com/2015/04/best-static-site-generators) | Aniruddha Mysore | 2015-04-06 |
|
||||
| [Goodbye WordPress; Hello Hugo](http://willwarren.com/2015/04/05/goodbye-wordpress-hello-hugo/) | Will Warren | 2015-04-05 |
|
||||
| [Static Websites with Hugo on Google Cloud Storage](http://www.moxie.io/post/static-websites-with-hugo-on-google-cloud-storage/) | Moxie Input/Output | 2015-04-02 |
|
||||
| [De nuevo iniciando un blog](https://alvarolizama.net/) | Alvaro Lizama | 2015-03-29 |
|
||||
| [We moved our blog from Posthaven to Hugo after only three posts. Why?](http://blog.hypriot.com/post/moved-from-posthaven-to-hugo/) | Hypriot | 2015-03-27 |
|
||||
| [Top Static Site Generators in 2015](http://superdevresources.com/static-site-generators-2015/) | Kanishk Kunal | 2015-03-12 |
|
||||
| [Moving to Hugo](http://abiosoft.com/moving-to-hugo/) | Abiola Ibrahim | 2015-03-08 |
|
||||
| [Migrating a blog (yes, this one!) from Wordpress to Hugo](http://justindunham.net/migrating-from-wordpress-to-hugo/) | Justin Dunham | 2015-02-13 |
|
||||
| [<span lang="ja">blogをoctopressからHugoに乗り換えたメモ</span>](http://blog.jigyakkuma.org/2015/02/11/hugo/) | jigyakkuma | 2015-02-11 |
|
||||
| [<span lang="ja">Hugoでブログをつくった</span>](http://porgy13.github.io/post/new-hugo-blog/) | porgy13 | 2015-02-07 |
|
||||
| [<span lang="ja">Hugoにブログを移行した</span>](http://keichi.net/post/first/) | Keichi Takahashi | 2015-02-04 |
|
||||
| [<span lang="zh-CN">Hugo静态网站生成器中文教程</span>](http://nanshu.wang/post/2015-01-31/) | Nanshu Wang | 2015-01-31 |
|
||||
| [<span lang="ja">Hugo + GitHub Pages + Wercker CI = ¥0(無料)<br>でコマンド 1 発(自動化)でサイト<br>・ブログを公開・運営・分析・収益化</span>](http://qiita.com/yoheimuta/items/8a619cac356bed89a4c9) | Yohei Yoshimuta | 2015-01-31 |
|
||||
| [Running Hugo websites on anynines](http://blog.anynines.com/running-hugo-websites-on-anynines/) | Julian Weber | 2015-01-30 |
|
||||
| [MiddlemanからHugoへ移行した](http://re-dzine.net/2015/01/hugo/) | Haruki Konishi | 2015-01-21 |
|
||||
| [WordPress から Hugo に乗り換えました](http://rakuishi.com/archives/wordpress-to-hugo/) | rakuishi | 2015-01-20 |
|
||||
| [HUGOを使ってサイトを立ち上げる方法](http://qiita.com/syui/items/869538099551f24acbbf) | Syui | 2015-01-17 |
|
||||
| [<span lang="ja">Jekyllが許されるのは小学生までだよね</span>](http://t32k.me/mol/log/hugo/) | Ishimoto Koji | 2015-01-16 |
|
||||
| [Getting started with Hugo](http://anthonyfok.org/post/getting-started-with-hugo/) | Anthony Fok | 2015-01-12 |
|
||||
| [<span lang="zh-CN">把这个博客静态化了</span> <small>(Migrate to Hugo)</small>](http://lich-eng.com/2015/01/03/migrate-to-hugo/)| Li Cheng | 2015-01-03 |
|
||||
| [Porting my blog with Hugo](http://blog.srackham.com/posts/porting-my-blog-with-hugo/) | Stuart Rackham | 2014-12-30 |
|
||||
| [Hugoを使ってみたときのメモ](http://machortz.github.io/posts/usinghugo/) | Machortz | 2014-12-29 |
|
||||
| [OctopressからHugoへ移行した](http://deeeet.com/writing/2014/12/25/hugo/) | Taichi Nakashima | 2014-12-25 |
|
||||
| [Migrating to Hugo From Octopress](http://nathanleclaire.com/blog/2014/12/22/migrating-to-hugo-from-octopress/) | Nathan LeClaire | 2014-12-22 |
|
||||
| [Dynamic Pages with GoHugo.io](http://cyrillschumacher.com/2014/12/21/dynamic-pages-with-gohugo.io/) | Cyrill Schumacher | 2014-12-21 |
|
||||
| [6 Static Blog Generators That Aren’t Jekyll](http://www.sitepoint.com/6-static-blog-generators-arent-jekyll/) | David Turnbull | 2014-12-08 |
|
||||
| [Travel Blogging Setup](http://www.stou.dk/2014/11/travel-blogging-setup/) | Rasmus Stougaard | 2014-11-23 |
|
||||
| [Hosting A Hugo Website Behind Nginx](http://www.bigbeeconsultants.co.uk/blog/hosting-hugo-website-behind-nginx) | Rick Beton | 2014-11-20 |
|
||||
| [<span lang="zh-CN">使用Hugo搭建免费个人Blog</span> <small>(How to use Hugo)</small>](http://ulricqin.com/post/how-to-use-hugo/) | Ulric Qin <span lang="zh-CN">秦晓辉</span> | 2014-11-11 |
|
||||
| [Built in Speed and Built for Speed by Hugo](http://cheekycoder.com/2014/10/built-for-speed-by-hugo/) | Cheeky Coder | 2014-10-30 |
|
||||
| [Hugo para crear sitios web estáticos](http://www.webbizarro.com/noticias/1076/hugo-para-crear-sitios-web-estaticos/) | Web Bizarro | 2014-08-19 |
|
||||
| [Going with hugo](http://www.markuseliasson.se/article/going-with-hugo/) | Markus Eliasson | 2014-08-18 |
|
||||
| [Benchmarking Jekyll, Hugo and Wintersmith](http://fredrikloch.me/post/2014-08-12-Jekyll-and-its-alternatives-from-a-site-generation-point-of-view/) | Fredrik Loch | 2014-08-12 |
|
||||
| [Goodbye Octopress, Hello Hugo!](http://andreimihu.com/blog/2014/08/11/goodbye-octopress-hello-hugo/) | Andrei Mihu | 2014-08-11 |
|
||||
| [Beautiful sites for Open Source projects](http://beautifulopen.com/2014/08/09/hugo/) | Beautiful Open | 2014-08-09 |
|
||||
| [Hugo: Beyond the Defaults](http://npf.io/2014/08/hugo-beyond-the-defaults/) | Nate Finch | 2014-08-08 |
|
||||
| [First Impressions of Hugo](https://peteraba.com/blog/first-impressions-of-hugo/) | Peter Aba | 2014-06-06 |
|
||||
| [New Site Workflow](http://vurt.co.uk/post/new_website/) | Giles Paterson | 2014-08-05 |
|
||||
| [How I Learned to Stop Worrying and Love the (Static) Web](http://cognition.ca/post/about-hugo/) | Joshua McKenty | 2014-08-04 |
|
||||
| [Hugo - Static Site Generator](http://kenwoo.io/blog/hugo---static-site-generator/) | Kenny Woo | 2014-08-03 |
|
||||
| [Hugo Is Friggin' Awesome](http://npf.io/2014/08/hugo-is-awesome/) | Nate Finch | 2014-08-01 |
|
||||
| [<span lang="zh-CN">再次搬家</span> <small>(Move from WordPress to Hugo)</small>](http://www.chingli.com/misc/move-from-wordpress-to-hugo/) | <span lang="zh-CN">青砾</span> (chingli) | 2014-07-12 |
|
||||
| [Embedding Gists in Hugo](http://danmux.com/posts/embedded_gists/) | Dan Mull | 2014-07-05 |
|
||||
| [An Introduction To Hugo](http://www.cirrushosting.com/web-hosting-blog/an-introduction-to-hugo/) | Dan Silber | 2014-07-01 |
|
||||
| [Moving to Hugo](http://danmux.com/posts/hugo_based_blog/) | Dan Mull | 2014-05-29 |
|
||||
| [<span lang="zh-CN">开源之静态站点生成器排行榜</span><br><small>(Leaderboard of open-source static website generators)</small>](http://code.csdn.net/news/2819909) | CSDN.net | 2014-05-23 |
|
||||
| [Finally, a satisfying and effective blog setup](http://michaelwhatcott.com/now-powered-by-hugo/) | Michael Whatcott | 2014-05-20 |
|
||||
| [Hugo from scratch](http://zackofalltrades.com/notes/2014/05/hugo-from-scratch/) | Zack Williams | 2014-05-18 |
|
||||
| [Why I switched away from Jekyll](http://www.jakejanuzelli.com/why-I-switched-away-from-jekyll/) | Jake Januzelli | 2014-05-10 |
|
||||
| [Welcome our new blog](http://blog.ninya.io/posts/welcome-our-new-blog/) | Ninya.io | 2014-04-11 |
|
||||
| [Mission Not Accomplished](http://johnsto.co.uk/blog/mission-not-accomplished/) | Dave Johnston | 2014-04-03 |
|
||||
| [Hugo - A Static Site Builder in Go](http://deepfriedcode.com/post/hugo/) | Deep Fried Code | 2014-03-30 |
|
||||
| [Adventures in Angular Podcast](http://devchat.tv/adventures-in-angular/003-aia-gdes) | Matias Niemela | 2014-03-28 |
|
||||
| [Hugo](http://bra.am/post/hugo/) | bra.am | 2014-03-23 |
|
||||
| [Converting Blogger To Markdown](http://trishagee.github.io/project/atom-to-hugo/) | Trisha Gee | 2014-03-20 |
|
||||
| [Moving to Hugo Static Web Pages](http://tepid.org/tech/hugo-web/) | Tobias Weingartner | 2014-03-16 |
|
||||
| [New Blog Engine: Hugo](https://blog.afoolishmanifesto.com/posts/hugo/) | fREW Schmidt | 2014-03-15 |
|
||||
| [Hugo + gulp.js = Huggle](http://ktmud.github.io/huggle/en/intro/) ([English](http://ktmud.github.io/huggle/en/intro/), [<span lang="zh-CN">中文</span>](http://ktmud.github.io/huggle/zh/intro/)) | Jesse Yang <span lang="zh-CN">杨建超</span> | 2014-03-08 |
|
||||
| [Powered by Hugo](http://kieranhealy.org/blog/archives/2014/02/24/powered-by-hugo/) | Kieran Healy | 2014-02-24 |
|
||||
| [<span lang="ja">静的サイトを素早く構築するために<br>GoLangで作られたジェネレータHugo</span>](http://hamasyou.com/blog/2014/02/21/hugo/)| <div lang="ja" style="line-height: 1.1;">Shogo Hamada<br>濱田章吾</div> | 2014-02-21 |
|
||||
| [Latest Roundup of Useful Tools For Developers](http://codegeekz.com/latest-roundup-of-useful-tools-for-developers/) | CodeGeekz | 2014-02-13 |
|
||||
| [Hugo: Static Site Generator written in Go](http://www.braveterry.com/2014/02/06/hugo-static-site-generator-written-in-go/) | Brave Terry | 2014-02-06 |
|
||||
| [10 Useful HTML5 Tools for Web Designers and Developers](http://designdizzy.com/10-useful-html5-tools-for-web-designers-and-developers/) | Design Dizzy | 2014-02-04 |
|
||||
| [Hugo – Fast, Flexible Static Site Generator](http://cube3x.com/hugo-fast-flexible-static-site-generator/) | Joby Joseph | 2014-01-18 |
|
||||
| [Hugo: A new way to build static website](http://www.w3update.com/opensource/hugo-a-new-way-to-build-static-website.html) | w3update | 2014-01-17 |
|
||||
| [Xaprb now uses Hugo](http://xaprb.com/blog/2014/01/15/using-hugo/) | Baron Schwartz | 2014-01-15 |
|
||||
| [New jQuery Plugins And Resources That Web Designers Need](http://www.designyourway.net/blog/resources/new-jquery-plugins-and-resources-that-web-designers-need/) | Design Your Way | 2014-01-01 |
|
||||
| [On Blog Construction](http://alexla.sh/post/on-blog-construction/) | Alexander Lash | 2013-12-27 |
|
||||
| [Hugo](http://onethingwell.org/post/69070926608/hugo) | One Thing Well | 2013-12-05 |
|
||||
| [In Praise Of Hugo](http://sound-guru.com/blog/post/hello-world/) | sound-guru.com | 2013-10-19 |
|
||||
| [Hosting a blog on S3 and Cloudfront](http://www.danesparza.net/2013/07/hosting-a-blog-on-s3-and-cloudfront/) | Dan Esparza | 2013-07-24 |
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Content Management
|
||||
linktitle: Content Management Overview
|
||||
description: Hugo makes managing large static sites easy with support for archetypes, content types, menus, cross references, summaries, and more.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 1
|
||||
tags: [source, organization]
|
||||
categories: [content management]
|
||||
weight: 01 #rem
|
||||
draft: false
|
||||
aliases: [/content/]
|
||||
toc: false
|
||||
---
|
||||
|
||||
A static site generator needs to extend beyond front matter and a couple templates to be both scalable and *manageable*. Hugo was designed with not only developers in mind, but also content managers and authors.
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: Archetypes
|
||||
linktitle: Archetypes
|
||||
description: Archetypes allow you to create new instances of content types and set default parameters from the command line.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
tags: [archetypes,generators,metadata,front matter]
|
||||
categories: ["content management"]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 70
|
||||
quicklinks:
|
||||
weight: 70 #rem
|
||||
draft: false
|
||||
aliases: [/content/archetypes/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## What are Archetypes?
|
||||
|
||||
**Archetypes** are content files in the [archetypes directory][] of your project that contain preconfigured [front matter][] for your website's [content types][]. Archetypes facilitate consistent metadata across your website content and allow content authors to quickly generate instances of a content type via the `hugo new` command.
|
||||
|
||||
The `hugo new` generator for archetypes assumes your working directory is the content folder at the root of your project. Hugo is able to infer the appropriate archetype by assuming the content type from the content section passed to the CLI command:
|
||||
|
||||
```bash
|
||||
hugo new <content-section>/<file-name.md>
|
||||
```
|
||||
|
||||
We can use this pattern to create a new `.md` file in the `posts` section:
|
||||
|
||||
{{% code file="archetype-example.sh" %}}
|
||||
```bash
|
||||
hugo new posts/my-first-post.md
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% note "Override Content Type in a New File" %}}
|
||||
To override the content type Hugo infers from `[content-section]`, add the `--kind` flag to the end of the `hugo new` command.
|
||||
{{% /note %}}
|
||||
|
||||
Running this command in a new site that does not have default or custom archetypes will create the following file:
|
||||
|
||||
{{% output file="content/posts/my-first-post.md" %}}
|
||||
```toml
|
||||
+++
|
||||
date = "2017-02-01T19:20:04-07:00"
|
||||
title = "my first post"
|
||||
draft = true
|
||||
+++
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
{{% note %}}
|
||||
In this example, if you do not already have a `content/posts` directory, Hugo will create both `content/posts/` and `content/posts/my-first-post.md` for you.
|
||||
{{% /note %}}
|
||||
|
||||
The auto-populated fields are worth examining:
|
||||
|
||||
* `title` is generated from the new content's filename (i.e. in this case, `my-first-post` becomes `"my first post"`)
|
||||
* `date` and `title` are the variables that ship with Hugo and are therefore included in *all* content files created with the Hugo CLI. `date` is generated in [RFC 3339 format][] by way of Golang's [`now()`][] function, which returns the current time.
|
||||
* The third variable, `draft = true`, is *not* inherited by your default or custom archetypes but is included in Hugo's automatically scaffolded `default.md` archetype for convenience.
|
||||
|
||||
Three variables per content file are often not enough for effective content management of larger websites. Luckily, Hugo provides a simple mechanism for extending the number of variables through custom archetypes, as well as default archetypes to keep content creation DRY.
|
||||
|
||||
## Lookup Order for Archetypes
|
||||
|
||||
Similar to the [lookup order for templates][lookup] in your `layouts` directory, Hugo looks for a section- or type-specific archetype, then a default archetype, and finally an internal archetype that ships with Hugo. For example, Hugo will look for an archetype for `content/posts/my-first-post.md` in the following order:
|
||||
|
||||
1. `archetypes/posts.md`
|
||||
2. `archetypes/default.md`
|
||||
3. `themes/<THEME>/archetypes/posts.md`
|
||||
4. `themes/<THEME>/archetypes/default.md` (Auto-generated with `hugo new site`)
|
||||
|
||||
{{% note "Using a Theme Archetype" %}}
|
||||
If you wish to use archetypes that ship with a theme, the `theme` field must be specified in your [configuration file](/getting-started/configuration/).
|
||||
{{% /note %}}
|
||||
|
||||
## Choosing Your Archetype's Front Matter Format
|
||||
|
||||
By default, `hugo new` content files include front matter in the TOML format regardless of the format used in `archetypes/*.md`.
|
||||
|
||||
You can specify a different default format in your site [configuration file][] file using the `metaDataFormat` directive. Possible values are `toml`, `yaml`, and `json`.
|
||||
|
||||
## Default Archetypes
|
||||
|
||||
Default archetypes are convenient if your content's front matter stays consistent across multiple [content sections][sections].
|
||||
|
||||
### Creating the Default Archetype
|
||||
|
||||
When you create a new Hugo project using `hugo new site`, you'll notice that Hugo has already scaffolded a file at `archetypes/default.md`.
|
||||
|
||||
The following examples are from a site that's using `tags` and `categories` as [taxonomies][]. If we assume that all content files will require these two key-values, we can create a `default.md` archetype that *extends* Hugo's base archetype. In this example, we are including "golang" and "hugo" as tags and "web development" as a category.
|
||||
|
||||
{{% code file="archetypes/default.md" %}}
|
||||
```toml
|
||||
+++
|
||||
tags = ["golang", "hugo"]
|
||||
categories = ["web development"]
|
||||
+++
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% warning "EOL Characters in Text Editors"%}}
|
||||
If you get an `EOF error` when using `hugo new`, add a carriage return after the closing `+++` or `---` for your TOML or YAML front matter, respectively. (See the [troubleshooting article on EOF errors](/troubleshooting/eof-error/) for more information.)
|
||||
{{% /warning %}}
|
||||
|
||||
### Using the Default Archetype
|
||||
|
||||
With an `archetypes/default.md` in place, we can use the CLI to create a new post in the `posts` content section:
|
||||
|
||||
{{% code file="new-post-from-default.sh" %}}
|
||||
```bash
|
||||
$ hugo new posts/my-new-post.md
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Hugo then creates a new markdown file with the following front matter:
|
||||
|
||||
{{% output file="content/posts/my-new-post.md" %}}
|
||||
```toml
|
||||
+++
|
||||
categories = ["web development"]
|
||||
date = "2017-02-01T19:20:04-07:00"
|
||||
tags = ["golang", "hugo"]
|
||||
title = "my new post"
|
||||
+++
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
We see that the `title` and `date` key-values have been added in addition to the `tags` and `categories` key-values from `archetypes/default.md`.
|
||||
|
||||
{{% note "Ordering of Front Matter" %}}
|
||||
You may notice that content files created with `hugo new` do not respect the order of the key-values specified in your archetype files. This is a [known issue](https://github.com/spf13/hugo/issues/452).
|
||||
{{% /note %}}
|
||||
|
||||
## Custom Archetypes
|
||||
|
||||
Suppose your site's `posts` section requires more sophisticated front matter than what has been specified in `archetypes/default.md`. You can create a custom archetype for your posts at `archetypes/posts.md` that includes the full set of front matter to be added to the two default archetypes fields.
|
||||
|
||||
### Creating a Custom Archetype
|
||||
|
||||
{{% code file="archetypes/posts.md"%}}
|
||||
```toml
|
||||
+++
|
||||
description = ""
|
||||
tags = ""
|
||||
categories = ""
|
||||
+++
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
### Using a Custom Archetype
|
||||
|
||||
With an `archetypes/posts.md` in place, you can use the Hugo CLI to create a new post with your preconfigured front matter in the `posts` content section:
|
||||
|
||||
{{% code file="new-post-from-custom.sh" %}}
|
||||
```bash
|
||||
$ hugo new posts/post-from-custom.md
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
This time, Hugo recognizes our custom `archetypes/posts.md` archetype and uses it instead of `archetypes/default.md`. The generated file will now include the full list of front matter parameters, as well as the base archetype's `title` and `date`:
|
||||
|
||||
{{% output file="content/posts/post-from-custom-archetype.md" %}}
|
||||
```toml
|
||||
+++
|
||||
categories = ""
|
||||
date = 2017-02-13T17:24:43-08:00
|
||||
description = ""
|
||||
tags = ""
|
||||
title = "post from custom archetype"
|
||||
+++
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
### Hugo Docs Custom Archetype
|
||||
|
||||
As an example of archetypes in practice, the following is the `functions` archetype from the Hugo docs:
|
||||
|
||||
{{% code file="archetypes/functions.md" %}}
|
||||
```yaml
|
||||
{{< readfile file="/themes/gohugoioTheme/archetypes/functions.md" >}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% note %}}
|
||||
The preceding archetype is kept up to date with every Hugo build by using Hugo's [`readFile` function](/functions/readfile/). For similar examples, see [Local File Templates](/templates/files/).
|
||||
{{% /note %}}
|
||||
|
||||
[archetypes directory]: /getting-started/directory-structure/
|
||||
[`now()`]: http://golang.org/pkg/time/#Now
|
||||
[configuration file]: /getting-started/configuration/
|
||||
[sections]: /content-management/sections/
|
||||
[content types]: /content-management/types/
|
||||
[front matter]: /content-management/front-matter/
|
||||
[RFC 3339 format]: https://www.ietf.org/rfc/rfc3339.txt
|
||||
[taxonomies]: /content-management/taxonomies/
|
||||
[lookup]: /templates/lookup/
|
||||
[templates]: /templates/
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
title: Authors
|
||||
linktitle: Authors
|
||||
description:
|
||||
date: 2016-08-22
|
||||
publishdate: 2017-03-12
|
||||
lastmod: 2017-03-12
|
||||
tags: [authors]
|
||||
categories: ["content management"]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 55
|
||||
weight: 55 #rem
|
||||
draft: true
|
||||
aliases: [/content/archetypes/]
|
||||
toc: true
|
||||
comments: Before this page is published, need to also update both site- and page-level variables documentation.
|
||||
---
|
||||
|
||||
|
||||
|
||||
Larger sites often have multiple content authors. Hugo provides standardized author profiles to organize relationships between content and content creators for sites operating under a distributed authorship model.
|
||||
|
||||
## Author Profiles
|
||||
|
||||
You can create a profile containing metadata for each author on your website. These profiles have to be saved under `data/_authors/`. The filename of the profile will later be used as an identifier. This way Hugo can associate content with one or multiple authors. An author's profile can be defined in the JSON, YAML, or TOML format.
|
||||
|
||||
### Example: Author Profile
|
||||
|
||||
Let's suppose Alice Allison is a blogger. A simple unique identifier would be `alice`. Now, we have to create a file called `alice.toml` in the `data/_authors/` directory. The following example is the standardized template written in TOML:
|
||||
|
||||
{{% code file="data/_authors/alice.toml" %}}
|
||||
```toml
|
||||
givenName = "Alice" # or firstName as alias
|
||||
familyName = "Allison" # or lastName as alias
|
||||
displayName = "Alice Allison"
|
||||
thumbnail = "static/authors/alice-thumb.jpg"
|
||||
image = "static/authors/alice-full.jpg"
|
||||
shortBio = "My name is Alice and I'm a blogger."
|
||||
bio = "My name is Alice and I'm a blogger... some other stuff"
|
||||
email = "alice.allison@email.com"
|
||||
weight = 10
|
||||
|
||||
[social]
|
||||
facebook = "alice.allison"
|
||||
twitter = "alice"
|
||||
googleplus = "aliceallison1"
|
||||
website = "www.example.com"
|
||||
|
||||
[params]
|
||||
random = "whatever you want"
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
All variables are optional but it's advised to fill all important ones (e.g. names and biography) because themes can vary in their usage.
|
||||
|
||||
You can store files for the `thumbnail` and `image` attributes in the `static` folder. Then add the path to the photos relative to `static`; e.g., `/static/path/to/thumbnail.jpg`.
|
||||
|
||||
`weight` allows you to define the order of an author in an `.Authors` list and can be accessed on list or via the `.Site.Authors` variable.
|
||||
|
||||
The `social` section contains all the links to the social network accounts of an author. Hugo is able to generate the account links for the most popular social networks automatically. This way, you only have to enter your username. You can find a list of all supported social networks [here](#linking-social-network-accounts-automatically). All other variables, like `website` in the example above remain untouched.
|
||||
|
||||
The `params` section can contain arbitrary data much like the same-named section in the config file. What it contains is up to you.
|
||||
|
||||
## Associating Content Through Identifiers
|
||||
|
||||
Earlier it was mentioned that content can be associated with an author through their corresponding identifier. In our case, blogger Alice has the identifier `alice`. In the front matter of a content file, you can create a list of identifiers and assign it to the `authors` variable. Here are examples for `alice` using YAML and TOML, respectively.
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: Why Hugo is so Awesome
|
||||
date: 2016-08-22T14:27:502:00
|
||||
authors: ["alice"]
|
||||
---
|
||||
|
||||
Nothing to read here. Move along...
|
||||
```
|
||||
|
||||
```toml
|
||||
+++
|
||||
title = Why Hugo is so Awesome
|
||||
date = "2016-08-22T14:27:502:00"
|
||||
authors: ["alice"]
|
||||
+++
|
||||
|
||||
Nothing to read here. Move along...
|
||||
```
|
||||
|
||||
Future authors who might work on this blog post can append their identifiers to the `authors` array in the front matter as well.
|
||||
|
||||
## Working with Templates
|
||||
|
||||
After a successful setup it's time to give some credit to the authors by showing them on the website. Within the templates Hugo provides a list of the author's profiles if they are listed in the `authors` variable within the front matter.
|
||||
|
||||
The list is accessible via the `.Authors` template variable. Printing all authors of a the blog post is straight forward:
|
||||
|
||||
```
|
||||
{{ range .Authors }}
|
||||
{{ .DisplayName }}
|
||||
{{ end }}
|
||||
=> Alice Allison
|
||||
```
|
||||
|
||||
Even if there are co-authors you may only want to show the main author. For this case you can use the `.Author` template variable **(note the singular form)**. The template variable contains the profile of the author that is first listed with his identifier in the front matter.
|
||||
|
||||
{{% note %}}
|
||||
You can find a list of all template variables to access the profile information in [Author Variables](/variables/authors/).
|
||||
{{% /note %}}
|
||||
|
||||
### Linking Social Network Accounts
|
||||
|
||||
As aforementioned, Hugo is able to generate links to profiles of the most popular social networks. The following social networks with their corrersponding identifiers are supported: `github`, `facebook`, `twitter`, `googleplus`, `pinterest`, `instagram`, `youtube` and `linkedin`.
|
||||
|
||||
This is can be done with the `.Social.URL` function. Its only parameter is the name of the social network as they are defined in the profile (e.g. `facebook`, `googleplus`). Custom variables like `website` remain as they are.
|
||||
|
||||
Most articles feature a small section with information about the author at the end. Let's create one containing the author's name, a thumbnail, a (summarized) biography and links to all social networks:
|
||||
|
||||
{{% code file="layouts/partials/author-info.html" download="author-info.html" %}}
|
||||
```html
|
||||
{{ with .Author }}
|
||||
<h3>{{ .DisplayName }}</h3>
|
||||
<img src="{{ .Thumbnail | absURL }}" alt="{{ .DisplayName }}">
|
||||
<p>{{ .ShortBio }}</p>
|
||||
<ul>
|
||||
{{ range $network, $username := .Social }}
|
||||
<li><a href="{{ $.Author.Social.URL $network }}">{{ $network }}</a></li>
|
||||
{{ end }}
|
||||
</ul>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
## Who Published What?
|
||||
|
||||
That question can be answered with a list of all authors and another list containing all articles that they each have written. Now we have to translate this idea into templates. The [taxonomy][] feature allows us to logically group content based on information that they have in common; e.g. a tag or a category. Well, many articles share the same author, so this should sound familiar, right?
|
||||
|
||||
In order to let Hugo know that we want to group content based on their author, we have to create a new taxonomy called `author` (the name corresponds to the variable in the front matter). Here is the snippet in a `config.yaml` and `config.toml`, respectively:
|
||||
|
||||
```yaml
|
||||
taxonomies:
|
||||
author: authors
|
||||
```
|
||||
|
||||
```toml
|
||||
[taxonomies]
|
||||
author = "authors"
|
||||
```
|
||||
|
||||
|
||||
### Listing All Authors
|
||||
|
||||
In the next step we can create a template to list all authors of your website. Later, the list can be accessed at `www.example.com/authors/`. Create a new template in the `layouts/taxonomy/` directory called `authors.term.html`. This template will be exclusively used for this taxonomy.
|
||||
|
||||
{{% code file="layouts/taxonomy/author.term.html" download="author.term.html" %}}
|
||||
```html
|
||||
<ul>
|
||||
{{ range $author, $v := .Data.Terms }}
|
||||
{{ $profile := $.Authors.Get $author }}
|
||||
<li>
|
||||
<a href="{{ printf "%s/%s/" $.Data.Plural $author | absURL }}">
|
||||
{{ $profile.DisplayName }} - {{ $profile.ShortBio }}
|
||||
</a>
|
||||
</li>
|
||||
{{ end }}
|
||||
</ul>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
`.Data.Terms` contains the identifiers of all authors and we can range over it to create a list with all author names. The `$profile` variable gives us access to the profile of the current author. This allows you to generate a nice info box with a thumbnail, a biography and social media links, like at the [end of a blog post](#linking-social-network-accounts-automatically).
|
||||
|
||||
### Listing Each Author's Publications
|
||||
|
||||
Last but not least, we have to create the second list that contains all publications of an author. Each list will be shown in its own page and can be accessed at `www.example.com/authors/<IDENTIFIER>`. Replace `<IDENTIFIER>` with a valid author identifier like `alice`.
|
||||
|
||||
The layout for this page can be defined in the template `layouts/taxonomy/author.html`.
|
||||
|
||||
{{% code file="layouts/taxonomy/author.html" download="author.html" %}}
|
||||
```html
|
||||
{{ range .Data.Pages }}
|
||||
<h2><a href="{{ .Permalink }}">{{ .Title }}</a></h2>
|
||||
<span>written by {{ .Author.DisplayName }}</span>
|
||||
{{ .Summary }}
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
The example above generates a simple list of all posts written by a single author. Inside the loop you've access to the complete set of [page variables][pagevars]. Therefore, you can add additional information about the current posts like the publishing date or the tags.
|
||||
|
||||
With a lot of content this list can quickly become very long. Consider to use the [pagination][] feature. It splits the list into smaller chunks and spreads them over multiple pages.
|
||||
|
||||
[pagevars]: /variables/page/
|
||||
[pagination]: /templates/pagination/
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: Comments
|
||||
linktitle: Comments
|
||||
description: Hugo ships with an internal Disqus template that requires negligible effort to implement, but Disqus isn't the only commenting system that will work with your new Hugo website.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-03-09
|
||||
tags: [sections,content,organization, fundamentals]
|
||||
categories: [project organization]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 140
|
||||
weight: 140 #rem
|
||||
draft: false
|
||||
aliases: [/extras/comments/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
The most common interaction people ask for in static websites is the ability to add comments.
|
||||
|
||||
Hugo ships with support for [Disqus](https://disqus.com/), a third-party service that provides comment and community capabilities to websites via JavaScript.
|
||||
|
||||
Your theme may already support Disqus, but if not, it is easy to add to your templates via [Hugo's built-in Disqus partial][disquspartial].
|
||||
|
||||
## Adding Disqus
|
||||
|
||||
Hugo comes with all the code you need to load Disqus into your templates. Before adding Disqus to your site, you'll need to [set up an account][disqussetup].
|
||||
|
||||
### Configuring Disqus
|
||||
|
||||
Disqus comments require you set a single value in your [site's configuration file][configuration]. The following show the configuration variable in a `config.toml` and `config.yml`, respectively:
|
||||
|
||||
```toml
|
||||
disqusShortname = "yourdiscussshortname"
|
||||
```
|
||||
|
||||
```yaml
|
||||
disqusShortname: "yourdiscussshortname"
|
||||
```
|
||||
|
||||
For many websites, this is enough configuration. However, you also have the option to set the following in the [front matter][] of a single content file:
|
||||
|
||||
* `disqus_identifier`
|
||||
* `disqus_title`
|
||||
* `disqus_url`
|
||||
|
||||
### Rendering Hugo's Built-in Disqus Partial Template
|
||||
|
||||
See [Partial Templates][partials] to learn how to add the Disqus partial to your Hugo website's templates.
|
||||
|
||||
## Commenting Alternatives
|
||||
|
||||
There are a few alternatives to commenting on static sites for those who do not want to use Disqus:
|
||||
|
||||
* [Static Man](https://staticman.net/)
|
||||
* [txtpen](https://txtpen.com)
|
||||
* [IntenseDebate](http://intensedebate.com/)
|
||||
* [Graph Comment][]
|
||||
* [Muut](http://muut.com/)
|
||||
* [isso](http://posativ.org/isso/) (Self-hosted, Python)
|
||||
* [Tutorial on Implementing Isso with Hugo][issotutorial]
|
||||
|
||||
|
||||
<!-- I don't think this is worth including in the documentation since it seems that Steve is no longer supporting or developing this project. rdwatters - 2017-02-29.-->
|
||||
<!-- * [Kaiju](https://github.com/spf13/kaiju) -->
|
||||
|
||||
<!-- ## Kaiju
|
||||
|
||||
[Kaiju](https://github.com/spf13/kaiju) is an open-source project started by [spf13](http://spf13.com/) (Hugo’s author) to bring easy and fast real time discussions to the web.
|
||||
|
||||
Written using Go, Socket.io, and [MongoDB][], Kaiju is very fast and easy to deploy.
|
||||
|
||||
It is in early development but shows promise. If you have interest, please help by contributing via pull request, [opening an issue in the Kaiju GitHub repository][kaijuissue], or [Tweeting about it][tweet]. Every bit helps. -->
|
||||
|
||||
[configuration]: /getting-started/configuration/
|
||||
[disquspartial]: /templates/partials/#disqus
|
||||
[disqussetup]: https://disqus.com/profile/signup/
|
||||
[forum]: https://discourse.gohugo.io
|
||||
[front matter]: /content-management/front-matter/
|
||||
[Graph Comment]: https://graphcomment.com/
|
||||
[kaijuissue]: https://github.com/spf13/kaiju/issues/new
|
||||
[issotutorial]: https://stiobhart.net/2017-02-24-isso-comments/
|
||||
[partials]: /templates/partials/
|
||||
[MongoDB]: https://www.mongodb.com/
|
||||
[tweet]: https://twitter.com/spf13
|
||||
@@ -0,0 +1,215 @@
|
||||
---
|
||||
title: Cross References
|
||||
linktitle:
|
||||
description: Hugo makes it easy to link documents together with the ref and relref shortcodes, which safely provide links to headings inside of your content, whether across documents or within a document.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-03-31
|
||||
categories: [content management]
|
||||
tags: ["cross references","references", "anchors", "urls"]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 100
|
||||
weight: 100 #rem
|
||||
draft: false
|
||||
aliases: [/extras/crossreferences/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo makes it easy to link documents together with `ref` and `relref`, both of which are [built-in Hugo shortcodes][]. These shortcodes are also used to safely provide links to headings inside of your content, whether across documents or within a document. The only difference between `ref` and `relref` is whether the resulting URL is absolute (`http://1.com/about/`) or relative (`/about/`), respectively.
|
||||
|
||||
## Using `ref` and `relref`
|
||||
|
||||
```md
|
||||
{{</* ref "document" */>}}
|
||||
{{</* ref "#anchor" */>}}
|
||||
{{</* ref "document#anchor" */>}}
|
||||
{{</* relref "document" */>}}
|
||||
{{</* relref "#anchor" */>}}
|
||||
{{</* relref "document#anchor" */>}}
|
||||
```
|
||||
|
||||
The single parameter to `ref` is a string with a content `documentname` (e.g., `about.md`) with or without an appended in-document `anchor` (`#who`) without spaces.
|
||||
|
||||
### Document Names
|
||||
|
||||
The `documentname` is the name of a document, including the format extension; this may be just the filename, or the relative path from the `content/` directory. With a document `content/blog/post.md`, either format will produce the same result:
|
||||
|
||||
```md
|
||||
{{</* relref "blog/post.md" */>}} => `/blog/post/`
|
||||
{{</* relref "post.md" */>}} => `/blog/post/`
|
||||
```
|
||||
|
||||
If you have the same filename used across multiple sections, you should only use the relative path format; otherwise, the behavior will be `undefined`. This is best illustrated with an example `content` directory:
|
||||
|
||||
```bash
|
||||
.
|
||||
└── content
|
||||
├── events
|
||||
│ └── my-birthday.md
|
||||
├── galleries
|
||||
│ └── my-birthday.md
|
||||
├── meta
|
||||
│ └── my-article.md
|
||||
└── posts
|
||||
└── my-birthday.md
|
||||
```
|
||||
|
||||
The potential for conflicting `documentname` is more likely in larger sites. Using the example of multiple `my-birthday.md` files, the following shows how these cross references may or may not render when called from within `content/meta/my-article.md`:
|
||||
|
||||
{{% code file="content/meta/my-article.md" copy="false" %}}
|
||||
```md
|
||||
{{</* relref "my-birthday.md" */>}} => /events/my-birthday/ (maybe)
|
||||
{{</* relref "my-birthday.md" */>}} => /posts/my-birthday/ (maybe)
|
||||
{{</* relref "my-birthday.md" */>}} => /galleries/my-birthday/ (maybe)
|
||||
{{</* relref "events/my-birthday.md" */>}} => /events/my-birthday/
|
||||
{{</* relref "galleries/my-birthday.md" */>}} => /galleries/my-birthday/
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
A relative document name must *not* begin with a slash (`/`).
|
||||
```md
|
||||
{{</* relref "/events/my-birthday.md" */>}} => ""
|
||||
```
|
||||
|
||||
### With Multiple Output Formats
|
||||
|
||||
If the page exists in multiple [output formats][], `ref` or `relref` can be used with a output format name:
|
||||
|
||||
```
|
||||
[Neat]({{</* ref "blog/neat.md" "amp" */>}})
|
||||
```
|
||||
|
||||
### Anchors
|
||||
|
||||
When an `anchor` is provided by itself, the current page’s unique identifier will be appended; when an `anchor` is provided appended to `documentname`, the found page's unique identifier will be appended:
|
||||
|
||||
```md
|
||||
{{</* relref "#anchors" */>}} => #anchors:9decaf7
|
||||
{{</* relref "about-hugo/hugo-features.md#content" */>}} => /blog/post/#who:badcafe
|
||||
```
|
||||
|
||||
The above examples render as follows for this very page as well as a reference to the "Content" heading in the Hugo docs features pageyoursite
|
||||
|
||||
```md
|
||||
{{</* relref "#who" */>}} => #who:9decaf7
|
||||
{{</* relref "blog/post.md#who" */>}} => /blog/post/#who:badcafe
|
||||
```
|
||||
|
||||
More information about document unique identifiers and headings can be found [below]({{< ref "#hugo-heading-anchors" >}}).
|
||||
|
||||
### Examples
|
||||
|
||||
* `{{</* ref "blog/post.md" */>}} => http://yoursite.com/blog/post/`
|
||||
* `{{</* ref "post.md#tldr" */>}} => http://yoursite.com/blog/post/#tldr:caffebad`
|
||||
* `{{</* relref "post.md" */>}} => /blog/post/`
|
||||
* `{{</* relref "blog/post.md#tldr" */>}} => /blog/post/#tldr:caffebad`
|
||||
* `{{</* ref "#tldr" */>}} => #tldr:badcaffe`
|
||||
* `{{</* relref "#tldr" */>}} => #tldr:badcaffe`
|
||||
|
||||
## Hugo Heading Anchors
|
||||
|
||||
When using Markdown document types, Hugo generates heading anchors automatically. The generated anchor for this section is `hugo-heading-anchors`. Because the heading anchors are generated automatically, Hugo takes some effort to ensure that heading anchors are unique both inside a document and across the entire site.
|
||||
|
||||
Ensuring heading uniqueness across the site is accomplished with a unique identifier for each document based on its path. Unless a document is renamed or moved between sections *in the filesystem*, the unique identifier for the document will not change: `blog/post.md` will always have a unique identifier of `81df004c333b392d34a49fd3a91ba720`.
|
||||
|
||||
`ref` and `relref` were added so you can make these reference links without having to know the document’s unique identifier. (The links in document tables of contents are automatically up-to-date with this value.)
|
||||
|
||||
```md
|
||||
{{</* relref "content-management/cross-references.md#hugo-heading-anchors" */>}}
|
||||
/content-management/cross-references/#hugo-heading-anchors:77cd9ea530577debf4ce0f28c8dca242
|
||||
```
|
||||
|
||||
What follows is a deeper discussion of *why* and *how* Hugo generates heading anchors. It is not necessary to know this to use `ref` and `relref`, but it may be useful in understanding how some anchors may not match your expectations.
|
||||
|
||||
### How to Generate a Heading Anchor
|
||||
|
||||
Convert the text of the heading to lowercase.
|
||||
|
||||
```
|
||||
Hugo: A Fast & Modern Static Web Engine
|
||||
=> hugo: a fast & modern static web engine
|
||||
```
|
||||
|
||||
Replace anything that isn't an ASCII letter (`a-z`) or number (`0-9`) with a dash (`-`).
|
||||
|
||||
```
|
||||
hugo: a fast & modern static web engine
|
||||
=> hugo--a-fast---modern-static-web-engine
|
||||
```
|
||||
|
||||
Get rid of extra dashes.
|
||||
|
||||
```
|
||||
hugo--a-fast---modern-static-web-engine
|
||||
=> hugo-a-fast-modern-static-web-engine
|
||||
```
|
||||
|
||||
You have just converting the text of a heading to a suitable anchor. If your document has unique heading text, all of the anchors will be unique, too.
|
||||
|
||||
#### Specifying Heading Anchors
|
||||
|
||||
You can also tell Hugo to use a particular heading anchor.
|
||||
|
||||
```md
|
||||
# Hugo: A Fast & Modern Static Web Engine {#hugo-main}
|
||||
```
|
||||
|
||||
Hugo will use `hugo-main` as the heading anchor.
|
||||
|
||||
### What About Duplicate Heading Anchors?
|
||||
|
||||
The technique outlined above works well enough, but some documents have headings with identical text, like the [shortcodes][] page—there are three headings with the text "Example". You can specify heading anchors manually:
|
||||
|
||||
```
|
||||
### Example {#example-1}
|
||||
### Example {#example-2}
|
||||
### Example {#example-3}
|
||||
```
|
||||
|
||||
It’s easy to forget to do that all the time, and Hugo is smart enough to do it for you. It just adds `-x` to the end of each heading it has already seen.
|
||||
|
||||
* `### Example` => `example`
|
||||
* `### Example` => `example-1`
|
||||
* `### Example` => `example-2`
|
||||
|
||||
Sometimes it's a little harder, but Hugo can recover from those, too, by adding more suffixes:
|
||||
|
||||
* `# Heading` → `heading`
|
||||
* `# Heading 1` → `heading-1`
|
||||
* `# Heading` → `heading-1-1`
|
||||
* `# Heading` → `heading-1-2`
|
||||
* `# Heading 1` → `heading-2`
|
||||
|
||||
This can even affect specified heading anchors that come after a generated heading anchor.
|
||||
|
||||
* `# My Heading` → `my-heading`
|
||||
* `# My Heading {#my-heading}` → `my-heading-1`
|
||||
|
||||
{{% note %}}
|
||||
This particular collision and override both unfortunate and unavoidable because Hugo processes each heading for collision detection as it sees it during conversion.
|
||||
{{% /note %}}
|
||||
|
||||
This technique works well for documents rendered on individual pages (e.g., blog posts), but what about [Hugo list pages][lists]?
|
||||
|
||||
### Unique Heading Anchors in Lists
|
||||
|
||||
Hugo converts each document from Markdown independently. It doesn’t know that `blog/post.md` has an "Example" heading that will collide with the "Example" heading in `blog/post2.md`. Even if it did know this, the addition of `blog/post3.md` should not cause the anchors for the headings in the other blog posts to change.
|
||||
|
||||
Enter the document’s unique identifier. To prevent this sort of collision on list pages, Hugo always appends the document's to a generated heading anchor. So, the "Example" heading in `blog/post.md` actually turns into `#example:81df004…`, and the "Example" heading in `blog/post2.md` actually turns into `#example:8cf1599…`. All you have to know is the heading anchor that was generated, not the document identifier; `ref` and `relref` take care of the rest for you.
|
||||
|
||||
```html
|
||||
<a href='{{</* relref "blog/post.md#example" */>}}'>Post Example</a>
|
||||
<a href='/blog/post.md#81df004…'>Post Example</a>
|
||||
```
|
||||
|
||||
```
|
||||
[Post Two Example]({{</* relref "blog/post2.md#example" */>}})
|
||||
<a href='/blog/post2.md#8cf1599…'>Post Two Example</a>
|
||||
```
|
||||
|
||||
[built-in Hugo shortcodes]: /content-management/shortcodes/#using-the-built-in-shortcodes
|
||||
[lists]: /templates/lists/
|
||||
[output formats]: /templates/output-formats/
|
||||
[shortcode]: /content-management/shortcodes/
|
||||
@@ -0,0 +1,248 @@
|
||||
---
|
||||
title: Supported Content Formats
|
||||
linktitle: Supported Content Formats
|
||||
description: Markdown is natively supported in Hugo and is parsed by the feature-rich and incredibly speed Blackfriday parse. Hugo also provides support for additional syntaxes (eg, Asciidoc) via external helpers.
|
||||
date: 2017-01-10
|
||||
publishdate: 2017-01-10
|
||||
lastmod: 2017-04-06
|
||||
categories: [content management]
|
||||
tags: [markdown,asciidoc,mmark,content format]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 20
|
||||
weight: 20 #rem
|
||||
draft: false
|
||||
aliases: [/content/markdown-extras/,/content/supported-formats/,/doc/supported-formats/,/tutorials/mathjax/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Markdown
|
||||
|
||||
Markdown is the native content format for Hugo and is rendered using the excellent [Blackfriday project][blackfriday], a blazingly fast parser written in Golang.
|
||||
|
||||
{{% note "Deeply Nested Lists" %}}
|
||||
Before you begin writing your content in markdown, Blackfriday has a known issue [(#329)](https://github.com/russross/blackfriday/issues/329) with handling deeply nested lists. Luckily, there is an easy workaround. Use 4-spaces (i.e., <kbd>tab</kbd>) rather than 2-space indentations.
|
||||
{{% /note %}}
|
||||
|
||||
## Configuring BlackFriday Markdown Rendering
|
||||
|
||||
You can configure multiple aspects of Blackfriday as show in the following list. See the docs on [Configuration][config] for the full list of explicit directions you can give to Hugo when rendering your site.
|
||||
|
||||
{{< readfile file="/content/readfiles/bfconfig.md" markdown="true" >}}
|
||||
|
||||
## Extending Markdown
|
||||
|
||||
Hugo provides some convenient methods for extending markdown.
|
||||
|
||||
### Task Lists
|
||||
|
||||
Hugo supports [GitHub-styled task lists (i.e., TODO lists)][gfmtasks] for the Blackfriday markdown renderer. If you do not want to use this feature, you can disable it in your configuration.
|
||||
|
||||
#### Example Task List Input
|
||||
|
||||
{{% code file="content/my-to-do-list.md" %}}
|
||||
```markdown
|
||||
- [ ] a task list item
|
||||
- [ ] list syntax required
|
||||
- [ ] incomplete
|
||||
- [x] completed
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example Task List Output
|
||||
|
||||
The preceding markdown produces the following HTML in your rendered website:
|
||||
|
||||
```html
|
||||
<ul class="task-list">
|
||||
<li><input type="checkbox" disabled="" class="task-list-item"> a task list item</li>
|
||||
<li><input type="checkbox" disabled="" class="task-list-item"> list syntax required</li>
|
||||
<li><input type="checkbox" disabled="" class="task-list-item"> incomplete</li>
|
||||
<li><input type="checkbox" checked="" disabled="" class="task-list-item"> completed</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
#### Example Task List Display
|
||||
|
||||
The following shows how the example task list will look to the end users of your website. Note that visual styling of lists is up to you. This list has been styled according to [the Hugo Docs stylesheet][hugocss].
|
||||
|
||||
- [ ] a task list item
|
||||
- [ ] list syntax required
|
||||
- [ ] incomplete
|
||||
- [x] completed
|
||||
|
||||
### Emojis
|
||||
|
||||
Hugo comes with built-in support for emojis in your content, as well as ships with the [`emojify` function][]. To add emojis directly to content, set `enableEmoji` to `true` in your [site configuration][config].
|
||||
|
||||
For a full list of emojis, see the [Emoji cheat sheet][emojis].
|
||||
|
||||
### Shortcodes
|
||||
|
||||
If you write in Markdown and find yourself frequently embedding your content with raw HTML, Hugo provides built-in shortcodes functionality to act as the intermediary between your content and templating. This is one of the most powerful features in Hugo and allows you to essentially create your own Markdown extensions very quickly.
|
||||
|
||||
See [Shortcodes][sc] for usage, particularly for the built-in shortcodes that ship with Hugo, and [Shortcode Templating][sct] to learn how to build your own.
|
||||
|
||||
### Code Blocks
|
||||
|
||||
Hugo supports GitHub-flavored markdown's use of triple back ticks, as well as provides a special [`highlight` nested shortcode][hlsc] to render syntax highlighting via [Pygments][]. For usage examples and a complete explanation, see the [syntax highlighting documentation][hl] in [developer tools][].
|
||||
|
||||
## Mmark
|
||||
|
||||
Mmark is a [fork of BlackFriday][mmark] and markdown superset that is well suited for writing [IETF documentation][ietf]. You can see examples of the syntax in the [Mmark GitHub repository][mmarkgh] or the full syntax on [Miek Gieben's website][].
|
||||
|
||||
### Using Mmark
|
||||
|
||||
As Hugo ships with Mmark, using the syntax is as easy as changing the extension of your content files from `.md` to `.mmark`.
|
||||
|
||||
In the event that you want to only use Mmark in specific files, you can also define the Mmark syntax in your content's front matter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: My Post
|
||||
date: 2017-04-01
|
||||
markdown: mmark
|
||||
---
|
||||
```
|
||||
|
||||
{{% warning %}}
|
||||
Mmark support is still an *experimental* feature in Hugo. For example, shortcodes are not translated when used in an included `.mmark` file ([#3131](https://github.com/spf13/hugo/issues/3137)), and `EXTENSION_ABBREVIATION` ([#1970](https://github.com/spf13/hugo/issues/1970)) and the aforementioned GFM todo lists ([#2270](https://github.com/spf13/hugo/issues/2270)) are not fully supported. Contributions are welcome.
|
||||
{{% /warning %}}
|
||||
|
||||
## MathJax with Hugo
|
||||
|
||||
[MathJax](http://www.mathjax.org/) is a JavaScript library that allows the display of mathematical expressions described via a LaTeX-style syntax in the HTML (or Markdown) source of a web page. As it is a pure a JavaScript library, getting it to work within Hugo is fairly straightforward, but does have some oddities that will be discussed here.
|
||||
|
||||
This is not an introduction into actually using MathJax to render typeset mathematics on your website. Instead, this page is a collection of tips and hints for one way to get MathJax working on a website built with Hugo.
|
||||
|
||||
### Enabling MathJax
|
||||
|
||||
The first step is to enable MathJax on pages that you would like to have typeset math. There are multiple ways to do this (adventurous readers can consult the [Loading and Configuring](http://docs.mathjax.org/en/latest/configuration.html) section of the MathJax documentation for additional methods of including MathJax), but the easiest way is to use the secure MathJax CDN by include a `<script>` tag for the officially recommended secure CDN ([cdn.js.com](https://cdnjs.com)):
|
||||
|
||||
{{% code file="add-mathjax-to-page.html" %}}
|
||||
```html
|
||||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
|
||||
</script>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
One way to ensure that this code is included in all pages is to put it in one of the templates that live in the `layouts/partials/` directory. For example, I have included this in the bottom of my template `footer.html` because I know that the footer will be included in every page of my website.
|
||||
|
||||
### Options and Features
|
||||
|
||||
MathJax is a stable open-source library with many features. I encourage the interested reader to view the [MathJax Documentation](http://docs.mathjax.org/en/latest/index.html), specifically the sections on [Basic Usage](http://docs.mathjax.org/en/latest/index.html#basic-usage) and [MathJax Configuration Options](http://docs.mathjax.org/en/latest/index.html#mathjax-configuration-options).
|
||||
|
||||
### Issues with Markdown
|
||||
|
||||
{{% note %}}
|
||||
The following issues with Markdown assume you are using `.md` for content and BlackFriday for parsing. Using [Mmark](#mmark) as your content format will obviate the need for the following workarounds.
|
||||
|
||||
When using Mmark with MathJax, use `displayMath: [['$$','$$'], ['\\[','\\]']]`. See the [Mmark `README.md`](https://github.com/miekg/mmark/wiki/Syntax#math-blocks) for more information. In addition to MathJax, Mmark has been shown to work well with [KaTeX](https://github.com/Khan/KaTeX). See this [related blog post from a Hugo user](http://nosubstance.me/post/a-great-toolset-for-static-blogging/).
|
||||
{{% /note %}}
|
||||
|
||||
After enabling MathJax, any math entered between proper markers (see the [MathJax documentation][mathjaxdocs]) will be processed and typeset in the web page. One issue that comes up, however, with Markdown is that the underscore character (`_`) is interpreted by Markdown as a way to wrap text in `emph` blocks while LaTeX (MathJax) interprets the underscore as a way to create a subscript. This "double speak" of the underscore can result in some unexpected and unwanted behavior.
|
||||
|
||||
### Solution
|
||||
|
||||
There are multiple ways to remedy this problem. One solution is to simply escape each underscore in your math code by entering `\_` instead of `_`. This can become quite tedious if the equations you are entering are full of subscripts.
|
||||
|
||||
Another option is to tell Markdown to treat the MathJax code as verbatim code and not process it. One way to do this is to wrap the math expression inside a `<div>` `</div>` block. Markdown would ignore these sections and they would get passed directly on to MathJax and processed correctly. This works great for display style mathematics, but for inline math expressions the line break induced by the `<div>` is not acceptable. The syntax for instructing Markdown to treat inline text as verbatim is by wrapping it in backticks (`` ` ``). You might have noticed, however, that the text included in between backticks is rendered differently than standard text (on this site these are items highlighted in red). To get around this problem, we could create a new CSS entry that would apply standard styling to all inline verbatim text that includes MathJax code. Below I will show the HTML and CSS source that would accomplish this (note this solution was adapted from [this blog post](http://doswa.com/2011/07/20/mathjax-in-markdown.html)---all credit goes to the original author).
|
||||
|
||||
{{% code file="mathjax-markdown-solution.html" %}}
|
||||
```js
|
||||
<script type="text/x-mathjax-config">
|
||||
MathJax.Hub.Config({
|
||||
tex2jax: {
|
||||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||||
displayMath: [['$$','$$'], ['\[','\]']],
|
||||
processEscapes: true,
|
||||
processEnvironments: true,
|
||||
skipTags: ['script', 'noscript', 'style', 'textarea', 'pre'],
|
||||
TeX: { equationNumbers: { autoNumber: "AMS" },
|
||||
extensions: ["AMSmath.js", "AMSsymbols.js"] }
|
||||
}
|
||||
});
|
||||
</script>
|
||||
|
||||
<script type="text/x-mathjax-config">
|
||||
MathJax.Hub.Queue(function() {
|
||||
// Fix <code> tags after MathJax finishes running. This is a
|
||||
// hack to overcome a shortcoming of Markdown. Discussion at
|
||||
// https://github.com/mojombo/jekyll/issues/199
|
||||
var all = MathJax.Hub.getAllJax(), i;
|
||||
for(i = 0; i < all.length; i += 1) {
|
||||
all[i].SourceElement().parentNode.className += ' has-jax';
|
||||
}
|
||||
});
|
||||
</script>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
|
||||
|
||||
As before, this content should be included in the HTML source of each page that will be using MathJax. The next code snippet contains the CSS that is used to have verbatim MathJax blocks render with the same font style as the body of the page.
|
||||
|
||||
{{% code file="mathjax-style.css" %}}
|
||||
```css
|
||||
code.has-jax {
|
||||
font: inherit;
|
||||
font-size: 100%;
|
||||
background: inherit;
|
||||
border: inherit;
|
||||
color: #515151;
|
||||
}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
In the CSS snippet, notice the line `color: #515151;`. `#515151` is the value assigned to the `color` attribute of the `body` class in my CSS. In order for the equations to fit in with the body of a web page, this value should be the same as the color of the body.
|
||||
|
||||
### Usage
|
||||
|
||||
With this setup, everything is in place for a natural usage of MathJax on pages generated using Hugo. In order to include inline mathematics, just put LaTeX code in between `` `$ TeX Code $` `` or `` `\( TeX Code \)` ``. To include display style mathematics, just put LaTeX code in between `<div>$$TeX Code$$</div>`. All the math will be properly typeset and displayed within your Hugo generated web page!
|
||||
|
||||
## Additional Formats Through External Helpers
|
||||
|
||||
Since 0.14, Hugo has defined a new concept called _external helpers_. It means that you can write your content using [Asciidoc][ascii], [reStructuredText][rest], or Emacs org-mode. If you have files with associated extensions, Hugo will call external commands to generate the content. ([See the Hugo source code for external helpers][helperssource].)
|
||||
|
||||
For example, for Asciidoc files, Hugo will try to call the `asciidoctor` or `asciidoc` command. This means that you will have to install the associated tool on your machine to be able to use these formats. ([See the Asciidoctor docs for installation instructions](http://asciidoctor.org/docs/install-toolchain/)).
|
||||
|
||||
To use these formats, just use the standard extension and the front matter exactly as you would do with natively supported `.md` files.
|
||||
|
||||
{{% warning "Performance of External Helpers" %}}
|
||||
Because additional formats are external commands---with the exception of Org-mode---generation performance will rely heavily on the performance of the external tool you are using. As this feature is still in its infancy, feedback is welcome.
|
||||
{{% /warning %}}
|
||||
|
||||
## Learn Markdown
|
||||
|
||||
Markdown syntax is simple enough to learn in a single sitting. The following are excellent resources to get you up and running:
|
||||
|
||||
* [Daring Fireball: Markdown, John Gruber (Creator of Markdown)][fireball]
|
||||
* [Markdown Cheatsheet, Adam Pritchard][mdcheatsheet]
|
||||
* [Markdown Tutorial (Interactive), Garen Torikian][mdtutorial]
|
||||
|
||||
[`emojify` function]: /functions/emojify/
|
||||
[ascii]: http://asciidoc.org/
|
||||
[bfconfig]: /getting-started/configuration/#configuring-blackfriday-rendering
|
||||
[blackfriday]: https://github.com/russross/blackfriday
|
||||
[config]: /getting-started/configuration/
|
||||
[developer tools]: /tools/
|
||||
[emojis]: https://www.webpagefx.com/tools/emoji-cheat-sheet/
|
||||
[fireball]: https://daringfireball.net/projects/markdown/
|
||||
[gfmtasks]: https://guides.github.com/features/mastering-markdown/#syntax
|
||||
[helperssource]: https://github.com/spf13/hugo/blob/77c60a3440806067109347d04eb5368b65ea0fe8/helpers/general.go#L65
|
||||
[hl]: /tools/syntax-highlighting/
|
||||
[hlsc]: /content-management/shortcodes/#highlight
|
||||
[hugocss]: /css/style.min.css
|
||||
[ietf]: https://tools.ietf.org/html/
|
||||
[mathjaxdocs]: https://docs.mathjax.org/en/latest/
|
||||
[mdcheatsheet]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
|
||||
[mdtutorial]: http://www.markdowntutorial.com/
|
||||
[Miek Gieben's website]: https://miek.nl/2016/March/05/mmark-syntax-document/
|
||||
[mmark]: https://github.com/miekg/mmark
|
||||
[mmarkgh]: https://github.com/miekg/mmark/wiki/Syntax
|
||||
[org]: http://orgmode.org/
|
||||
[Pygments]: http://pygments.org/
|
||||
[rest]: http://docutils.sourceforge.net/rst.html
|
||||
[sc]: /content-management/shortcodes/
|
||||
[sct]: /templates/shortcode-templates/
|
||||
@@ -0,0 +1,201 @@
|
||||
---
|
||||
title: Front Matter
|
||||
linktitle:
|
||||
description: Hugo allows you to add front matter in yaml, toml, or json to your content files.
|
||||
date: 2017-01-09
|
||||
publishdate: 2017-01-09
|
||||
lastmod: 2017-02-24
|
||||
categories: [content management]
|
||||
tags: ["front matter", "yaml", "toml", "json", "metadata", "archetypes"]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 30
|
||||
weight: 30 #rem
|
||||
draft: false
|
||||
aliases: [/content/front-matter/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
**Front matter** allows you to keep metadata attached to an instance of a [content type][]---i.e., embedded inside a content file---and is one of the many features that gives Hugo its strength.
|
||||
|
||||
## Front Matter Formats
|
||||
|
||||
Hugo supports three formats for front matter, each with their own identifying tokens.
|
||||
|
||||
TOML
|
||||
: identified by opening and closing `+++`.
|
||||
|
||||
YAML
|
||||
: identified by opening and closing `---` *or* opening `---` and closing `...`
|
||||
|
||||
JSON
|
||||
: a single JSON object surrounded by '`{`' and '`}`', followed by a new line.
|
||||
|
||||
### TOML Example
|
||||
|
||||
```toml
|
||||
+++
|
||||
title = "spf13-vim 3.0 release and new website"
|
||||
description = "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
|
||||
tags = [ ".vimrc", "plugins", "spf13-vim", "vim" ]
|
||||
date = "2012-04-06"
|
||||
categories = [
|
||||
"Development",
|
||||
"VIM"
|
||||
]
|
||||
slug = "spf13-vim-3-0-release-and-new-website"
|
||||
+++
|
||||
```
|
||||
|
||||
### YAML Example
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: "spf13-vim 3.0 release and new website"
|
||||
description: "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
|
||||
tags: [ ".vimrc", "plugins", "spf13-vim", "vim" ]
|
||||
lastmod: 2015-12-23
|
||||
date: "2012-04-06"
|
||||
categories:
|
||||
- "Development"
|
||||
- "VIM"
|
||||
slug: "spf13-vim-3-0-release-and-new-website"
|
||||
---
|
||||
```
|
||||
|
||||
### JSON Example
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "spf13-vim 3.0 release and new website",
|
||||
"description": "spf13-vim is a cross platform distribution of vim plugins and resources for Vim.",
|
||||
"tags": [ ".vimrc", "plugins", "spf13-vim", "vim" ],
|
||||
"date": "2012-04-06",
|
||||
"categories": [
|
||||
"Development",
|
||||
"VIM"
|
||||
],
|
||||
"slug": "spf13-vim-3-0-release-and-new-website"
|
||||
}
|
||||
```
|
||||
|
||||
## Front Matter Variables
|
||||
|
||||
### Predefined
|
||||
|
||||
There are a few predefined variables that Hugo is aware of. See [Page Variables][pagevars] for how to call many of these predefined variables in your templates.
|
||||
|
||||
`aliases`
|
||||
: an array of one or more aliases (e.g., old published paths of renamed content) that will be created in the output directory structure . See [Aliases][aliases] for details.
|
||||
|
||||
`date`
|
||||
: the datetime at which the content was created; note this value is auto-populated according to Hugo's built-in [archetype][].
|
||||
|
||||
`description`
|
||||
: the description for the content.
|
||||
|
||||
`draft`
|
||||
: if `true`, the content will not be rendered unless the `--buildDrafts` flag is passed to the `hugo` command.
|
||||
|
||||
`expirydate`
|
||||
: the datetime at which the content should no longer be published by Hugo; expired content will not be rendered unless the `--buildExpired` flag is passed to the `hugo` command.
|
||||
|
||||
`isCJKLanguage`
|
||||
: if `true`, Hugo will explicitly treat the content as a CJK language; both `.Summary` and `.WordCount` work properly in CJK languages.
|
||||
|
||||
`keywords`
|
||||
: the meta keywords for the content.
|
||||
|
||||
`layout`
|
||||
: the layout Hugo should select from the [lookup order][lookup] when rendering the content. If a `type` is not specified in the front matter, Hugo will look for the layout of the same name in the layout directory that corresponds with a content's section. See ["Defining a Content Type"][definetype]
|
||||
|
||||
`lastmod`
|
||||
: the datetime at which the content was last modified.
|
||||
|
||||
`linktitle`
|
||||
: used for creating links to content; if set, Hugo defaults to using the `linktitle` before the `title`. Hugo can also [order lists of content by `linktitle`][bylinktitle].
|
||||
|
||||
`markup`
|
||||
: **experimental**; specify `"rst"` for reStructuredText (requires`rst2html`) or `"md"` (default) for Markdown.
|
||||
|
||||
`outputs`
|
||||
: allows you to specify output formats specific to the content. See [output formats][outputs].
|
||||
|
||||
`publishdate`
|
||||
: if in the future, content will not be rendered unless the `--buildFuture` flag is passed to `hugo`.
|
||||
|
||||
`slug`
|
||||
: appears as the tail of the output URL. A value specified in front matter will override the segment of the URL based on the filename.
|
||||
|
||||
`taxonomies`
|
||||
: these will use the field name of the plural form of the index; see the `tags` and `categories` in the above front matter examples.
|
||||
|
||||
`title`
|
||||
: the title for the content.
|
||||
|
||||
`type`
|
||||
: the type of the content; this value will be automatically derived from the directory (i.e., the [section][]) if not specified in front matter.
|
||||
|
||||
`url`
|
||||
: the full path to the content from the web root. It makes no assumptions about the path of the content file. It also ignores any language prefixes of
|
||||
the multilingual feature.
|
||||
|
||||
`weight`
|
||||
: used for [ordering your content in lists][ordering].
|
||||
|
||||
{{% note "Hugo's Default URL Destinations" %}}
|
||||
If neither `slug` nor `url` is present and [permalinks are not configured otherwise in your site `config` file](/content-management/urls/#permalinks), Hugo will use the filename of your content to create the output URL. See [Content Organization](/content-management/organization) for an explanation of paths in Hugo and [URL Management](/content-management/urls/) for ways to customize Hugo's default behaviors.
|
||||
{{% /note %}}
|
||||
|
||||
### User-Defined
|
||||
|
||||
You can add fields to your front matter arbitrarily to meet your needs. These user-defined key-values are placed into a single `.Params` variable for use in your templates.
|
||||
|
||||
The following fields can be accessed via `.Params.include_toc` and `.Params.show_comments`, respectively. The [Variables][] section provides more information on using Hugo's page- and site-level variables in your templates.
|
||||
|
||||
```yaml
|
||||
include_toc: true
|
||||
show_comments: false
|
||||
```
|
||||
|
||||
These two user-defined fields can then be accessed via `.Params.include_toc` and `.Params.show_comments`, respectively. The [Variables][variables] section provides more information on using Hugo's page- and site-level variables in your templates.
|
||||
|
||||
{{% note %}}
|
||||
Field names are always normalized to lowercase; e.g., `camelCase: true` is available as `.Params.camelcase`.
|
||||
{{% /note %}}
|
||||
|
||||
## Ordering Content Through Front Matter
|
||||
|
||||
You can assign content-specific `weight` in the front matter of your content. These values are especially useful for [ordering][ordering] in list views. You can use `weight` for ordering of content and the convention of [`<TAXONOMY>_weight`][taxweight] for ordering content within a taxonomy. See [Ordering and Grouping Hugo Lists][lists] to see how `weight` can be used to organize your content in list views.
|
||||
|
||||
## Overriding Global Blackfriday Configuration
|
||||
|
||||
It's possible to set some options for Markdown rendering in a content's front matter as an override to the [BlackFriday rendering options set in your project configuration][config].
|
||||
|
||||
## Front Matter Format Specs
|
||||
|
||||
* [TOML Spec][toml]
|
||||
* [YAML Spec][yaml]
|
||||
* [JSON Spec][json]
|
||||
|
||||
[variables]: /variables/
|
||||
[aliases]: /content-management/urls/#aliases/
|
||||
[archetype]: /content-management/archetypes/
|
||||
[bylinktitle]: /templates/lists/#by-link-title
|
||||
[config]: /getting-started/configuration/ "Hugo documentation for site configuration"
|
||||
[content type]: /content-management/types/
|
||||
[contentorg]: /content-management/organization/
|
||||
[definetype]: /content-management/types/#defining-a-content-type "Learn how to specify a type and a layout in a content's front matter"
|
||||
[json]: /documents/ecma-404-json-spec.pdf "Specification for JSON, JavaScript Object Notation"
|
||||
[lists]: /templates/lists/#ordering-content "See how to order content in list pages; for example, templates that look to specific _index.md for content and front matter."
|
||||
[lookup]: /templates/lookup-order/ "Hugo traverses your templates in a specific order when rendering content to allow for DRYer templating."
|
||||
[ordering]: /templates/lists/ "Hugo provides multiple ways to sort and order your content in list templates"
|
||||
[outputs]: /templates/output-formats/ "With the release of v22, you can output your content to any text format using Hugo's familiar templating"
|
||||
[pagevars]: /variables/page/
|
||||
[section]: /content-management/sections/
|
||||
[taxweight]: /content-management/taxonomies/
|
||||
[toml]: https://github.com/toml-lang/toml "Specification for TOML, Tom's Obvious Minimal Language"
|
||||
[urls]: /content-management/urls/
|
||||
[variables]: /variables/
|
||||
[yaml]: http://yaml.org/spec/ "Specification for YAML, YAML Ain't Markup Language"
|
||||
@@ -0,0 +1,186 @@
|
||||
---
|
||||
title: Menus
|
||||
linktitle: Menus
|
||||
description: Hugo's simple yet powerful menu system allows you to add content to menus with a high level of control and low level of effort.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-03-31
|
||||
categories: [content management]
|
||||
tags: [menus]
|
||||
draft: false
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 120
|
||||
weight: 120 #rem
|
||||
aliases: [/extras/menus/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo's simple yet powerful menu system allows you to add content to menus with a high degree of control and a very low amount of effort on the part of content authors.
|
||||
|
||||
{{% note "Lazy Blogger"%}}
|
||||
If all you want is a simple menu for your sections, see the ["Section Menu for Lazy Bloggers" in Menu Templates](/templates/menu-templates/#section-menu-for-lazy-blogger).
|
||||
{{% /note %}}
|
||||
|
||||
Hugo's robust menu features allow you to do the following:
|
||||
|
||||
* Place content in one or many menus
|
||||
* Handle nested menus with unlimited depth
|
||||
* Create menu entries without being attached to any content
|
||||
* Distinguish active element (and active branch)
|
||||
|
||||
## What is a Menu in Hugo?
|
||||
|
||||
A **menu** is a named array of menu entries accessible by name via the [`.Site.Menus` site variable][sitevars]. For example, you can access your site's `main` menu via `.Site.Menus.main`.
|
||||
|
||||
{{% note "Menus on Multilingual Sites" %}}
|
||||
If you make use of the [multilingual feature](/content-management/multilingual/), you can define language-independent menus.
|
||||
{{% /note %}}
|
||||
|
||||
A menu entry has the following properties (i.e., variables) available to it:
|
||||
|
||||
`.URL`
|
||||
: string
|
||||
|
||||
`.Name`
|
||||
: string
|
||||
|
||||
`.Menu`
|
||||
: string
|
||||
|
||||
`.Identifier`
|
||||
: string
|
||||
|
||||
`.Pre`
|
||||
: template.HTML
|
||||
|
||||
`.Post`
|
||||
: template.HTML
|
||||
|
||||
`.Weight`
|
||||
: int
|
||||
|
||||
`.Parent`
|
||||
: string
|
||||
|
||||
`.Children`
|
||||
: Menu
|
||||
|
||||
Note that menus also have the following functions available as well:
|
||||
|
||||
`.HasChildren`
|
||||
: boolean
|
||||
|
||||
Additionally, there are some relevant functions available to menus on a page:
|
||||
|
||||
`.IsMenuCurrent`
|
||||
: (menu string, menuEntry *MenuEntry ) boolean
|
||||
|
||||
`.HasMenuCurrent`
|
||||
: (menu string, menuEntry *MenuEntry) boolean
|
||||
|
||||
## Adding content to menus
|
||||
|
||||
Hugo allows you to add content to a menu via the content's [front matter](/content-management/front-matter/).
|
||||
|
||||
### Simple
|
||||
|
||||
If all you need to do is add an entry to a menu, the simple form works well.
|
||||
|
||||
#### A Single Menu
|
||||
|
||||
```yaml
|
||||
---
|
||||
menu: "main"
|
||||
---
|
||||
```
|
||||
|
||||
#### Multiple Menus
|
||||
|
||||
```yaml
|
||||
---
|
||||
menu: ["main", "footer"]
|
||||
---
|
||||
```
|
||||
|
||||
### Advanced
|
||||
|
||||
Take the advanced approach if more control is required. All of the menu entry properties listed above are available.
|
||||
|
||||
```yaml
|
||||
---
|
||||
menu:
|
||||
docs:
|
||||
parent: 'extras'
|
||||
weight: 20
|
||||
---
|
||||
```
|
||||
|
||||
## Adding Non-content Entries to a Menu
|
||||
|
||||
You can also add entries to menus that aren’t attached to a piece of content. This takes place in your Hugo project's [`config` file][config].
|
||||
|
||||
Here’s an example snippet pulled from a `config.toml`:
|
||||
|
||||
{{% code file="config.toml" %}}
|
||||
```toml
|
||||
[[menu.main]]
|
||||
name = "about hugo"
|
||||
pre = "<i class='fa fa-heart'></i>"
|
||||
weight = -110
|
||||
identifier = "about"
|
||||
url = "/about/"
|
||||
[[menu.main]]
|
||||
name = "getting started"
|
||||
pre = "<i class='fa fa-road'></i>"
|
||||
weight = -100
|
||||
url = "/getting-started/"
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Here's the equivalent snippet in a `config.yaml`:
|
||||
|
||||
{{% code file="config.yml" %}}
|
||||
```yaml
|
||||
---
|
||||
menu:
|
||||
docs:
|
||||
- Name: "about hugo"
|
||||
Pre: "<i class='fa fa-heart'></i>"
|
||||
Weight: -110
|
||||
Identifier: "about"
|
||||
URL: "/about/"
|
||||
- Name: "getting started"
|
||||
Pre: "<i class='fa fa-road'></i>"
|
||||
Weight: -100
|
||||
URL: "/getting-started/"
|
||||
---
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% note %}}
|
||||
The URLs must be relative to the context root. If the `baseURL` is `http://example.com/mysite/`, then the URLs in the menu must not include the context root `mysite`. Using an absolute URL will overide the baseURL. If the value used for `URL` in the above example is `http://subdomain.example.com/`, the output will be `http://subdomain.example.com`.
|
||||
{{% /note %}}
|
||||
|
||||
## Nesting
|
||||
|
||||
All nesting of content is done via the `parent` field.
|
||||
|
||||
The parent of an entry should be the identifier of another entry. The identifier should be unique (within a menu).
|
||||
|
||||
The following order is used to determine an Identifier:
|
||||
|
||||
`.Name > .LinkTitle > .Title`
|
||||
|
||||
This means that `.Title` will be used unless `.LinkTitle` is present, etc. In practice, `.Name` and `.Identifier` are only used to structure relationships and therefore never displayed.
|
||||
|
||||
In this example, the top level of the menu is defined in your [site `config` file][config]). All content entries are attached to one of these entries via the `.Parent` field.
|
||||
|
||||
## Rendering Menus
|
||||
|
||||
See [Menu Templates](/templates/menu-templates/) for information on how to render your site menus within your templates.
|
||||
|
||||
[config]: /getting-started/configuration/
|
||||
[multilingual]: /content-management/multilingual/
|
||||
[sitevars]: /variables/
|
||||
@@ -0,0 +1,294 @@
|
||||
---
|
||||
title: Multilingual Mode
|
||||
linktitle: Multilingual and i18n
|
||||
description: As of v0.17, Hugo supports the creation of websites with multiple languages side by side.
|
||||
date: 2017-01-10
|
||||
publishdate: 2017-01-10
|
||||
lastmod: 2017-01-10
|
||||
categories: [content management]
|
||||
tags: [multilingual,i18n, internationalization]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 150
|
||||
weight: 150 #rem
|
||||
draft: false
|
||||
aliases: [/content/multilingual/,/content-management/multilingual/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo supports multiple languages side-by-side (added in `Hugo 0.17`). You should Define the available languages in a `Languages` section in your site configuration.
|
||||
|
||||
## Configuring Multilingual Mode
|
||||
|
||||
The following is an example of a TOML site configuration for a multilingual Hugo project:
|
||||
|
||||
{{% code file="config.toml" download="config.toml" %}}
|
||||
```toml
|
||||
DefaultContentLanguage = "en"
|
||||
copyright = "Everything is mine"
|
||||
|
||||
[params.navigation]
|
||||
help = "Help"
|
||||
|
||||
[Languages]
|
||||
[Languages.en]
|
||||
title = "My blog"
|
||||
weight = 1
|
||||
[Languages.en.params]
|
||||
linkedin = "english-link"
|
||||
|
||||
[Languages.fr]
|
||||
copyright = "Tout est à moi"
|
||||
title = "Mon blog"
|
||||
weight = 2
|
||||
[Languages.fr.params]
|
||||
linkedin = "lien-francais"
|
||||
[Languages.fr.navigation]
|
||||
help = "Aide"
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Anything not defined in a `[Languages]` block will fall back to the global
|
||||
value for that key (e.g., `copyright` for the English [`en`] language).
|
||||
|
||||
With the configuration above, all content, sitemap, RSS feeds, paginations,
|
||||
and taxonomy pages will be rendered below `/` in English (your default content language) and then below `/fr` in French.
|
||||
|
||||
When working with front matter `Params` in [single page templates][singles], omit the `params` in the key for the translation.
|
||||
|
||||
If you want all of the languages to be put below their respective language code, enable `defaultContentLanguageInSubdir: true`.
|
||||
|
||||
Only the obvious non-global options can be overridden per language. Examples of global options are `BaseURL`, `BuildDrafts`, etc.
|
||||
|
||||
## Taxonomies and Blackfriday
|
||||
|
||||
Taxonomies and [Blackfriday configuration][config] can also be set per language:
|
||||
|
||||
|
||||
{{% code file="bf-config.toml" %}}
|
||||
```toml
|
||||
[Taxonomies]
|
||||
tag = "tags"
|
||||
|
||||
[blackfriday]
|
||||
angledQuotes = true
|
||||
hrefTargetBlank = true
|
||||
|
||||
[Languages]
|
||||
[Languages.en]
|
||||
weight = 1
|
||||
title = "English"
|
||||
[Languages.en.blackfriday]
|
||||
angledQuotes = false
|
||||
|
||||
[Languages.fr]
|
||||
weight = 2
|
||||
title = "Français"
|
||||
[Languages.fr.Taxonomies]
|
||||
plaque = "plaques"
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
## Translating Your Content
|
||||
|
||||
Translated articles are identified by the name of the content file.
|
||||
|
||||
### Examples of Translated Articles
|
||||
|
||||
1. `/content/about.en.md`
|
||||
2. `/content/about.fr.md`
|
||||
|
||||
You can also have the following, in which case the config variable `defaultContentLanguage` will be used to affect the default language `about.md`. This way, you can slowly start to translate your current content without having to rename everything:
|
||||
|
||||
1. `/content/about.md`
|
||||
2. `/content/about.fr.md`
|
||||
|
||||
If left unspecified, the default value for `defaultContentLanguage` is `en`.
|
||||
|
||||
By having the same *base filename*, the content pieces are linked together as translated pieces.
|
||||
|
||||
If you need distinct URLs per language, you can set the slug in the non-default language file. For example, you can define a custom slug for a French translation in the front matter of `content/about.fr.md` as follows:
|
||||
|
||||
```yaml
|
||||
slug: "a-propos"
|
||||
|
||||
```
|
||||
|
||||
At render, Hugo will build both `/about/` and `/a-propos/` as properly linked translated pages.
|
||||
|
||||
## Link to Translated Content
|
||||
|
||||
To create a list of links to translated content, use a template similar to the following:
|
||||
|
||||
{{% code file="layouts/partials/i18nlist.html" %}}
|
||||
```html
|
||||
{{ if .IsTranslated }}
|
||||
<h4>{{ i18n "translations" }}</h4>
|
||||
<ul>
|
||||
{{ range .Translations }}
|
||||
<li>
|
||||
<a href="{{ .Permalink }}">{{ .Lang }}: {{ .Title }}{{ if .IsPage }} ({{ i18n "wordCount" . }}){{ end }}</a>
|
||||
</li>
|
||||
{{ end}}
|
||||
</ul>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
The above can be put in a `partial` (i.e., inside `layouts/partials/`) and included in any template, be it for a [single content page][contenttemplate] or the [homepage][]. It will not print anything if there are no translations for a given page, or if there are translations---in the case of the homepage, section listing, etc.---a site with only render one language.
|
||||
|
||||
The above also uses the [`i18n` function][i18func] described in the next section.
|
||||
|
||||
## Translation of Strings
|
||||
|
||||
Hugo uses [go-i18n][] to support string translations. [See the project's source repository][go-i18n-source] to find tools that will help you manage your translation workflows.
|
||||
|
||||
Translations are collected from the `themes/<THEME>/i18n/` folder (built into the theme), as well as translations present in `i18n/` at the root of your project. In the `i18n`, the translations will be merged and take precedence over what is in the theme folder. Language files should be named according to [RFC 5646][] with names such as `en-US.toml`, `fr.toml`, etc.
|
||||
|
||||
From within your templates, use the `i18n` function like this:
|
||||
|
||||
```
|
||||
{{ i18n "home" }}
|
||||
```
|
||||
|
||||
This uses a definition like this one in `i18n/en-US.toml`:
|
||||
|
||||
```
|
||||
[home]
|
||||
other = "Home"
|
||||
```
|
||||
|
||||
Often you will want to use to the page variables in the translations strings. To do that, pass on the "." context when calling `i18n`:
|
||||
|
||||
```
|
||||
{{ i18n "wordCount" . }}
|
||||
```
|
||||
|
||||
This uses a definition like this one in `i18n/en-US.toml`:
|
||||
|
||||
```
|
||||
[wordCount]
|
||||
other = "This article has {{ .WordCount }} words."
|
||||
```
|
||||
An example of singular and plural form:
|
||||
|
||||
```
|
||||
[readingTime]
|
||||
one = "One minute read"
|
||||
other = "{{.Count}} minutes read"
|
||||
```
|
||||
And then in the template:
|
||||
|
||||
```
|
||||
{{ i18n "readingTime" .ReadingTime }}
|
||||
```
|
||||
To track down missing translation strings, run Hugo with the `--i18n-warnings` flag:
|
||||
|
||||
```bash
|
||||
hugo --i18n-warnings | grep i18n
|
||||
i18n|MISSING_TRANSLATION|en|wordCount
|
||||
```
|
||||
|
||||
## Customize Dates
|
||||
|
||||
At the time of this writing, Golang does not yet have support for internationalized locales, but if you do some work, you can simulate it. For example, if you want to use French month names, you can add a data file like ``data/mois.yaml`` with this content:
|
||||
|
||||
~~~yaml
|
||||
1: "janvier"
|
||||
2: "février"
|
||||
3: "mars"
|
||||
4: "avril"
|
||||
5: "mai"
|
||||
6: "juin"
|
||||
7: "juillet"
|
||||
8: "août"
|
||||
9: "septembre"
|
||||
10: "octobre"
|
||||
11: "novembre"
|
||||
12: "décembre"
|
||||
~~~
|
||||
|
||||
... then index the non-English date names in your templates like so:
|
||||
|
||||
~~~html
|
||||
<time class="post-date" datetime="{{ .Date.Format "2006-01-02T15:04:05Z07:00" | safeHTML }}">
|
||||
Article publié le {{ .Date.Day }} {{ index $.Site.Data.mois (printf "%d" .Date.Month) }} {{ .Date.Year }} (dernière modification le {{ .Lastmod.Day }} {{ index $.Site.Data.mois (printf "%d" .Lastmod.Month) }} {{ .Lastmod.Year }})
|
||||
</time>
|
||||
~~~
|
||||
|
||||
This technique extracts the day, month and year by specifying ``.Date.Day``, ``.Date.Month``, and ``.Date.Year``, and uses the month number as a key, when indexing the month name data file.
|
||||
|
||||
## Menus
|
||||
|
||||
You can define your menus for each language independently. The [creation of a menu][menus] works analogous to earlier versions of Hugo, except that they have to be defined in their language-specific block in the configuration file:
|
||||
|
||||
```toml
|
||||
defaultContentLanguage = "en"
|
||||
|
||||
[languages.en]
|
||||
weight = 0
|
||||
languageName = "English"
|
||||
|
||||
[[languages.en.menu.main]]
|
||||
url = "/"
|
||||
name = "Home"
|
||||
weight = 0
|
||||
|
||||
|
||||
[languages.de]
|
||||
weight = 10
|
||||
languageName = "Deutsch"
|
||||
|
||||
[[languages.de.menu.main]]
|
||||
url = "/"
|
||||
name = "Startseite"
|
||||
weight = 0
|
||||
```
|
||||
|
||||
The rendering of the main navigation works as usual. `.Site.Menus` will just contain the menu of the current language. Pay attention to the generation of the menu links. `absLangURL` takes care that you link to the correct locale of your website. Otherwise, both menu entries would link to the English version as the default content language that resides in the root directory.
|
||||
|
||||
```html
|
||||
<ul>
|
||||
{{- $currentPage := . -}}
|
||||
{{ range .Site.Menus.main -}}
|
||||
<li class="{{ if $currentPage.IsMenuCurrent "main" . }}active{{ end }}">
|
||||
<a href="{{ .URL | absLangURL }}">{{ .Name }}</a>
|
||||
</li>
|
||||
{{- end }}
|
||||
</ul>
|
||||
|
||||
```
|
||||
|
||||
## Missing translations
|
||||
|
||||
If a string does not have a translation for the current language, Hugo will use the value from the default language. If no default value is set, an empty string will be shown.
|
||||
|
||||
While translating a Hugo website, it can be handy to have a visual indicator of missing translations. The [`EnableMissingTranslationPlaceholders` configuration option][config] will flag all untranslated strings with the placeholder `[i18n] identifier`, where `identifier` is the id of the missing translation.
|
||||
|
||||
{{% note %}}
|
||||
Hugo will generate your website with these missing translation placeholders. It might not be suited for production environments.
|
||||
{{% /note %}}
|
||||
|
||||
## Multilingual Themes support
|
||||
|
||||
To support Multilingual mode in your themes, some considerations must be taken for the URLs in the templates. If there is more than one language, URLs must meet the following criteria:
|
||||
|
||||
* Come from the built-in `.Permalink` or `.URL`
|
||||
* Be constructed with
|
||||
* The [`relLangURL` template function][rellangurl] or the [`absLangURL` template function][abslangurl] **OR**
|
||||
* Prefixed with `{{ .LanguagePrefix }}`
|
||||
|
||||
If there is more than one language defined, the `LanguagePrefix` variable will equal `/en` (or whatever your `CurrentLanguage` is). If not enabled, it will be an empty string and is therefore harmless for single-language Hugo websites.
|
||||
|
||||
[abslangurl]: /functions/abslangurl
|
||||
[config]: /getting-started/configuration/
|
||||
[contenttemplate]: /templates/single-page-templates/
|
||||
[go-i18n-source]: https://github.com/nicksnyder/go-i18n
|
||||
[go-i18n]: https://github.com/nicksnyder/go-i18n
|
||||
[homepage]: /templates/homepage/
|
||||
[i18func]: /functions/i18n/
|
||||
[menus]: /content-management/menus/
|
||||
[rellangurl]: /functions/rellangurl
|
||||
[RFC 5646]: https://tools.ietf.org/html/rfc5646
|
||||
[singles]: /templates/single-page-templates/
|
||||
@@ -0,0 +1,240 @@
|
||||
---
|
||||
title: Content Organization
|
||||
linktitle: Organization
|
||||
description: Hugo assumes that the same structure that works to organize your source content is used to organize the rendered site.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [content management]
|
||||
tags: [sections,content,organization,fundamentals]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 10
|
||||
weight: 10 #rem
|
||||
draft: false
|
||||
aliases: [/content/sections/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Organization of Content Source
|
||||
|
||||
In Hugo, your content should be organized in a manner that reflects the rendered website.
|
||||
|
||||
While Hugo supports content nested at any level, the top levels (i.e. `content/<DIRECTORIES>`) are special in Hugo and are considered the content [sections][]. Without any additional configuration, the following will just work:
|
||||
|
||||
```
|
||||
.
|
||||
└── content
|
||||
└── about
|
||||
| └── _index.md // <- http://yoursite.com/about/
|
||||
├── post
|
||||
| ├── firstpost.md // <- http://yoursite.com/post/firstpost/
|
||||
| ├── happy
|
||||
| | └── ness.md // <- http://yoursite.com/post/happy/ness/
|
||||
| └── secondpost.md // <- http://yoursite.com/post/secondpost/
|
||||
└── quote
|
||||
├── first.md // <- http://yoursite.com/quote/first/
|
||||
└── second.md // <- http://yoursite.com/quote/second/
|
||||
```
|
||||
|
||||
## Path Breakdown in Hugo
|
||||
|
||||
The following demonstrates the relationships between your content organization and the output URL structure for your Hugo website when it renders. These examples assume you are [using pretty URLs][pretty], which is the default behavior for Hugo. The examples also assume a key-value of `baseurl = "http://yoursite.com"` in your [site's configuration file][config].
|
||||
|
||||
### Index Pages: `_index.md`
|
||||
|
||||
`_index.md` has a special role in Hugo. It allows you to add front matter and content to your [list templates][lists] as of v0.18. These templates include those for [section templates][], [taxonomy templates][], [taxonomy terms templates][], and your [homepage template][]. In your templates, you can grab information from `_index.md` using the [`.Site.GetPage` function][getpage].
|
||||
|
||||
You can keep one `_index.md` for your homepage and one in each of your content sections, taxonomies, and taxonomy terms. The following shows typical placement of an `_index.md` that would contain content and front matter for a `posts` section list page on a Hugo website:
|
||||
|
||||
|
||||
```bash
|
||||
. url
|
||||
. ⊢--^-⊣
|
||||
. path slug
|
||||
. ⊢--^-⊣⊢---^---⊣
|
||||
. filepath
|
||||
. ⊢------^------⊣
|
||||
content/posts/_index.md
|
||||
```
|
||||
|
||||
At build, this will output to the following destination with the associated values:
|
||||
|
||||
```bash
|
||||
|
||||
url ("/posts/")
|
||||
⊢-^-⊣
|
||||
baseurl section ("posts")
|
||||
⊢--------^---------⊣⊢-^-⊣
|
||||
permalink
|
||||
⊢----------^-------------⊣
|
||||
http://yoursite.com/posts/index.html
|
||||
```
|
||||
|
||||
### Single Pages in Sections
|
||||
|
||||
Single content files in each of your sections are going to be rendered as [single page templates][singles]. Here is an example of a single `post` within `posts`:
|
||||
|
||||
|
||||
```bash
|
||||
path ("posts/my-first-hugo-post.md")
|
||||
. ⊢-----------^------------⊣
|
||||
. section slug
|
||||
. ⊢-^-⊣⊢--------^----------⊣
|
||||
content/posts/my-first-hugo-post.md
|
||||
```
|
||||
|
||||
At the time Hugo builds your site, the content will be output to the following destination:
|
||||
|
||||
```bash
|
||||
|
||||
url ("/posts/my-first-hugo-post/")
|
||||
⊢------------^----------⊣
|
||||
baseurl section slug
|
||||
⊢--------^--------⊣⊢-^--⊣⊢-------^---------⊣
|
||||
permalink
|
||||
⊢--------------------^---------------------⊣
|
||||
http://yoursite.com/posts/my-first-hugo-post/index.html
|
||||
```
|
||||
|
||||
### Section with Nested Directories
|
||||
|
||||
To continue the example, the following demonstrates destination paths for a file located at `content/events/chicago/lollapalooza.md` in the same site:
|
||||
|
||||
|
||||
```bash
|
||||
section
|
||||
⊢--^--⊣
|
||||
url
|
||||
⊢-------------^------------⊣
|
||||
|
||||
baseURL path slug
|
||||
⊢--------^--------⊣ ⊢------^-----⊣⊢----^------⊣
|
||||
permalink
|
||||
⊢----------------------^-----------------------⊣
|
||||
http://yoursite.com/events/chicago/lollapalooza/
|
||||
```
|
||||
|
||||
{{% note %}}
|
||||
As of v0.20, Hugo does not recognize nested sections. While you can nest as many content *directories* as you'd like, any child directory of a section will still be considered the same section as that of its parents. Therefore, in the above example, `{{.Section}}` for `lollapalooza.md` is `events` and *not* `chicago`. See the [related issue on GitHub](https://github.com/spf13/hugo/issues/465).
|
||||
{{% /note %}}
|
||||
|
||||
## Paths Explained
|
||||
|
||||
The following concepts will provide more insight into the relationship between your project's organization and the default behaviors of Hugo when building the output website.
|
||||
|
||||
### `section`
|
||||
|
||||
A default content type is determined by a piece of content's section. `section` is determined by the location within the project's `content` directory. `section` *cannot* be specified or overridden in front matter.
|
||||
|
||||
### `slug`
|
||||
|
||||
A content's `slug` is either `name.extension` or `name/`. The value for `slug` is determined by
|
||||
|
||||
* the name of the content file (e.g., `lollapalooza.md`) OR
|
||||
* front matter overrides
|
||||
|
||||
### `path`
|
||||
|
||||
A content's `path` is determined by the section's path to the file. The file `path`
|
||||
|
||||
* is based on the path to the content's location AND
|
||||
* does not include the slug
|
||||
|
||||
### `url`
|
||||
|
||||
The `url` is the relative URL for the piece of content. The `url`
|
||||
|
||||
* is based on the content's location within the directory structure OR
|
||||
* is defined in front matter and *overrides all the above*
|
||||
|
||||
## Overriding Destination Paths via Front Matter
|
||||
|
||||
Hugo believes that you organize your content with a purpose. The same structure that works to organize your source content is used to organize the rendered site. As displayed above, the organization of the source content will be mirrored in the destination.
|
||||
|
||||
There are times where you may need more control over your content. In these cases, there are fields that can be specified in the front matter to determine the destination of a specific piece of content.
|
||||
|
||||
The following items are defined in this order for a specific reason: items explained further down in the list will override earlier items, and not all of these items can be defined in front matter:
|
||||
|
||||
### `filename`
|
||||
|
||||
This isn't in the front matter, but is the actual name of the file minus the extension. This will be the name of the file in the destination (e.g., `content/posts/my-post.md` becomes `yoursite.com/posts/my-post/`).
|
||||
|
||||
### `slug`
|
||||
|
||||
When defined in the front matter, the `slug` can take the place of the filename for the destination.
|
||||
|
||||
{{% code file="content/posts/old-post.md" %}}
|
||||
```yaml
|
||||
---
|
||||
title: New Post
|
||||
slug: "new-post"
|
||||
---
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
This will render to the following destination according to Hugo's default behavior:
|
||||
|
||||
```
|
||||
yoursite.com/posts/new-post/
|
||||
```
|
||||
|
||||
### `section`
|
||||
|
||||
`section` is determined by a content's location on disk and *cannot* be specified in the front matter. See [sections][] for more information.
|
||||
|
||||
### `type`
|
||||
|
||||
A content's `type` is also determined by its location on disk but, unlike `section`, it *can* be specified in the front matter. See [types][]. This can come in especially handy when you want a piece of content to render using a different layout. In the following example, you can create a layout at `layouts/new/mylayout.html` that Hugo will use to render this piece of content, even in the midst of many other posts.
|
||||
|
||||
{{% code file="content/posts/my-post.md" %}}
|
||||
```yaml
|
||||
---
|
||||
title: My Post
|
||||
type: new
|
||||
layout: mylayout
|
||||
---
|
||||
```
|
||||
{{% /code %}}
|
||||
<!-- See https://discourse.gohugo.io/t/path-not-works/6387 -->
|
||||
<!-- ### `path`
|
||||
|
||||
`path` can be provided in the front matter. This will replace the actual path to the file on disk. Destination will create the destination with the same path, including the section. -->
|
||||
|
||||
### `url`
|
||||
|
||||
A complete URL can be provided. This will override all the above as it pertains to the end destination. This must be the path from the baseURL (starting with a `/`). `url` will be used exactly as it provided in the front matter and will ignore the `--uglyURLs` setting in your site configuration:
|
||||
|
||||
{{% code file="content/posts/old-url.md" %}}
|
||||
```yaml
|
||||
---
|
||||
title: Old URL
|
||||
url: /blog/new-url/
|
||||
---
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Assuming your `baseURL` is [configured][config] to `https://yoursite.com`, the addition of `url` to the front matter will make `old-url.md` render to the following destination:
|
||||
|
||||
```
|
||||
https://yoursite.com/blog/new-url/
|
||||
```
|
||||
|
||||
You can see more information on how to control output paths in [URL Management][urls].
|
||||
|
||||
[config]: /getting-started/configuration/
|
||||
[formats]: /content-management/formats/
|
||||
[front matter]: /content-management/front-matter/
|
||||
[getpage]: /functions/getpage/
|
||||
[homepage template]: /templates/homepage/
|
||||
[homepage]: /templates/homepage/
|
||||
[lists]: /templates/lists/
|
||||
[pretty]: /content-management/urls/#pretty-urls
|
||||
[section templates]: /templates/section-templates/
|
||||
[sections]: /content-management/sections/
|
||||
[singles]: /templates/single-page-templates/
|
||||
[taxonomy templates]: /templates/taxonomy-templates/
|
||||
[taxonomy terms templates]: /templates/taxonomy-templates/
|
||||
[types]: /content-management/types/
|
||||
[urls]: /content-management/urls/
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Content Sections
|
||||
linktitle: Sections
|
||||
description: Hugo provides full support for content sections, which according to Hugo's default behavior, will reflect the architecture of the rendered website.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [content management]
|
||||
tags: [lists,sections,content types,organization]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 50
|
||||
weight: 50 #rem
|
||||
draft: false
|
||||
aliases: [/content/sections/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## What are Sections in Hugo
|
||||
|
||||
Hugo believes that you organize your content with a purpose. The same structure that works to organize your source content is used to organize the rendered site (see [directory structure][]).
|
||||
|
||||
Following this pattern, Hugo uses the top level of your content organization as the content **section**.
|
||||
|
||||
The following example shows a content directory structure for a website that has three sections: "authors," "events," and "posts":
|
||||
|
||||
```bash
|
||||
.
|
||||
└── content
|
||||
├── authors
|
||||
| ├── _index.md // <- yoursite.com/authors/
|
||||
| ├── john-doe.md // <- yoursite.com/authors/john-doe/
|
||||
| └── jane-doe.md // <- yoursite.com/authors/jane-doe/
|
||||
└── events
|
||||
| ├── _index.md // <- yoursite.com/events/
|
||||
| ├── event-1.md // <- yoursite.com/events/event-1/
|
||||
| ├── event-2.md // <- yoursite.com/events/event-2/
|
||||
| └── event-3.md // <- yoursite.com/events/event-3/
|
||||
└── posts
|
||||
| ├── _index.md // <- yoursite.com/posts/
|
||||
| ├── event-1.md // <- yoursite.com/posts/event-1/
|
||||
| ├── event-2.md // <- yoursite.com/posts/event-2/
|
||||
| ├── event-3.md // <- yoursite.com/posts/event-3/
|
||||
| ├── event-4.md // <- yoursite.com/posts/event-4/
|
||||
| └── event-5.md // <- yoursite.com/posts/event-5/
|
||||
```
|
||||
|
||||
## Content Section Lists
|
||||
|
||||
Hugo will automatically create pages for each section root that list all of the content in that section. See the documentation on [section templates][] for details on customizing the way these pages are rendered.
|
||||
|
||||
As of Hugo v0.18, section pages can also have a content file and front matter. These section content files must be placed in their corresponding section folder and named `_index.md` in order for Hugo to correctly render the front matter and content.
|
||||
|
||||
{{% warning "`index.md` vs `_index.md`" %}}
|
||||
Hugo themes developed before v0.18 often used an `index.md`(i.e., without the leading underscore [`_`]) in a content section as a hack to emulate the behavior of `_index.md`. The hack may work...*sometimes*; however, the order of page rendering can be unpredictable in Hugo. What works now may fail to render appropriately as your site grows. It is **strongly advised** to use `_index.md` as content for your section index pages. **Note:** `_index.md`'s layout, as representative of a section, is a [list page template](/templates/section-templates/) and *not* a [single page template](/templates/single-page-templates/). If you want to alter the new default behavior for `_index.md`, configure `disableKinds` accordingly in your [site's configuration](/getting-started/configuration/).
|
||||
{{% /warning %}}
|
||||
|
||||
## Content *Section* vs Content *Type*
|
||||
|
||||
By default, everything created within a section will use the [content type][] that matches the section name. For example, Hugo will assume that `posts/post-1.md` has a `posts` content type. If you are using an [archetype][] for your posts section, Hugo will generate front matter according to what it finds in `archetypes/posts.md`.
|
||||
|
||||
[archetype]: /content-management/archetypes/
|
||||
[content type]: /content-management/types/
|
||||
[directory structure]: /getting-started/directory-structure/
|
||||
[section templates]: /templates/section-templates/
|
||||
|
||||
|
||||
@@ -0,0 +1,431 @@
|
||||
---
|
||||
title: Shortcodes
|
||||
linktitle:
|
||||
description: Shortcodes are simple snippets inside your content files that Hugo renders renders so as not to mess with the clean and simple syntax of your preferred content format.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-03-31
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 35
|
||||
weight: 35 #rem
|
||||
categories: [content management]
|
||||
tags: [markdown,content,shortcodes]
|
||||
draft: false
|
||||
aliases: [/extras/shortcodes/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## What is a Shortcode
|
||||
|
||||
Hugo loves Markdown because of its simple content format, but there are times when Markdown falls short. Often, content authors are forced to add raw HTML (e.g., video `<iframes>`) to Markdown content. We think this contradicts the beautiful simplicity of Markdown's syntax.
|
||||
|
||||
Hugo created **shortcodes** to circumvent these limitations.
|
||||
|
||||
A shortcode is a simple snippet inside a content file that Hugo will render using a predefined template. Note that shortcodes will not work in template files. If you need the type of drop-in functionality that shortcodes provide but in a template, you most likely want a [partial template][partials] instead.
|
||||
|
||||
In addition to cleaner Markdown, shortcodes can be updated any time to reflect new classes, techniques, or standards. At the point of site generation, Hugo shortcodes will easily merge in your changes. You avoid a possibly complicated search and replace operation.
|
||||
|
||||
## Using Shortcodes
|
||||
|
||||
In your content files, a shortcode can be called by calling `{{%/* shortcodename parameters*/%}}`. Shortcode parameters are space delimited, and parameters with internal spaces can be quoted.
|
||||
|
||||
The first word in the shortcode declaration is always the name of the shortcode. Parameters follow the name. Depending upon how the shortcode is defined, the parameters may be named, positional, or both, although you can't mix parameter types in a single call. The format for named parameters models that of HTML with the format `name="value"`.
|
||||
|
||||
Some shortcodes use or require closing shortcodes. Again like HTML, the opening and closing shortcodes match (name only) with the closing declaration, which is prepended with a slash.
|
||||
|
||||
Here are two examples of paired shortcodes:
|
||||
|
||||
```md
|
||||
{{%/* mdshortcode */%}}Stuff to `process` in the *center*.{{%/* /mdshortcode */%}}
|
||||
```
|
||||
|
||||
```md
|
||||
{{</* highlight go */>}} A bunch of code here {{</* /highlight */>}}
|
||||
```
|
||||
|
||||
The examples above use two different delimiters, the difference being the `%` character in the first and the `<>` characters in the second.
|
||||
|
||||
### Shortcodes with Markdown
|
||||
|
||||
The `%` character indicates that the shortcode's inner content---called in the [shortcode template][sctemps] with the [`.Inner` variable][scvars]---needs further processing by the page's rendering processor (i.e. markdown via Blackfriday). In the following example, Blackfriday would convert `**World**` to `<strong>World</strong>`:
|
||||
|
||||
```md
|
||||
{{%/* myshortcode */%}}Hello **World!**{{%/* /myshortcode */%}}
|
||||
```
|
||||
|
||||
### Shortcodes Without Markdown
|
||||
|
||||
The `<` character indicates that the shortcode's inner content does *not* need further rendering. Often shortcodes without markdown include internal HTML:
|
||||
|
||||
```md
|
||||
{{</* myshortcode */>}}<p>Hello <strong>World!</strong></p>{{</* /myshortcode */>}}
|
||||
```
|
||||
|
||||
### Nested Shortcodes
|
||||
|
||||
You can call shortcodes within other shortcodes by creating your own templates that leverage the `.Parent` variable. `.Parent` allows you to check the context in which the shortcode is being called. See [Shortcode templates][sctemps].
|
||||
|
||||
## Using Hugo's Built-in Shortcodes
|
||||
|
||||
Hugo ships with a set of predefined shortcodes that represent very common usage. These shortcodes are provided for author convenience and to keep your markdown content clean.
|
||||
|
||||
### `figure`
|
||||
|
||||
`figure` is an extension of the image syntax in markdown, which does not provide a shorthand for the more semantic [HTML5 `<figure>` element][figureelement].
|
||||
|
||||
The `figure` shortcode can use the following named parameters:
|
||||
|
||||
* `src`
|
||||
* `link`
|
||||
* `title`
|
||||
* `caption`
|
||||
* `class`
|
||||
* `attr` (i.e., attribution)
|
||||
* `attrlink`
|
||||
* `alt`
|
||||
|
||||
#### Example `figure` Input
|
||||
|
||||
{{% code file="figure-input-example.md" %}}
|
||||
```markdown
|
||||
{{</* figure src="/media/spf13.jpg" title="Steve Francia" */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `figure` Output
|
||||
|
||||
{{% output file="figure-output-example.html" %}}
|
||||
```html
|
||||
<figure>
|
||||
<img src="/media/spf13.jpg" />
|
||||
<figcaption>
|
||||
<h4>Steve Francia</h4>
|
||||
</figcaption>
|
||||
</figure>
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
### `gist`
|
||||
|
||||
Bloggers often want to include GitHub gists when writing posts. Let's suppose we want to use the [gist at the following url][examplegist]:
|
||||
|
||||
```html
|
||||
https://gist.github.com/spf13/7896402
|
||||
```
|
||||
|
||||
We can embed the gist in our content via username and gist ID pulled from the URL:
|
||||
|
||||
```md
|
||||
{{</* gist spf13 7896402 */>}}
|
||||
```
|
||||
|
||||
#### Example `gist` Input
|
||||
|
||||
If the gist contains several files and you want to quote just one of them, you can pass the filename (quoted) as an optional third argument:
|
||||
|
||||
{{% code file="gist-input.md" %}}
|
||||
```md
|
||||
{{</* gist spf13 7896402 "img.html" */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `gist` Output
|
||||
|
||||
{{% output file="gist-output.html" %}}
|
||||
```html
|
||||
{{< gist spf13 7896402 >}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### Example `gist` Display
|
||||
|
||||
To demonstrate the remarkably efficiency of Hugo's shortcode feature, we have embedded the `spf13` `gist` example in this page. The following simulates the experience for visitors to your website. Naturally, the final display will be contingent on your stylesheets and surrounding markup.
|
||||
|
||||
{{< gist spf13 7896402 >}}
|
||||
|
||||
### `highlight`
|
||||
|
||||
This shortcode will convert the source code provided into syntax-highlighted HTML. Read more on [highlighting](/tools/syntax-highlighting/). `highlight` takes exactly one required `language` parameter and requires a closing shortcode.
|
||||
|
||||
#### Example `highlight` Input
|
||||
|
||||
{{% code file="content/tutorials/learn-html.md" %}}
|
||||
```html
|
||||
{{</* highlight html */>}}
|
||||
<section id="main">
|
||||
<div>
|
||||
<h1 id="title">{{ .Title }}</h1>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
</div>
|
||||
</section>
|
||||
{{</* /highlight */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `highlight` Output
|
||||
|
||||
The `highlight` shortcode example above would produce the following HTML when the site is rendered:
|
||||
|
||||
{{% output file="tutorials/learn-html/index.html" %}}
|
||||
```html
|
||||
<span style="color: #f92672"><section</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">"main"</span><span style="color: #f92672">></span>
|
||||
<span style="color: #f92672"><div></span>
|
||||
<span style="color: #f92672"><h1</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">"title"</span><span style="color: #f92672">></span>{{ .Title }}<span style="color: #f92672"></h1></span>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
<span style="color: #f92672"></div></span>
|
||||
<span style="color: #f92672"></section></span>
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
{{% note "More on Syntax Highlighting" %}}
|
||||
To see even more options for adding syntax-highlighted code blocks to your website, see [Syntax Highlighting in Developer Tools](/tools/syntax-highlighting/).
|
||||
{{% /note %}}
|
||||
|
||||
### `instagram`
|
||||
|
||||
If you'd like to embed a photo from [Instagram][], you only need the photo's ID. You can discern an Instagram photo ID from the URL:
|
||||
|
||||
```html
|
||||
https://www.instagram.com/p/BMokmydjG-M/
|
||||
```
|
||||
|
||||
#### Example `instagram` Input
|
||||
|
||||
{{% code file="instagram-input.md" %}}
|
||||
```md
|
||||
{{</* instagram BMokmydjG-M */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
You also have the option to hide the caption:
|
||||
|
||||
{{% code file="instagram-input-hide-caption.md" %}}
|
||||
```md
|
||||
{{</* instagram BMokmydjG-M hidecaption */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `instagram` Output
|
||||
|
||||
By adding the preceding `hidecaption` example, the following HTML will be added to your rendered website's markup:
|
||||
|
||||
{{% output file="instagram-hide-caption-output.html" %}}
|
||||
```html
|
||||
{{< instagram BMokmydjG-M hidecaption >}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### Example `instagram` Display
|
||||
|
||||
Using the preceding `instagram` with hidecaption` example above, the following simulates the displayed experience for visitors to your website. Naturally, the final display will be contingent on your stylesheets and surrounding markup.
|
||||
|
||||
{{< instagram BMokmydjG-M hidecaption >}}
|
||||
|
||||
|
||||
### `ref` and `relref`
|
||||
|
||||
These shortcodes will look up the pages by their relative path (e.g., `blog/post.md`) or their logical name (`post.md`) and return the permalink (`ref`) or relative permalink (`relref`) for the found page.
|
||||
|
||||
`ref` and `relref` also make it possible to make fragmentary links that work for the header links generated by Hugo.
|
||||
|
||||
{{% note "More on Cross References" %}}
|
||||
Read a more extensive description of `ref` and `relref` in the [cross references](/content-management/cross-references/) documentation.
|
||||
{{% /note %}}
|
||||
|
||||
`ref` and `relref` take exactly one required parameter of _reference_, quoted and in position `0`.
|
||||
|
||||
#### Example `ref` and `relref` Input
|
||||
|
||||
```md
|
||||
[Neat]({{</* ref "blog/neat.md" */>}})
|
||||
[Who]({{</* relref "about.md#who" */>}})
|
||||
```
|
||||
|
||||
#### Example `ref` and `relref` Output
|
||||
|
||||
Assuming that standard Hugo pretty URLs are turned on.
|
||||
|
||||
```html
|
||||
<a href="/blog/neat">Neat</a>
|
||||
<a href="/about/#who:c28654c202e73453784cfd2c5ab356c0">Who</a>
|
||||
```
|
||||
|
||||
### `speakerdeck`
|
||||
|
||||
To embed slides from [Speaker Deck][], click on "< /> Embed" (under Share right next to the template on Speaker Deck) and copy the URL:
|
||||
|
||||
```html
|
||||
<script async class="speakerdeck-embed" data-id="4e8126e72d853c0060001f97" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
|
||||
```
|
||||
|
||||
#### `speakerdeck` Example Input
|
||||
|
||||
Extract the value from the field `data-id` and pass it to the shortcode:
|
||||
|
||||
{{% code file="speakerdeck-example-input.md" %}}
|
||||
```md
|
||||
{{</* speakerdeck 4e8126e72d853c0060001f97 */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### `speakerdeck` Example Output
|
||||
|
||||
{{% output file="speakerdeck-example-input.md" %}}
|
||||
```html
|
||||
{{< speakerdeck 4e8126e72d853c0060001f97 >}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### `speakerdeck` Example Display
|
||||
|
||||
For the preceding `speakerdeck` example, the following simulates the displayed experience for visitors to your website. Naturally, the final display will be contingent on your stylesheets and surrounding markup.
|
||||
|
||||
{{< speakerdeck 4e8126e72d853c0060001f97 >}}
|
||||
|
||||
### `tweet`
|
||||
|
||||
You want to include a single tweet into your blog post? Everything you need is the URL of the tweet:
|
||||
|
||||
```
|
||||
https://twitter.com/spf13/status/666616452582129664
|
||||
```
|
||||
|
||||
#### Example `tweet` Input
|
||||
|
||||
Pass the tweet's ID from the URL as a parameter to the `tweet` shortcode:
|
||||
|
||||
{{% code file="example-tweet-input.md" %}}
|
||||
```md
|
||||
{{</* tweet 666616452582129664 */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `tweet` Output
|
||||
|
||||
Using the preceding `tweet` example, the following HTML will be added to your rendered website's markup:
|
||||
|
||||
{{% output file="example-tweet-output.html" %}}
|
||||
```html
|
||||
{{< tweet 666616452582129664 >}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### Example `tweet` Display
|
||||
|
||||
Using the preceding `tweet` example, the following simulates the displayed experience for visitors to your website. Naturally, the final display will be contingent on your stylesheets and surrounding markup.
|
||||
|
||||
{{< tweet 666616452582129664 >}}
|
||||
|
||||
### `vimeo`
|
||||
|
||||
Adding a video from [Vimeo][] is equivalent to the YouTube shortcode above.
|
||||
|
||||
```
|
||||
https://vimeo.com/channels/staffpicks/146022717
|
||||
```
|
||||
|
||||
#### Example `vimeo` Input
|
||||
|
||||
Extract the ID from the video's URL and pass it to the `vimeo` shortcode:
|
||||
|
||||
{{% code file="example-vimeo-input.md" %}}
|
||||
```md
|
||||
{{</* vimeo 146022717 */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `vimeo` Output
|
||||
|
||||
Using the preceding `vimeo` example, the following HTML will be added to your rendered website's markup:
|
||||
|
||||
{{% output file="example-vimeo-output.html" %}}
|
||||
```html
|
||||
{{< vimeo 146022717 >}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
{{% tip %}}
|
||||
If you want to further customize the visual styling of the YouTube or Vimeo output, add a `class` named parameter when calling the shortcode. The new `class` will be added to the `<div>` that wraps the `<iframe>` *and* will remove the inline styles. Note that you will need to call the `id` as a named parameter as well.
|
||||
|
||||
```md
|
||||
{{</* vimeo id="146022717" class="my-vimeo-wrapper-class" */>}}
|
||||
```
|
||||
{{% /tip %}}
|
||||
|
||||
#### Example `vimeo` Display
|
||||
|
||||
Using the preceding `vimeo` example, the following simulates the displayed experience for visitors to your website. Naturally, the final display will be contingent on your stylesheets and surrounding markup.
|
||||
|
||||
{{< vimeo 146022717 >}}
|
||||
|
||||
### `youtube`
|
||||
|
||||
The `youtube` shortcode embeds a responsive video player for [YouTube videos][]. Only the ID of the video is required, e.g.:
|
||||
|
||||
```
|
||||
https://www.youtube.com/watch?v=w7Ft2ymGmfc
|
||||
```
|
||||
|
||||
|
||||
#### Example `youtube` Input
|
||||
|
||||
Copy the YouTube video ID that follows `v=` in the video's URL and pass it to the `youtube` shortcode:
|
||||
|
||||
{{% code file="example-youtube-input.md" %}}
|
||||
```md
|
||||
{{</* youtube w7Ft2ymGmfc */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Furthermore, you can automatically start playback of the embedded video by setting the `autoplay` parameter to `true`. Remember that you can't mix named an unnamed parameters, so you'll need to assign the yet unnamed video id to the parameter `id`:
|
||||
|
||||
|
||||
{{% code file="example-youtube-input-with-autoplay.md" %}}
|
||||
```md
|
||||
{{</* youtube id="w7Ft2ymGmfc" autoplay="true" */>}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `youtube` Output
|
||||
|
||||
Using the preceding `youtube` example, the following HTML will be added to your rendered website's markup:
|
||||
|
||||
{{% code file="example-youtube-output.html" %}}
|
||||
```html
|
||||
{{< youtube id="w7Ft2ymGmfc" autoplay="true" >}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `youtube` Display
|
||||
|
||||
Using the preceding `youtube` example (without `autoplay="true"`), the following simulates the displayed experience for visitors to your website. Naturally, the final display will be contingent on your stylesheets and surrounding markup. The video is also include in the [Quick Start of the Hugo documentation][quickstart].
|
||||
|
||||
{{< youtube w7Ft2ymGmfc >}}
|
||||
|
||||
## Creating Custom Shortcodes
|
||||
|
||||
To learn more about creating custom shortcodes, see the [shortcode template documentation][].
|
||||
|
||||
[`figure` shortcode]: #figure
|
||||
[contentmanagementsection]: /content-management/formats/
|
||||
[examplegist]: https://gist.github.com/spf13/7896402
|
||||
[figureelement]: http://html5doctor.com/the-figure-figcaption-elements/ "An article from HTML5 doctor discussing the fig and figcaption elements."
|
||||
[Instagram]: https://www.instagram.com/
|
||||
[pagevariables]: /variables/page/
|
||||
[partials]: /templates/partials/
|
||||
[Pygments]: http://pygments.org/
|
||||
[quickstart]: /getting-started/quick-start/
|
||||
[sctemps]: /templates/shortcode-templates/
|
||||
[scvars]: /variables/shortcodes/
|
||||
[shortcode template documentation]: /templates/shortcode-templates/
|
||||
[Speaker Deck]: https://speakerdeck.com/
|
||||
[templatessection]: /templates/
|
||||
[Vimeo]: https://vimeo.com/
|
||||
[YouTube Videos]: https://www.youtube.com/
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: Content Summaries
|
||||
linktitle: Summaries
|
||||
description: Hugo can generate summaries of your content to show snippets in summary views. You have the option to split these summaries yourself or let Hugo automatically generate them for you.
|
||||
date: 2017-01-10
|
||||
publishdate: 2017-01-10
|
||||
lastmod: 2017-01-10
|
||||
categories: [content management]
|
||||
tags: [summaries,abstracts,read more]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 90
|
||||
weight: 90 #rem
|
||||
draft: false
|
||||
aliases: [/content/summaries/,/content-management/content-summaries/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
With the use of the `.Summary` [page variable][pagevariables], Hugo can generate summaries of content to show snippets in summary views. The summary view snippets are automatically generated by Hugo and offer two splitting options.
|
||||
|
||||
## Summary Splitting Options
|
||||
|
||||
You have two options for where the content is split:
|
||||
|
||||
* Hugo-defined Summary Split
|
||||
* User-defined Summary Split
|
||||
|
||||
Content summaries may also provide links to the original content. A common design pattern is to see this link in the form of a "Read More..." button. To make this easier, you can leverage the `.RelPermalink`, `.Permalink`, and `.Truncated` [page variables][pagevariables].
|
||||
|
||||
### Hugo-defined: Automatic Summary Splitting
|
||||
|
||||
By default, Hugo automatically takes the first 70 words of your content as its summary and stores it into the `.Summary` page variable for use in your templates. Taking the Hugo-defined approach to summaries may save time, but it has pros and cons:
|
||||
|
||||
* **Pros:** Automatic, no additional work on your part.
|
||||
* **Cons:** All HTML tags are stripped from the summary, and the first 70 words, whether they belong to a heading or to different paragraphs, are all lumped into one paragraph.
|
||||
|
||||
{{% note %}}
|
||||
The Hugo-defined summaries are set to use word count by default. However, "word count" is relatively defined. If you are creating content in a CJK language and want to use Hugo's automatic summary splitting, set `hasCJKLanguage` to `true` in you [site configuration](/getting-started/configuration/).
|
||||
{{% /note %}}
|
||||
|
||||
### User-defined: Manual Summary Splitting
|
||||
|
||||
Alternatively, you may add the <code><!--more--></code> summary divider where you want to split the article. For [org content][org], use `# more` where you want to split the article. Content that comes before the summary divider will be used as that content's summary and stored in the `.Summary` page variable with all HTML formatting intact.
|
||||
|
||||
{{% note "Summary Divider"%}}
|
||||
The concept of a *summary divider* is not unique to Hugo. It is also called the "more tag" or "excerpt separator" in other literature.
|
||||
{{% /note %}}
|
||||
|
||||
* Pros: Freedom, precision, and improved rendering. All HTML tags and formatting are preserved.
|
||||
* Cons: Extra work for content authors, since they need to remember to type <code><!--more--></code> (or `# more` for [org content][org]) in each content file. This can be automated by adding the summary divider below the front matter of an [archetype](/content-management/archetypes/).
|
||||
|
||||
{{% warning "Be Precise with the Summary Divider" %}}
|
||||
Be careful to enter <code><!--more--></code> exactly; i.e., all lowercase and with no whitespace. Any mistakes in the divider will tell Hugo to treat the divider as a regular comment and will fail to store your desired content in the `.Summary` variable.
|
||||
{{% /warning %}}
|
||||
|
||||
## Example: First 10 Articles with Summaries
|
||||
|
||||
You can show content summaries with the following code. You could use the following snippet, for example, in a [section template][].
|
||||
|
||||
{{% code file="page-list-with-summaries.html" %}}
|
||||
```html
|
||||
{{ range first 10 .Data.Pages }}
|
||||
<article>
|
||||
<!-- this <div> includes the title summary -->
|
||||
<div>
|
||||
<h2><a href="{{ .RelPermalink }}">{{ .Title }}</a></h2>
|
||||
{{ .Summary }}
|
||||
</div>
|
||||
{{ if .Truncated }}
|
||||
<!-- This <div> includes a read more link, but only if the summary is truncated... -->
|
||||
<div>
|
||||
<a href="{{ .RelPermalink }}">Read More…</a>
|
||||
</div>
|
||||
{{ end }}
|
||||
</article>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Note how the `.Truncated` boolean valuable may be used to hide the "Read More..." link when the content is not truncated; i.e., when the summary contains the entire article.
|
||||
|
||||
[org]: /content-management/formats/
|
||||
[pagevariables]: /variables/page/
|
||||
[section template]: /templates/section-templates/
|
||||
@@ -0,0 +1,240 @@
|
||||
---
|
||||
title: Taxonomies
|
||||
linktitle:
|
||||
description: Hugo includes support for user-defined taxonomies to help you demonstrate logical relationships between content for the end users of your website.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
tags: [taxonomies,metadata,front matter,terms]
|
||||
categories: [content management]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 80
|
||||
weight: 80 #rem
|
||||
draft: false
|
||||
aliases: [/taxonomies/overview/,/taxonomies/usage/,/indexes/overview/,/doc/indexes/,/extras/indexes]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## What is a Taxonomy?
|
||||
|
||||
Hugo includes support for user-defined groupings of content called **taxonomies**. Taxonomies are classifications that demonstrate logical relationships between content.
|
||||
|
||||
### Definitions
|
||||
|
||||
In order to effectively work with taxonomies in Hugo, it's important to first understand the language used to described the concept.
|
||||
|
||||
Taxonomy
|
||||
: a categorization that can be used to classify content
|
||||
|
||||
Term
|
||||
: a key within the taxonomy
|
||||
|
||||
Value
|
||||
: a piece of content assigned to a term
|
||||
|
||||
## Example Taxonomy: Movie Website
|
||||
|
||||
Let's assume you are making a website about movies. You may want to include the following taxonomies:
|
||||
|
||||
* Actors
|
||||
* Directors
|
||||
* Studios
|
||||
* Genre
|
||||
* Year
|
||||
* Awards
|
||||
|
||||
Then, in each of the movies, you would specify terms for each of these taxonomies (i.e., in the [front matter][] of each of your movie content files). From these terms, Hugo would automatically create pages for each Actor, Director, Studio, Genre, Year, and Award, with each listing all of the Movies that matched that specific Actor, Director, Studio, Genre, Year, and Award.
|
||||
|
||||
### Movie Taxonomy Organization
|
||||
|
||||
To continue with the example of a movie site, the following demonstrates content relationships from the perspective of the taxonomy:
|
||||
|
||||
```
|
||||
Actor <- Taxonomy
|
||||
Bruce Willis <- Term
|
||||
The Six Sense <- Content
|
||||
Unbreakable <- Content
|
||||
Moonrise Kingdom <- Content
|
||||
Samuel L. Jackson <- Term
|
||||
Unbreakable <- Content
|
||||
The Avengers <- Content
|
||||
xXx <- Content
|
||||
```
|
||||
|
||||
From the perspective of the content, the relationships would appear differently, although the data and labels used are the same:
|
||||
|
||||
```
|
||||
Unbreakable <- Content
|
||||
Actors <- Taxonomy
|
||||
Bruce Willis <- Term
|
||||
Samuel L. Jackson <- Term
|
||||
Director <- Taxonomy
|
||||
M. Night Shyamalan <- Term
|
||||
...
|
||||
Moonrise Kingdom <- Content
|
||||
Actors <- Taxonomy
|
||||
Bruce Willis <- Term
|
||||
Bill Murray <- Term
|
||||
Director <- Taxonomy
|
||||
Wes Anderson <- Term
|
||||
...
|
||||
```
|
||||
|
||||
## Hugo Taxonomy Defaults
|
||||
|
||||
Hugo natively supports taxonomies, which means there are architectural patterns for rendering your project's taxonomies baked into Hugo's core.
|
||||
|
||||
Without adding a single line to your site's configuration file, Hugo will automatically create taxonomies for `tags` and `categories`. If you do not want Hugo to create these taxonomies---even though the values may be added to your content files' front matter---set `disableKinds` in your site's configuration to the following:
|
||||
|
||||
```toml
|
||||
disableKinds = ["taxonomy","taxonomyTerm"]
|
||||
```
|
||||
|
||||
### Default Destinations
|
||||
|
||||
When taxonomies are used---and [taxonomy templates][] are provided---Hugo will automatically create both a page listing all the taxonomy's terms and individual pages with lists of content associated with each term. For example, a `categories` taxonomy declared in your your configuration and used in your content front matter will create the following pages:
|
||||
|
||||
* A single page at `yoursite.com/categories/` that lists all the [terms within the taxonomy][]
|
||||
* [Individual taxonomy list pages][taxonomy templates] (e.g., `/categories/development/`) for each of the terms that shows a listing of all pages marked as part of that taxonomy within any content file's [front matter][]
|
||||
|
||||
## Configuring Taxonomies
|
||||
|
||||
Taxonomies must be defined in your [website configuration][config] before they can be used throughout the site. You need to provide both the plural and singular labels for each taxonomy. For example, `singular key = "plural value"` for TOML and `singular key: "plural value"` for YAML.
|
||||
|
||||
### Example: TOML Taxonomy Configuration
|
||||
|
||||
```toml
|
||||
[taxonomies]
|
||||
tag = "tags"
|
||||
category = "categories"
|
||||
series = "series"
|
||||
```
|
||||
|
||||
### Example: YAML Taxonomy Configuration
|
||||
|
||||
```yaml
|
||||
taxonomies:
|
||||
tag: "tags"
|
||||
category: "categories"
|
||||
series: "series"
|
||||
```
|
||||
|
||||
### Preserving Taxonomy Values
|
||||
|
||||
By default, taxonomy names are hyphenated, lower-cased, normalized, and then fixed and title-ized within.
|
||||
|
||||
Therefore, if you want to have a taxonomy term with special characters such as `Gérard Depardieu` instead of `Gerard Depardieu`, set the value for `preserveTaxonomyNames` to `true` in your [site configuration][config]. Hugo will then preserve special characters in taxonomy values but will still title-ize the values for titles and normalize them in URLs.
|
||||
|
||||
Note that if you use `preserveTaxonomyNames` and intend to manually construct URLs to the archive pages, you will need to pass the taxonomy values through the [`urlize` template function][].
|
||||
|
||||
{{% note %}}
|
||||
You can add content and front matter to your taxonomy list and taxonomy terms pages. See [Content Organization](/content-management/organization/) for more information on how to add an `_index.md` for this purpose.
|
||||
|
||||
Note also that taxonomy [permalinks](/content-management/urls/) are *not* configurable.
|
||||
{{% /note %}}
|
||||
|
||||
## Adding Taxonomies to Content
|
||||
|
||||
Once a taxonomy is defined at the site level, any piece of content can be assigned to it, regardless of [content type][] or [content section][].
|
||||
|
||||
Assigning content to a taxonomy is done in the [front matter][]. Simply create a variable with the *plural* name of the taxonomy and assign all terms you want to apply to the instance of the content type.
|
||||
|
||||
{{% note %}}
|
||||
If you would like the ability to quickly generate content files with preconfigured taxonomies or terms, read the docs on [Hugo archetypes](/content-management/archetypes/).
|
||||
{{% /note %}}
|
||||
|
||||
### Example: TOML Front Matter with Taxonomies
|
||||
|
||||
```toml
|
||||
+++
|
||||
title = "Hugo: A fast and flexible static site generator"
|
||||
tags = [ "Development", "Go", "fast", "Blogging" ]
|
||||
categories = [ "Development" ]
|
||||
series = [ "Go Web Dev" ]
|
||||
slug = "hugo"
|
||||
project_url = "https://github.com/spf13/hugo"
|
||||
+++
|
||||
```
|
||||
|
||||
### Example: YAML Front Matter with Taxonomies
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: "Hugo: A fast and flexible static site generator"
|
||||
tags: ["Development", "Go", "fast", "Blogging"]
|
||||
categories: ["Development"]
|
||||
categories: ["Go Web Dev"]
|
||||
slug: "hugo"
|
||||
project_url: "https://github.com/spf13/hugo"
|
||||
---
|
||||
```
|
||||
|
||||
### Example: JSON Front Matter with Taxonomies
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "Hugo: A fast and flexible static site generator",
|
||||
"tags": [
|
||||
"Development",
|
||||
"Go",
|
||||
"fast",
|
||||
"Blogging"
|
||||
],
|
||||
"categories" : [
|
||||
"Development"
|
||||
],
|
||||
"series" : [
|
||||
"Go Web Dev"
|
||||
],
|
||||
"slug": "hugo",
|
||||
"project_url": "https://github.com/spf13/hugo"
|
||||
}
|
||||
```
|
||||
|
||||
## Ordering Taxonomies
|
||||
|
||||
A content file can assign weight for each of its associate taxonomies. Taxonomic weight can be used for sorting or ordering content in [taxonomy list templates][] and is declared in a content file's [front matter][]. The convention for declaring taxonomic weight is `taxonomyname_weight`.
|
||||
|
||||
The following TOML and YAML examples show a piece of content that has a weight of 22, which can be used for ordering purposes when rendering the pages assigned to the "a", "b" and "c" values of the `tags` taxonomy. It has also been assigned the weight of 44 when rendering the "d" category page.
|
||||
|
||||
### Example: TOML Taxonomic `weight`
|
||||
|
||||
```toml
|
||||
+++
|
||||
title = "foo"
|
||||
tags = [ "a", "b", "c" ]
|
||||
tags_weight = 22
|
||||
categories = ["d"]
|
||||
categories_weight = 44
|
||||
+++
|
||||
```
|
||||
|
||||
### Example: YAML Taxonomic `weight`
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: foo
|
||||
tags: [ "a", "b", "c" ]
|
||||
tags_weight: 22
|
||||
categories: ["d"]
|
||||
categories_weight: 44
|
||||
---
|
||||
```
|
||||
|
||||
By using taxonomic weight, the same piece of content can appear in different positions in different taxonomies.
|
||||
|
||||
{{% note "Limits to Ordering Taxonomies" %}}
|
||||
Currently taxonomies only support the [default `weight => date` ordering of list content](/templates/lists/#default-weight-date). For more information, see the documentation on [taxonomy templates](/templates/taxonomy-templates/).
|
||||
{{% /note %}}
|
||||
|
||||
[`urlize` template function]: /functions/urlize/
|
||||
[content section]: /content-management/sections/
|
||||
[content type]: /content-management/types/
|
||||
[documentation on archetypes]: /content-management/archetypes/
|
||||
[front matter]: /content-management/front-matter/
|
||||
[taxonomy list templates]: /templates/taxonomy-templates/#taxonomy-page-templates
|
||||
[taxonomy templates]: /templates/taxonomy-templates/
|
||||
[terms within the taxonomy]: /templates/taxonomy-templates/#taxonomy-terms-templates "See how to order terms associated with a taxonomy"
|
||||
[config]: /getting-started/configuration/
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
title: Table of Contents
|
||||
linktitle:
|
||||
description: Hugo can automatically parse Markdown content and create a Table of Contents you can leverage in your templates to guide readers to sections of longer pages.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [content management]
|
||||
tags: [table of contents, toc]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 130
|
||||
weight: 130 #rem
|
||||
draft: false
|
||||
aliases: [/extras/toc/,/content-management/toc/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo can automatically parse Markdown content and create a Table of Contents you can leverage in your templates to guide readers to sections of longer pages.
|
||||
|
||||
{{% note "TOC Heading Levels are Fixed" %}}
|
||||
Currently, the `{{.TableOfContents}}` [page variable](/variables/page/) does not allow you to specify which heading levels you want the TOC to render. [See the related GitHub discussion (#1778)](https://github.com/spf13/hugo/issues/1778). As such, the resulting `<nav id="TableOfContents"><ul></ul></nav>` is going to start at `<h1>` when pulling from `{{.Content}}`.
|
||||
{{% /note %}}
|
||||
|
||||
## Usage
|
||||
|
||||
Create your markdown the way you normally would with the appropriate headings. Here is some example content:
|
||||
|
||||
```md
|
||||
<!-- Your front matter up here -->
|
||||
|
||||
## Introduction
|
||||
|
||||
One morning, when Gregor Samsa woke from troubled dreams, he found himself transformed in his bed into a horrible vermin.
|
||||
|
||||
## My Heading
|
||||
|
||||
He lay on his armour-like back, and if he lifted his head a little he could see his brown belly, slightly domed and divided by arches into stiff sections. The bedding was hardly able to cover it and seemed ready to slide off any moment.
|
||||
|
||||
### My Subheading
|
||||
|
||||
A collection of textile samples lay spread out on the table - Samsa was a travelling salesman - and above it there hung a picture that he had recently cut out of an illustrated magazine and housed in a nice, gilded frame. It showed a lady fitted out with a fur hat and fur boa who sat upright, raising a heavy fur muff that covered the whole of her lower arm towards the viewer. Gregor then turned to look out the window at the dull weather. Drops
|
||||
```
|
||||
|
||||
Hugo will take this Markdown and create a table of contents from `## Introduction`, `## My Heading`, and `### My Subheading` and then store it in the [page variable][pagevars]`.TableOfContents`.
|
||||
|
||||
The built-in `.TableOfContents` variables outputs a `<nav id="TableOfContents">` element with a child `<ul>`, whose child `<li>` elements begin with any `<h1>`'s (i.e., `#` in markdown) inside your content.'
|
||||
|
||||
## Template Example: Basic TOC
|
||||
|
||||
The following is an example of a very basic [single page template][]:
|
||||
|
||||
{{% code file="layout/_default/single.html" download="single.html" %}}
|
||||
```html
|
||||
{{ define "main" }}
|
||||
<main>
|
||||
<article>
|
||||
<header>
|
||||
<h1>{{ .Title }}</h1>
|
||||
</header>
|
||||
{{ .Content }}
|
||||
</article>
|
||||
<aside>
|
||||
{{ .TableOfContents }}
|
||||
</aside>
|
||||
</main>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
## Template Example: TOC Partial
|
||||
|
||||
The following is a [partial template][partials] that adds slightly more logic for page-level control over your table of contents. It assumes you are using a `toc` field in your content's [front matter][] that, unless specifically set to `false`, will add a TOC to any page with a `.WordCount` (see [Page Variables][pagevars]) greater than 400. This example also demonstrates how to use [conditionals][] in your templating:
|
||||
|
||||
{{% code file="layouts/partials/toc.html" download="toc.html" %}}
|
||||
```html
|
||||
{{ if and (gt .WordCount 400 ) (ne .Params.toc "false") }}
|
||||
<aside>
|
||||
<header>
|
||||
<h2>{{.Title}}</h2>
|
||||
</header>
|
||||
{{.TableOfContents}}
|
||||
</aside>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% note %}}
|
||||
With the preceding example, even pages with > 400 words *and* `toc` not set to `false` will not render a table of contents if there are no headings in the page for the `{{.TableOfContents}}` variable to pull from.
|
||||
{{% /note %}}
|
||||
|
||||
[conditionals]: /templates/introduction/#conditionals
|
||||
[front matter]: /content-management/table-of-contents/
|
||||
[pagevars]: /variables/page/
|
||||
[partials]: /templates/partials/
|
||||
[single page template]: /templates/single-page-templates/
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: Content Types
|
||||
linktitle: Types
|
||||
description: Hugo provides support for sites with multiple content types and assumes your site will be organized into sections, where each section will use the corresponding type.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [content management]
|
||||
tags: [lists,sections,content types,types,organization]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 60
|
||||
weight: 60 #rem
|
||||
draft: false
|
||||
aliases: [/content/types]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo provides full support for sites with multiple content types. A **content type** can have a unique set of metadata (i.e., [front matter][]) or customized [template][] and can be created by the `hugo new` command via [archetypes][].
|
||||
|
||||
## What is a Content Type
|
||||
|
||||
[Tumblr][] is a good example of a website with multiple content types. A piece of "content" could be a photo, quote, or a post, each with different sets of metadata and different visual rendering.
|
||||
|
||||
## Assigning a Content Type
|
||||
|
||||
Hugo assumes that your site will be organized into [sections][] and each section will use a corresponding type. This is to reduce the amount of configuration necessary for new Hugo projects.
|
||||
|
||||
If you are taking advantage of this default behavior, each new piece of content you place into a section will automatically inherit the type. Therefore a new file created at `content/posts/new-post.md` will automatically be assigned the type `posts`. Alternatively, you can set the content type in a content file's [front matter][] in the field "`type`".
|
||||
|
||||
## Creating New Content of a Specific Type
|
||||
|
||||
You can manually add files to your content directories, but Hugo has the ability to create and populate a new content file with preconfigured front matter via [archetypes][].
|
||||
|
||||
## Defining a Content Type
|
||||
|
||||
Creating a new content type is easy in Hugo. You simply define and provide the templates and archetype unique to your new content type. Hugo will fall back to using the general templates and default archetype whenever a specific file is not present.
|
||||
|
||||
{{% note "Declaring Content Types" %}}
|
||||
Remember, all of the following are *optional*. If you do not specifically declare content types in your front matter or develop specific layouts for content types, Hugo is smart enough to assume the content type from the file path and section. (See [Content Sections](/content-management/sections/) for more information.)
|
||||
{{% /note %}}
|
||||
|
||||
The following examples take you stepwise through creating a new type layout for a content file that contains the following front matter:
|
||||
|
||||
{{% code file="content/events/my-first-event.md" copy="false" %}}
|
||||
```toml
|
||||
+++
|
||||
title = My First Event
|
||||
date = "2016-06-24T19:20:04-07:00"
|
||||
description = "Today is my 36th birthday. How time flies."
|
||||
type = "event"
|
||||
layout = "birthday"
|
||||
+++
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
By default, Hugo assumes `*.md` under `events` is of the `events` content type. However, we have specified that this particular file at `content/events/ my-first-event.md` is of type `event` and should render using the `birthday` layout.
|
||||
|
||||
### Create a Type Layout Directory
|
||||
|
||||
Create a directory with the name of the type in `/layouts`. For creating these custom layouts, **type is always singular**; e.g., `events => event` and `posts => post`.
|
||||
|
||||
For this example, you need to create `layouts/event/birthday.html`.
|
||||
|
||||
{{% note %}}
|
||||
If you have multiple content files in your `events` directory that are of the `special` type and you don't want to define the `layout` specifically for each piece of content, you can create a layout at `layouts/special/single.html` to observe the [single page template lookup order](/templates/single-page-templates/).
|
||||
{{% /note %}}
|
||||
|
||||
{{% warning %}}
|
||||
With the "everything is a page" data model introduced in v0.18 (see [Content Organization](/content-management/organization/)), you can use `_index.md` in content directories to add both content and front matter to [list pages](/templates/lists/). However, `type` and `layout` declared in the front matter of `_index.md` are *not* currently respected at build time as of v0.19. This is a known issue [(#3005)](https://github.com/spf13/hugo/issues/3005).
|
||||
{{% /warning %}}
|
||||
|
||||
### Create Views
|
||||
|
||||
Many sites support rendering content in a few different ways; e.g., a single page view and a summary view to be used when displaying a [list of section contents][sectiontemplates].
|
||||
|
||||
Hugo limits assumptions about how you want to display your content to an intuitive set of sane defaults and will support as many different views of a content type as your site requires. All that is required for these additional views is that a template exists in each `/layouts/<TYPE>` directory with the same name.
|
||||
|
||||
### Custom Content Type Template Lookup Order
|
||||
|
||||
The lookup order for the `content/events/my-first-event.md` templates would be as follows:
|
||||
|
||||
* `layouts/event/birthday.html`
|
||||
* `layouts/event/single.html`
|
||||
* `layouts/events/single.html`
|
||||
* `layouts/_default/single.html`
|
||||
|
||||
### Create a Corresponding Archetype
|
||||
|
||||
We can then create a custom archetype with preconfigured front matter at `event.md` in the `/archetypes` directory; i.e. `archetypes/event.md`.
|
||||
|
||||
Read [Archetypes][archetypes] for more information on archetype usage with `hugo new`.
|
||||
|
||||
[archetypes]: /content-management/archetypes/
|
||||
[front matter]: /content-management/front-matter/
|
||||
[sectiontemplates]: /templates/section-templates/
|
||||
[sections]: /content-management/sections/
|
||||
[template]: /templates/
|
||||
[Tumblr]: https://www.tumblr.com/
|
||||
@@ -0,0 +1,286 @@
|
||||
---
|
||||
title: URL Management
|
||||
linktitle: URL Management
|
||||
description: Hugo provides native support for permalinks, aliases, link canonicalization, and multiple options for handling relative vs absolute URLs.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-03-09
|
||||
tags: [aliases,redirects,permalinks,urls]
|
||||
categories: [content management]
|
||||
menu:
|
||||
docs:
|
||||
parent: "content-management"
|
||||
weight: 110
|
||||
weight: 110 #rem
|
||||
draft: false
|
||||
aliases: [/extras/permalinks/,/extras/aliases/,/extras/urls/,/doc/redirects/,/doc/alias/,/doc/aliases/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Permalinks
|
||||
|
||||
The default Hugo target directory for your built website is `public/`. However, you can change this value by specifying a different `publishdir` in your [site configuration][config]. The directories created at build time for a section reflect the position of the content's directory within the `content` folder and namespace matching its layout within the `contentdir` hierarchy.
|
||||
|
||||
The `permalinks` option in your [site configuration][config] allows you to adjust the directory paths (i.e., the URLs) on a per-section basis. This will change where the files are written to and will change the page's internal "canonical" location, such that template references to `.RelPermalink` will honor the adjustments made as a result of the mappings in this option.
|
||||
|
||||
{{% note "Default Publish and Content Folders" %}}
|
||||
These examples use the default values for `publishDir` and `contentDir`; i.e., `publish` and `content`, respectively. You can override the default values in your [site's `config` file](/getting-started/configuration/).
|
||||
{{% /note %}}
|
||||
|
||||
For example, if one of your [sections][] is called `post` and you want to adjust the canonical path to be hierarchical based on the year, month, and post title, you could set up the following configurations in YAML and TOML, respectively.
|
||||
|
||||
### YAML Permalinks Configuration Example
|
||||
|
||||
{{% code file="config.yml" copy="false" %}}
|
||||
```yaml
|
||||
permalinks:
|
||||
post: /:year/:month/:title/
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
### TOML Permalinks Configuration Example
|
||||
|
||||
{{% code file="config.toml" copy="false" %}}
|
||||
```toml
|
||||
[permalinks]
|
||||
post = "/:year/:month/:title/"
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Only the content under `post/` will have the new URL structure. For example, the file `content/post/sample-entry.md` with `date: 2017-02-27T19:20:00-05:00` in its front matter will render to `public/2017/02/sample-entry/index.html` at build time and therefore be reachable at `http://yoursite.com/2013/11/sample-entry/`.
|
||||
|
||||
### Permalink Configuration Values
|
||||
|
||||
The following is a list of values that can be used in a `permalink` definition in your site `config` file. All references to time are dependent on the content's date.
|
||||
|
||||
`:year`
|
||||
: the 4-digit year
|
||||
|
||||
`:month`
|
||||
: the 2-digit month
|
||||
|
||||
`:monthname`
|
||||
: the name of the month
|
||||
|
||||
`:day`
|
||||
: the 2-digit day
|
||||
|
||||
`:weekday`
|
||||
: the 1-digit day of the week (Sunday = 0)
|
||||
|
||||
`:weekdayname`
|
||||
: the name of the day of the week
|
||||
|
||||
`:yearday`
|
||||
: the 1- to 3-digit day of the year
|
||||
|
||||
`:section`
|
||||
: the content's section
|
||||
|
||||
`:title`
|
||||
: the content's title
|
||||
|
||||
`:slug`
|
||||
: the content's slug (or title if no slug is provided in the front matter)
|
||||
|
||||
`:filename`
|
||||
: the content's filename (without extension)
|
||||
|
||||
## Aliases
|
||||
|
||||
For people migrating existing published content to Hugo, there's a good chance you need a mechanism to handle redirecting old URLs.
|
||||
|
||||
Luckily, redirects can be handled easily with **aliases** in Hugo.
|
||||
|
||||
### Example: Aliases
|
||||
|
||||
Let's assume you create a new piece of content at `content/posts/my-awesome-blog-post.md`. The content is a revision of your previous post at `content/posts/my-original-url.md`. You can create an `aliases` field in the front matter of your new `my-awesome-blog-post.md` where you can add previous paths. The following examples show how to create this filed in TOML and YAML front matter, respectively.
|
||||
|
||||
#### TOML Front Matter
|
||||
|
||||
{{% code file="content/posts/my-awesome-post.md" copy="false" %}}
|
||||
```toml
|
||||
+++
|
||||
aliases = [
|
||||
"/posts/my-original-url/",
|
||||
"/2010/01/01/even-earlier-url.html"
|
||||
]
|
||||
+++
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### YAML Front Matter
|
||||
|
||||
{{% code file="content/posts/my-awesome-post.md" copy="false" %}}
|
||||
```yaml
|
||||
---
|
||||
aliases:
|
||||
- /posts/my-original-url/
|
||||
- /2010/01/01/even-earlier-url.html
|
||||
---
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Now when you visit any of the locations specified in aliases---i.e., *assuming the same site domain*---you'll be redirected to the page they are specified on. For example, a visitor to `yoursite.com/posts/my-original-url/` will be immediately redirected to `yoursite.com/posts/my-awesome-blog-post/`.
|
||||
|
||||
### Example: Aliases in Multilingual
|
||||
|
||||
On [multilingual sites][multilingual], each translation of a post can have unique aliases. To use the same alias across multiple languages, prefix it with the language code.
|
||||
|
||||
In `/posts/my-new-post.es.md`:
|
||||
|
||||
```yaml
|
||||
---
|
||||
aliases:
|
||||
- /es/posts/my-original-post/
|
||||
---
|
||||
```
|
||||
|
||||
### How Hugo Aliases Work
|
||||
|
||||
When aliases are specified, Hugo creates a directory to match the alias entry. Inside the directory, Hugo creates an `.html` file specifying the canonical URL for the page and the new redirect target.
|
||||
|
||||
For example, a content file at `posts/my-intended-url.md` with the following in the front matter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: My New post
|
||||
aliases: [/posts/my-old-url/]
|
||||
---
|
||||
```
|
||||
|
||||
Assuming a `baseURL` of `yoursite.com`, the contents of the auto-generated alias `.html` found at `https://yoursite.com/posts/my-old-url/ will contain the following:`
|
||||
|
||||
```html
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>http://yoursite.com/posts/my-intended-url</title>
|
||||
<link rel="canonical" href="http://yoursite.com/posts/my-intended-url"/>
|
||||
<meta name=\"robots\" content=\"noindex\">
|
||||
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
|
||||
<meta http-equiv="refresh" content="0; url=http://yoursite.com/posts/my-intended-url"/>
|
||||
</head>
|
||||
</html>
|
||||
```
|
||||
|
||||
The `http-equiv="refresh"` line is what performs the redirect, in 0 seconds in this case. If an end user of your website goes to `https://yoursite.com/posts/my-old-url`, they will now be automatically redirected to the newer, correct URL. The addition of `<meta name=\"robots\" content=\"noindex\">` lets search engine bots know they they should not crawl and index your new alias page.
|
||||
|
||||
### Customizing
|
||||
|
||||
You may customize this alias page by creating an `alias.html` template in the
|
||||
layouts folder of your site (i.e., `layouts/alias.html`). In this case, the data passed to the template is
|
||||
|
||||
`Permalink`
|
||||
: the link to the page being aliased
|
||||
|
||||
`Page`
|
||||
: the Page data for the page being aliased
|
||||
|
||||
### Important Behaviors of Aliases
|
||||
|
||||
1. Hugo makes no assumptions about aliases. They also do not change based
|
||||
on your UglyURLs setting. You need to provide absolute paths to your web root
|
||||
and the complete filename or directory.
|
||||
2. Aliases are rendered *before* any content are rendered and therefore will be overwritten by any content with the same location.
|
||||
|
||||
## Pretty URLs
|
||||
|
||||
Hugo's default behavior is to render your content with "pretty" URLs. No non-standard server-side configuration is required for these pretty URLs to work.
|
||||
|
||||
The following demonstrates the concept:
|
||||
|
||||
```bash
|
||||
content/posts/_index.md
|
||||
=> yoursite.com/posts/index.html
|
||||
content/posts/post-1.md
|
||||
=> yoursite.com/posts/post-1/
|
||||
```
|
||||
|
||||
## Ugly URLs
|
||||
|
||||
If you would like to have are often referred to as "ugly URLs" (e.g., yoursite.com/urls.html), set `uglyurls = true` or `uglyurls: true` in your site's `config.toml` or `config.yaml`, respectively. You can also use the `--uglyURLs=true` [flag from the command line][usage] with `hugo` or `hugo server`..
|
||||
|
||||
If you want a specific piece of content to have an exact URL, you can specify this in the [front matter][] under the `url` key. The following are examples of the same content directory and what the eventual URL structure will be when Hugo runs with its default behavior.
|
||||
|
||||
See [Content Organization][contentorg] for more details on paths.
|
||||
|
||||
```bash
|
||||
.
|
||||
└── content
|
||||
└── about
|
||||
| └── _index.md // <- http://yoursite.com/about/
|
||||
├── post
|
||||
| ├── firstpost.md // <- http://yoursite.com/post/firstpost/
|
||||
| ├── happy
|
||||
| | └── ness.md // <- http://yoursite.com/post/happy/ness/
|
||||
| └── secondpost.md // <- http://yoursite.com/post/secondpost/
|
||||
└── quote
|
||||
├── first.md // <- http://yoursite.com/quote/first/
|
||||
└── second.md // <- http://yoursite.com/quote/second/
|
||||
```
|
||||
|
||||
Here's the same organization run with `hugo --uglyURLs`:
|
||||
|
||||
```bash
|
||||
.
|
||||
└── content
|
||||
└── about
|
||||
| └── _index.md // <- http://yoursite.com/about/index.html
|
||||
├── post
|
||||
| ├── firstpost.md // <- http://yoursite.com/post/firstpost.html
|
||||
| ├── happy
|
||||
| | └── ness.md // <- http://yoursite.com/post/happy/ness.html
|
||||
| └── secondpost.md // <- http://yoursite.com/post/secondpost.html
|
||||
└── quote
|
||||
├── first.md // <- http://yoursite.com/quote/first.html
|
||||
└── second.md // <- http://yoursite.com/quote/second.html
|
||||
```
|
||||
|
||||
|
||||
## Canonicalization
|
||||
|
||||
By default, all relative URLs encountered in the input are left unmodified, e.g. `/css/foo.css` would stay as `/css/foo.css`. The `canonifyURLs` field in your site `config` has a default value of `false`.
|
||||
|
||||
By setting `canonifyURLs` to `true`, all relative URLs would instead be *canonicalized* using `baseURL`. For example, assuming you have `baseURL = https://yoursite.com/`, the relative URL `/css/foo.css` would be turned into the absolute URL `http://yoursite.com/css/foo.css`.
|
||||
|
||||
Benefits of canonicalization include fixing all URLs to be absolute, which may aid with some parsing tasks. Note, however, that all modern browsers handle this on the client without issue.
|
||||
|
||||
Benefits of non-canonicalization include being able to have scheme-relative resource inclusion; e.g., so that `http` vs `https` can be decided according to how the page was retrieved.
|
||||
|
||||
{{% note "`canonifyURLs` default change" %}}
|
||||
In the May 2014 release of Hugo v0.11, the default value of `canonifyURLs` was switched from `true` to `false`, which we think is the better default and should continue to be the case going forward. Please verify and adjust your website accordingly if you are upgrading from v0.10 or older versions.
|
||||
{{% /note %}}
|
||||
|
||||
To find out the current value of `canonifyURLs` for your website, you may use the handy `hugo config` command added in v0.13.
|
||||
|
||||
```bash
|
||||
hugo config | grep -i canon
|
||||
```
|
||||
|
||||
Or, if you are on Windows and do not have `grep` installed:
|
||||
|
||||
```
|
||||
hugo config | FINDSTR /I canon
|
||||
```
|
||||
|
||||
## Overriding URLS with Front Matter
|
||||
|
||||
In addition to specifying permalink values in your site configuration for different content sections, Hugo provides even more granular control for individual pieces of content.
|
||||
|
||||
Both `slug` and `url` can be defined in individual front matter. For more information on content destinations at build time, see [Content Organization][contentorg].
|
||||
|
||||
## Relative URLs
|
||||
|
||||
By default, all relative URLs are left unchanged by Hugo, which can be problematic when you want to make your site browsable from a local file system.
|
||||
|
||||
Setting `relativeURLs` to `true` in your [site configuration][config] will cause Hugo to rewrite all relative URLs to be relative to the current content.
|
||||
|
||||
For example, if your `/post/first/` page contains a link to `/about/`, Hugo will rewrite the URL to `../../about/`.
|
||||
|
||||
[config]: /getting-started/configuration/
|
||||
[contentorg]: /content-management/organization/
|
||||
[front matter]: /content-management/front-matter/
|
||||
[multilingual]: /content-management/multilingual/
|
||||
[sections]: /content-management/sections/
|
||||
[usage]: /getting-started/usage/
|
||||
@@ -1,330 +0,0 @@
|
||||
---
|
||||
lastmod: 2016-10-01
|
||||
date: 2014-05-14T02:13:50Z
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
next: /content/ordering
|
||||
prev: /content/types
|
||||
title: Archetypes
|
||||
weight: 50
|
||||
toc: true
|
||||
---
|
||||
|
||||
Typically, each piece of content you create within a Hugo project will have [front matter](/content/front-matter/) that follows a consistent structure. If you write blog posts, for instance, you might use the following front matter for the vast majority of those posts:
|
||||
|
||||
```toml
|
||||
+++
|
||||
title = ""
|
||||
date = ""
|
||||
slug = ""
|
||||
tags = [
|
||||
""
|
||||
]
|
||||
categories = [
|
||||
""
|
||||
]
|
||||
draft = true
|
||||
+++
|
||||
```
|
||||
|
||||
You can always add non-typical front matter to any piece of content, but since it takes extra work to develop a theme that handles unique metadata, consistency is simpler.
|
||||
|
||||
With this in mind, Hugo has a convenient feature known as *archetypes* that allows users to define default front matter for new pieces of content.
|
||||
|
||||
By using archetypes, we can:
|
||||
|
||||
1. **Save time**. Stop writing the same front matter over and over again.
|
||||
2. **Avoid errors**. Reduce the odds of typos, improperly formatted syntax, and other simple mistakes.
|
||||
3. **Focus on more important things**. Avoid having to remember all of the fields that need to be associated with each piece of content. (This is particularly important for larger projects with complex front matter and a variety of content types.)
|
||||
|
||||
Let's explore how they work.
|
||||
|
||||
## Built-in Archetypes
|
||||
|
||||
If you've been using Hugo for a while, there's a decent chance you've come across archetypes without even realizing it. This is because Hugo includes a basic, built-in archetype that is used by default whenever it generates a content file.
|
||||
|
||||
To see this in action, open the command line, navigate into your project's directory, and run the following command:
|
||||
|
||||
```bash
|
||||
hugo new hello-world.md
|
||||
```
|
||||
|
||||
This `hugo new` command creates a new content file inside the project's `content` directory — in this case, a file named `hello-world.md` — and if you open this file, you'll notice it contains the following front matter:
|
||||
|
||||
```toml
|
||||
+++
|
||||
date = "2017-05-31T15:18:11+10:00"
|
||||
draft = true
|
||||
title = "hello world"
|
||||
+++
|
||||
```
|
||||
|
||||
Here, we can see that three fields have been added to the document: a `title` field that is based on the file name we defined, a `draft` field that ensures this content won't be published by default, and a `date` field that is auto-populated with the current date and time in the [RFC 3339](https://stackoverflow.com/questions/522251/whats-the-difference-between-iso-8601-and-rfc-3339-date-formats) format.
|
||||
|
||||
This, in its most basic form, is an example of an archetype. To understand how useful they can be though, it's best if we create our own.
|
||||
|
||||
## Creating Archetypes
|
||||
|
||||
In this section, we're going to create an archetype that will override the built-in archetype, allowing us to define custom front matter that will be included in any content files that we generate with the `hugo new` command.
|
||||
|
||||
To achieve this, create a file named `default.md` inside the `archetypes` folder of a Hugo project. (If the folder doesn't exist, create it.)
|
||||
|
||||
Then, inside this file, define the following front matter:
|
||||
|
||||
```toml
|
||||
+++
|
||||
slug = ""
|
||||
tags = []
|
||||
categories = []
|
||||
draft = true
|
||||
+++
|
||||
```
|
||||
|
||||
You'll notice that we haven't defined a `title` or `date` field. This is because Hugo will automatically add these fields to the beginning of the front matter. We do, however, need to define the `draft` field if we want it to exist in our front matter.
|
||||
|
||||
You'll also notice that we're writing the front matter in the TOML format. It's possible to define archetype front matter in other formats, but a setting needs to be changed in the configuration file for this to be possible. See the "[Archetype Formats](#archetype-formats)" section of this article for more details.
|
||||
|
||||
Next, run the following command:
|
||||
|
||||
```bash
|
||||
hugo new my-archetype-example.md
|
||||
```
|
||||
|
||||
This command will generate a file named `my-archetype-example.md` inside the `content` directory, and this file will contain the following output:
|
||||
|
||||
```toml
|
||||
+++
|
||||
categories = []
|
||||
date = "2017-05-31T15:21:13+10:00"
|
||||
draft = true
|
||||
slug = ""
|
||||
tags = []
|
||||
title = "my archetype example"
|
||||
+++
|
||||
```
|
||||
|
||||
As we can see, the file contains the `title` and `date` property that Hugo created for us, along with the front matter that we defined in the `archetypes/default.md` file.
|
||||
|
||||
You'll also notice that the fields have been sorted into alphabetical order. This is an unintentional side-effect that stems from the underlying code libraries that Hugo relies upon. It is, however, [a known issue that is actively being discussed](https://github.com/gohugoio/hugo/issues/452).
|
||||
|
||||
## Section Archetypes
|
||||
|
||||
By creating the `archetypes/default.md` file, we've created a default archetype that is more useful than the built-in archetype, but since Hugo encourages us to [organize our content into sections](/content/sections/), each of which will likely have different front matter requirements, a "one-size-fits-all" archetype isn't necessarily the best approach.
|
||||
|
||||
To accommodate for this, Hugo allows us to create archetypes for each section of our project. This means, whenever we generate content for a certain section, the appropriate front matter for that section will be automatically included in the generated file.
|
||||
|
||||
To see this in action, create a "photo" section by creating a directory named "photo" inside the `content` directory.
|
||||
|
||||
Then create a file named `photo.md` inside the `archetypes` directory and include the following front matter inside this file:
|
||||
|
||||
```toml
|
||||
+++
|
||||
image_url = ""
|
||||
camera = ""
|
||||
lens = ""
|
||||
aperture = ""
|
||||
iso = ""
|
||||
draft = true
|
||||
+++
|
||||
```
|
||||
|
||||
Here, the critical detail is that the `photo.md` file in the `archetypes` directory is named after the `photo` section that we just created. By sharing a name, Hugo can understand that there's a relationship between them.
|
||||
|
||||
Next, run the following command:
|
||||
|
||||
```bash
|
||||
hugo new photo/my-pretty-cat.md
|
||||
```
|
||||
|
||||
This command will generate a file named `my-pretty-cat.md` inside the `content/photo` directory, and this file will contain the following output:
|
||||
|
||||
```toml
|
||||
+++
|
||||
aperture = ""
|
||||
camera = ""
|
||||
date = "2017-05-31T15:25:18+10:00"
|
||||
draft = true
|
||||
image_url = ""
|
||||
iso = ""
|
||||
lens = ""
|
||||
title = "my pretty cat"
|
||||
+++
|
||||
```
|
||||
|
||||
As we can see, the `title` and `date` fields are still included by Hugo, but the rest of the front matter is being generated from the `photo.md` archetype instead of the `default.md` archetype.
|
||||
|
||||
### Tip: Default Values
|
||||
|
||||
To make archetypes more useful, define default values for any fields that will always be set to a range of limited options. In the case of the `photo.md` archetype, for instance, you could include lists of the various cameras and lenses that you own:
|
||||
|
||||
```toml
|
||||
+++
|
||||
image_url = ""
|
||||
camera = [
|
||||
"Sony RX100 Mark IV",
|
||||
"Canon 5D Mark III",
|
||||
"iPhone 6S"
|
||||
]
|
||||
lens = [
|
||||
"Canon EF 50mm f/1.8",
|
||||
"Rokinon 14mm f/2.8"
|
||||
]
|
||||
aperture = ""
|
||||
iso = ""
|
||||
draft = true
|
||||
+++
|
||||
```
|
||||
|
||||
Then, after generating a content file, simply remove the values that aren't relevant. This saves you from typing out the same options over and over again while ensuring consistency in how they're written.
|
||||
|
||||
## Scaffolding Content
|
||||
|
||||
Archetypes aren't limited to defining default front matter. They can also be used to define a default structure for the body of Markdown documents.
|
||||
|
||||
For example, imagine creating a `review.md` archetype for the purpose of writing camera reviews. This is what the front matter for such an archetype might look like:
|
||||
|
||||
```toml
|
||||
+++
|
||||
manufacturer = ""
|
||||
model = ""
|
||||
price = ""
|
||||
releaseDate = ""
|
||||
rating = ""
|
||||
+++
|
||||
```
|
||||
|
||||
But reviews tend to follow strict formats and need to answer specific questions, and it's with these expectations of precise structure that archetypes can prove to be even more useful.
|
||||
|
||||
For the sake of writing reviews, for instance, we could define the structure of a review beneath the front matter of the `review.md` file:
|
||||
|
||||
```markdown
|
||||
+++
|
||||
manufacturer = ""
|
||||
model = ""
|
||||
price = ""
|
||||
releaseDate = ""
|
||||
rating = ""
|
||||
+++
|
||||
|
||||
## Introduction
|
||||
|
||||
## Sample Photos
|
||||
|
||||
## Conclusion
|
||||
```
|
||||
|
||||
Then, whenever we use the `hugo new` command to create a new review, not only will the default front matter be copied into the newly created Markdown document, but the body of the `review.md` archetype will also be copied.
|
||||
|
||||
To take this further though — and to ensure authors on multi-author websites are on the same page about how content should be written — we could include notes and reminders within the archetype:
|
||||
|
||||
```markdown
|
||||
+++
|
||||
manufacturer = ""
|
||||
model = ""
|
||||
price = ""
|
||||
releaseDate = ""
|
||||
rating = ""
|
||||
+++
|
||||
|
||||
## Introduction
|
||||
|
||||
<!--
|
||||
What is the selling point of the camera?
|
||||
What has changed since last year's model?
|
||||
Include a bullet-point list of key features.
|
||||
-->
|
||||
|
||||
## Sample Photos
|
||||
|
||||
<!-- TODO: Take at least 12 photos in a variety of situations. -->
|
||||
|
||||
## Conclusion
|
||||
|
||||
<!--
|
||||
Is this camera worth the money?
|
||||
Does it accomplish what it set out to achieve?
|
||||
Are there any specific groups of people who should/shouldn't buy it?
|
||||
Would you recommend it to a friend?
|
||||
Are there alternatives on the horizon?
|
||||
-->
|
||||
|
||||
```
|
||||
|
||||
That way, each time we generate a new content file, we have a series of handy notes to push us closer to a piece of writing that's suitable for publishing.
|
||||
|
||||
(If you're wondering why the notes are wrapped in the HTML comment syntax, it's to ensure they won't appear inside the preview window of whatever Markdown editor the author happens to be using. They're not strictly necessary though.)
|
||||
|
||||
This is still a fairly simple example, but if your content usually contains a variety of components — headings, bullet-points, images, [short-codes](/extras/shortcodes/), etc — it's not hard to see the time-saving benefits of placing these components in the body of an archetype file.
|
||||
|
||||
## Theme Archetypes
|
||||
|
||||
Whenever you generate a content file with the `hugo new` command, Hugo will start by searching for archetypes in the `archetypes` directory, initially looking for an archetype that matches the content's section and falling-back on the `default.md` archetype (if one is present). If no archetypes are found in this directory, Hugo will continue its search in the `archetypes` directory of the currently active theme. In other words, it's possible for themes to come packaged with their own archetypes, ensuring that users of that theme format their content files with correctly structured front matter.
|
||||
|
||||
To allow Hugo to use archetypes from a theme, [that theme must be activated via the project's configuration file](/themes/usage/):
|
||||
|
||||
```toml
|
||||
theme = "ThemeNameGoesHere"
|
||||
```
|
||||
|
||||
If an archetype doesn't exist in the `archetypes` directory at the top-level of a project or inside the `archetypes` directory of an active theme, the built-in archetype will be used.
|
||||
|
||||
{{< figure src="/img/content/archetypes/archetype-hierarchy.png" alt="How Hugo Decides Which Archetype To Use" >}}
|
||||
|
||||
## Archetype Formats
|
||||
|
||||
By default, the `hugo new` command will generate front matter in the TOML format. This means, even if we define the front matter in our archetype files as YAML or JSON, it will be converted to the TOML format before it ends up in our content files.
|
||||
|
||||
Fortunately, this functionality can be overwritten.
|
||||
|
||||
Inside the project's configuration file, simply define a `metaDataFormat` property:
|
||||
|
||||
```toml
|
||||
metaDataFormat = ""
|
||||
```
|
||||
|
||||
Then set this property to any of the following values:
|
||||
|
||||
* toml
|
||||
* yaml
|
||||
* json
|
||||
|
||||
By defining this option, any front matter will be generated in your preferred format.
|
||||
|
||||
It's worth noting, however, that when generating front matter in the TOML format, you might encounter the following error:
|
||||
|
||||
```bash
|
||||
Error: cannot convert type <nil> to TomlTree
|
||||
```
|
||||
|
||||
This is because, to generate TOML, all of the fields in the front matter need to have a default value, even if that default value is just an empty string.
|
||||
|
||||
For example, this YAML would *not* successfully compile into the TOML format:
|
||||
|
||||
```yaml
|
||||
---
|
||||
slug:
|
||||
tags:
|
||||
categories:
|
||||
draft:
|
||||
---
|
||||
```
|
||||
|
||||
But this YAML *would* successfully compile:
|
||||
|
||||
```yaml
|
||||
---
|
||||
slug: ""
|
||||
tags:
|
||||
-
|
||||
categories:
|
||||
-
|
||||
draft: true
|
||||
---
|
||||
```
|
||||
|
||||
It's a subtle yet important detail to remember.
|
||||
|
||||
## Notes
|
||||
|
||||
* Prior to Hugo v0.13, some users received [an "EOF" error when using archetypes](https://github.com/gohugoio/hugo/issues/776), related to what text editor they used to create the archetype. As of Hugo v0.13, this error has been [resolved](https://github.com/gohugoio/hugo/pull/785).
|
||||
@@ -1,119 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/front-matter/
|
||||
lastmod: 2015-12-23
|
||||
date: 2013-07-01
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
next: /content/sections
|
||||
prev: /content/organization
|
||||
title: Front Matter
|
||||
weight: 20
|
||||
toc: true
|
||||
---
|
||||
|
||||
The **front matter** is one of the features that gives Hugo its strength. It enables
|
||||
you to include the meta data of the content right with it. Hugo supports a few
|
||||
different formats, each with their own identifying tokens.
|
||||
|
||||
Supported formats:
|
||||
|
||||
* **[TOML][]**, identified by '`+++`'.
|
||||
* **[YAML][]**, identified by '`---`'.
|
||||
* **[JSON][]**, a single JSON object which is surrounded by '`{`' and '`}`', followed by a newline.
|
||||
|
||||
[TOML]: https://github.com/toml-lang/toml "Tom's Obvious, Minimal Language"
|
||||
[YAML]: http://www.yaml.org/ "YAML Ain't Markup Language"
|
||||
[JSON]: http://www.json.org/ "JavaScript Object Notation"
|
||||
|
||||
## TOML Example
|
||||
|
||||
<pre><code class="language-toml">+++
|
||||
title = "spf13-vim 3.0 release and new website"
|
||||
description = "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
|
||||
tags = [ ".vimrc", "plugins", "spf13-vim", "vim" ]
|
||||
date = "2012-04-06"
|
||||
categories = [
|
||||
"Development",
|
||||
"VIM"
|
||||
]
|
||||
slug = "spf13-vim-3-0-release-and-new-website"
|
||||
+++
|
||||
</code><code class="language-markdown">Content of the file goes Here
|
||||
</code></pre>
|
||||
|
||||
## YAML Example
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: "spf13-vim 3.0 release and new website"
|
||||
description: "spf13-vim is a cross platform distribution of vim plugins and resources for Vim."
|
||||
tags: [ ".vimrc", "plugins", "spf13-vim", "vim" ]
|
||||
lastmod: 2015-12-23
|
||||
date: "2012-04-06"
|
||||
categories:
|
||||
- "Development"
|
||||
- "VIM"
|
||||
slug: "spf13-vim-3-0-release-and-new-website"
|
||||
---
|
||||
|
||||
Content of the file goes Here
|
||||
```
|
||||
|
||||
## JSON Example
|
||||
|
||||
```json
|
||||
{
|
||||
"title": "spf13-vim 3.0 release and new website",
|
||||
"description": "spf13-vim is a cross platform distribution of vim plugins and resources for Vim.",
|
||||
"tags": [ ".vimrc", "plugins", "spf13-vim", "vim" ],
|
||||
"date": "2012-04-06",
|
||||
"categories": [
|
||||
"Development",
|
||||
"VIM"
|
||||
],
|
||||
"slug": "spf13-vim-3-0-release-and-new-website"
|
||||
}
|
||||
|
||||
Content of the file goes Here
|
||||
```
|
||||
|
||||
## Variables
|
||||
|
||||
There are a few predefined variables that Hugo is aware of and utilizes. The user can also create
|
||||
any variable they want. These will be placed into the `.Params` variable available to the templates.
|
||||
Field names are always normalized to lowercase (e.g. `camelCase: true` is available as `.Params.camelcase`).
|
||||
|
||||
### Required variables
|
||||
|
||||
* **title** The title for the content
|
||||
* **description** The description for the content
|
||||
* **date** The date the content will be sorted by
|
||||
* **taxonomies** These will use the field name of the plural form of the index (see tags and categories above)
|
||||
|
||||
### Optional variables
|
||||
|
||||
* **aliases** An array of one or more aliases
|
||||
(e.g. old published path of a renamed content)
|
||||
that would be created to redirect to this content.
|
||||
See [Aliases]({{< relref "extras/aliases.md" >}}) for details.
|
||||
* **draft** If true, the content will not be rendered unless `hugo` is called with `--buildDrafts`
|
||||
* **publishdate** If in the future, content will not be rendered unless `hugo` is called with `--buildFuture`
|
||||
* **expirydate** Content already expired will not be rendered unless `hugo` is called with `--buildExpired`
|
||||
* **type** The type of the content (will be derived from the directory automatically if unset)
|
||||
* **isCJKLanguage** If true, explicitly treat the content as CJKLanguage (`.Summary` and `.WordCount` can work properly in CJKLanguage)
|
||||
* **weight** Used for sorting
|
||||
* **markup** *(Experimental)* Specify `"rst"` for reStructuredText (requires
|
||||
`rst2html`) or `"md"` (default) for Markdown
|
||||
* **slug** appears as tail of the url. It can be used to change the part of the url that is based on the filename.
|
||||
* **url** The full path to the content from the web root. It makes no assumptions about the path of the content file. It also ignores any language prefixes of the multilingual feature.
|
||||
|
||||
*If neither `slug` or `url` is present, the filename will be used.*
|
||||
|
||||
## Configure Blackfriday rendering
|
||||
|
||||
It's possible to set some options for Markdown rendering in the page's front matter as an override to the site wide configuration.
|
||||
|
||||
See [Configuration]({{< ref "overview/configuration.md#configure-blackfriday-rendering" >}}) for more.
|
||||
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-12-23
|
||||
date: 2014-03-06
|
||||
linktitle: Ordering
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
next: /content/summaries
|
||||
prev: /content/archetypes
|
||||
title: Ordering Content
|
||||
weight: 60
|
||||
---
|
||||
|
||||
Hugo provides you with all the flexibility you need to organize how your content is ordered.
|
||||
|
||||
By default, content is ordered by weight, then by date with the most
|
||||
recent date first, but alternative sorting (by `title` and `linktitle`) is
|
||||
also available. The order the content would appear is specified in
|
||||
the [list template](/templates/list/).
|
||||
|
||||
_Both the `date` and `weight` fields are optional._
|
||||
|
||||
Unweighted pages appear at the end of the list. If no weights are provided (or
|
||||
if weights are the same), `date` will be used to sort. If neither is provided,
|
||||
content will be ordered based on how it's read off the disk, and no order is
|
||||
guaranteed.
|
||||
|
||||
## Assigning weight to content
|
||||
|
||||
```toml
|
||||
+++
|
||||
weight = 4
|
||||
title = "Three"
|
||||
date = "2012-04-06"
|
||||
+++
|
||||
Front Matter with Ordered Pages 3
|
||||
```
|
||||
|
||||
## Ordering Content Within Taxonomies
|
||||
|
||||
Please see the [Taxonomy Ordering Documentation](/taxonomies/ordering/).
|
||||
@@ -1,175 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/organization/
|
||||
lastmod: 2015-09-27
|
||||
date: 2013-07-01
|
||||
linktitle: Organization
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
next: /content/supported-formats
|
||||
prev: /overview/source-directory
|
||||
title: Content Organization
|
||||
weight: 10
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo uses files (see [supported formats](/content/supported-formats/)) with headers commonly called the *front matter*. Hugo
|
||||
respects the organization that you provide for your content to minimize any
|
||||
extra configuration, though this can be overridden by additional configuration
|
||||
in the front matter.
|
||||
|
||||
## Organization
|
||||
|
||||
In Hugo, the content should be arranged in the same way they are intended for
|
||||
the rendered website. Without any additional configuration, the following will
|
||||
just work. Hugo supports content nested at any level. The top level is special
|
||||
in Hugo and is used as the [section](/content/sections/).
|
||||
|
||||
.
|
||||
└── content
|
||||
└── about
|
||||
| └── _index.md // <- http://1.com/about/
|
||||
├── post
|
||||
| ├── firstpost.md // <- http://1.com/post/firstpost/
|
||||
| ├── happy
|
||||
| | └── ness.md // <- http://1.com/post/happy/ness/
|
||||
| └── secondpost.md // <- http://1.com/post/secondpost/
|
||||
└── quote
|
||||
├── first.md // <- http://1.com/quote/first/
|
||||
└── second.md // <- http://1.com/quote/second/
|
||||
|
||||
**Here's the same organization run with `hugo --uglyURLs`**
|
||||
|
||||
.
|
||||
└── content
|
||||
└── about
|
||||
| └── _index.md // <- http://1.com/about/
|
||||
├── post
|
||||
| ├── firstpost.md // <- http://1.com/post/firstpost.html
|
||||
| ├── happy
|
||||
| | └── ness.md // <- http://1.com/post/happy/ness.html
|
||||
| └── secondpost.md // <- http://1.com/post/secondpost.html
|
||||
└── quote
|
||||
├── first.md // <- http://1.com/quote/first.html
|
||||
└── second.md // <- http://1.com/quote/second.html
|
||||
|
||||
## Destinations
|
||||
|
||||
Hugo believes that you organize your content with a purpose. The same structure
|
||||
that works to organize your source content is used to organize the rendered
|
||||
site. As displayed above, the organization of the source content will be
|
||||
mirrored in the destination.
|
||||
|
||||
Notice that the first level `about/` page URL was created using a directory
|
||||
named "about" with a single `_index.md` file inside. Find out more about `_index.md` specifically in [content for the homepage and other list pages](https://gohugo.io/overview/source-directory#content-for-home-page-and-other-list-pages).
|
||||
|
||||
There are times when one would need more control over their content. In these
|
||||
cases, there are a variety of things that can be specified in the front matter
|
||||
to determine the destination of a specific piece of content.
|
||||
|
||||
The following items are defined in order; latter items in the list will override
|
||||
earlier settings.
|
||||
|
||||
### filename
|
||||
This isn't in the front matter, but is the actual name of the file minus the
|
||||
extension. This will be the name of the file in the destination.
|
||||
|
||||
### slug
|
||||
Defined in the front matter, the `slug` can take the place of the filename for the
|
||||
destination.
|
||||
|
||||
### filepath
|
||||
The actual path to the file on disk. Destination will create the destination
|
||||
with the same path. Includes [section](/content/sections/).
|
||||
|
||||
### section
|
||||
`section` is determined by its location on disk and *cannot* be specified in the front matter. See [section](/content/sections/).
|
||||
|
||||
### type
|
||||
`type` is also determined by its location on disk but, unlike `section`, it *can* be specified in the front matter. See [type](/content/types/).
|
||||
|
||||
### path
|
||||
`path` can be provided in the front matter. This will replace the actual
|
||||
path to the file on disk. Destination will create the destination with the same
|
||||
path. Includes [section](/content/sections/).
|
||||
|
||||
### url
|
||||
A complete URL can be provided. This will override all the above as it pertains
|
||||
to the end destination. This must be the path from the baseURL (starting with a "/").
|
||||
When a `url` is provided, it will be used exactly. Using `url` will ignore the
|
||||
`--uglyURLs` setting.
|
||||
|
||||
|
||||
## Path breakdown in Hugo
|
||||
|
||||
### Content
|
||||
|
||||
. path slug
|
||||
. ⊢-------^----⊣ ⊢------^-------⊣
|
||||
content/extras/indexes/category-example/index.html
|
||||
|
||||
|
||||
. section slug
|
||||
. ⊢--^--⊣ ⊢------^-------⊣
|
||||
content/extras/indexes/category-example/index.html
|
||||
|
||||
|
||||
. section slug
|
||||
. ⊢--^--⊣⊢--^--⊣
|
||||
content/extras/indexes/index.html
|
||||
|
||||
### Destination
|
||||
|
||||
|
||||
permalink
|
||||
⊢--------------^-------------⊣
|
||||
http://spf13.com/projects/hugo
|
||||
|
||||
|
||||
baseURL section slug
|
||||
⊢-----^--------⊣ ⊢--^---⊣ ⊢-^⊣
|
||||
http://spf13.com/projects/hugo
|
||||
|
||||
|
||||
baseURL section slug
|
||||
⊢-----^--------⊣ ⊢--^--⊣ ⊢--^--⊣
|
||||
http://spf13.com/extras/indexes/example
|
||||
|
||||
|
||||
baseURL path slug
|
||||
⊢-----^--------⊣ ⊢------^-----⊣ ⊢--^--⊣
|
||||
http://spf13.com/extras/indexes/example
|
||||
|
||||
|
||||
baseURL url
|
||||
⊢-----^--------⊣ ⊢-----^-----⊣
|
||||
http://spf13.com/projects/hugo
|
||||
|
||||
|
||||
baseURL url
|
||||
⊢-----^--------⊣ ⊢--------^-----------⊣
|
||||
http://spf13.com/extras/indexes/example
|
||||
|
||||
|
||||
|
||||
**section** = which type the content is by default
|
||||
|
||||
* based on content location
|
||||
* front matter overrides
|
||||
|
||||
**slug** = name.ext or name/
|
||||
|
||||
* based on content-name.md
|
||||
* front matter overrides
|
||||
|
||||
**path** = section + path to file excluding slug
|
||||
|
||||
* based on path to content location
|
||||
|
||||
|
||||
**url** = relative URL
|
||||
|
||||
* defined in front matter
|
||||
* overrides all the above
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-12-23
|
||||
date: 2013-07-01
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
next: /content/types
|
||||
notoc: true
|
||||
prev: /content/front-matter
|
||||
title: Sections
|
||||
weight: 30
|
||||
---
|
||||
|
||||
Hugo believes that you organize your content with a purpose. The same structure
|
||||
that works to organize your source content is used to organize the rendered
|
||||
site (see [Organization](/content/organization/)). Following this pattern Hugo
|
||||
uses the top level of your content organization as **the Section**.
|
||||
|
||||
The following example site uses two sections, "post" and "quote".
|
||||
|
||||
{{< nohighlight >}}.
|
||||
└── content
|
||||
├── post
|
||||
| ├── firstpost.md // <- http://1.com/post/firstpost/
|
||||
| ├── happy
|
||||
| | └── ness.md // <- http://1.com/post/happy/ness/
|
||||
| └── secondpost.md // <- http://1.com/post/secondpost/
|
||||
└── quote
|
||||
├── first.md // <- http://1.com/quote/first/
|
||||
└── second.md // <- http://1.com/quote/second/
|
||||
{{< /nohighlight >}}
|
||||
|
||||
## Section Lists
|
||||
|
||||
Hugo will automatically create pages for each section root that list all
|
||||
of the content in that section. See [List Templates](/templates/list/)
|
||||
for details on customizing the way they appear.
|
||||
|
||||
Section pages can also have a content file and frontmatter, see [Source Organization]({{< relref "overview/source-directory.md#content-for-home-page-and-other-list-pages" >}}).
|
||||
|
||||
## Sections and Types
|
||||
|
||||
By default everything created within a section will use the content type
|
||||
that matches the section name.
|
||||
|
||||
Section defined in the front matter have the same impact.
|
||||
|
||||
To change the type of a given piece of content, simply define the type
|
||||
in the front matter.
|
||||
|
||||
If a layout for a given type hasn't been provided, a default type template will
|
||||
be used instead provided it exists.
|
||||
|
||||
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-01-27
|
||||
date: 2013-07-01
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
notoc: true
|
||||
prev: /content/ordering
|
||||
next: /content/markdown-extras
|
||||
title: Summaries
|
||||
weight: 65
|
||||
---
|
||||
|
||||
With the use of the `.Summary` [page variable](/templates/variables/), Hugo can generate summaries of content to show snippets in summary views. The summary view snippets are automatically generated by Hugo. Where a piece of content is split for the content summary depends on whether the split is Hugo-defined or user-defined.
|
||||
|
||||
Content summaries may also provide links to the original content, usually in the form of a "Read More..." link, with the help of the `.RelPermalink` or `.Permalink` variable, as well as the `.Truncated` boolean variable to determine whether such "Read More..." link is necessary.
|
||||
|
||||
## Hugo-defined: automatic summary split
|
||||
|
||||
By default, Hugo automatically takes the first 70 words of your content as its summary and stores it into the `.Summary` variable, which you may use in your templates.
|
||||
|
||||
* Pros: Automatic, no additional work on your part.
|
||||
* Cons: All HTML tags are stripped from the summary, and the first 70 words, whether they belong to a heading or to different paragraphs, are all lumped into one paragraph. Some people like it, but some people don't.
|
||||
|
||||
## User-defined: manual summary split:
|
||||
|
||||
Alternatively, you may add the <code><!--more--></code> summary divider[^1] (for org content, use <code># more</code>) where you want to split the article. Content prior to the summary divider will be used as that content's summary, and stored into the `.Summary` variable with all HTML formatting intact.
|
||||
|
||||
[^1]: The **summary divider** is also called "more tag", "excerpt separator", etc. in other literature.
|
||||
|
||||
* Pros: Freedom, precision, and improved rendering. All formatting is preserved.
|
||||
* Cons: Need to remember to type <code><!--more--></code> (or <code># more</code> for org content) in your content file. :-)
|
||||
|
||||
Be careful to enter <code><!--more--></code> (or <code># more</code> for org content) exactly, i.e. all lowercase with no whitespace, otherwise it would be treated as regular comment and ignored.
|
||||
|
||||
If there is nothing but spaces and newlines after the summary divider then `.Truncated` will be false.
|
||||
|
||||
## Showing Summaries
|
||||
|
||||
You can show content summaries with the following code. You could do this, for example, on a [list](/templates/list/) page.
|
||||
|
||||
{{ range first 10 .Data.Pages }}
|
||||
<div class="summary">
|
||||
<h4><a href="{{ .RelPermalink }}">{{ .Title }}</a></h4>
|
||||
{{ .Summary }}
|
||||
</div>
|
||||
{{ if .Truncated }}
|
||||
<div class="read-more-link">
|
||||
<a href="{{ .RelPermalink }}">Read More…</a>
|
||||
</div>
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
|
||||
Note how the `.Truncated` boolean valuable may be used to hide the "Read More..." link when the content is not truncated, i.e. when the summary contains the entire article.
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-09-28
|
||||
date: 2013-07-01
|
||||
linktitle: Types
|
||||
menu:
|
||||
main:
|
||||
parent: content
|
||||
next: /content/archetypes
|
||||
prev: /content/sections
|
||||
title: Content Types
|
||||
weight: 40
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo has full support for different types of content. A content type can have a
|
||||
unique set of meta data, template and can be automatically created by the `hugo new`
|
||||
command through using content [archetypes](/content/archetypes/).
|
||||
|
||||
A good example of when multiple types are needed is to look at [Tumblr](https://www.tumblr.com/). A piece
|
||||
of content could be a photo, quote or post, each with different meta data and
|
||||
rendered differently.
|
||||
|
||||
## Assigning a content type
|
||||
|
||||
Hugo assumes that your site will be organized into [sections](/content/sections/)
|
||||
and each section will use the corresponding type. If you are taking advantage of
|
||||
this, then each new piece of content you place into a section will automatically
|
||||
inherit the type.
|
||||
|
||||
Alternatively, you can set the type in the meta data under the key "`type`".
|
||||
|
||||
|
||||
## Creating new content of a specific type
|
||||
|
||||
Hugo has the ability to create a new content file and populate the front matter
|
||||
with the data set corresponding to that type. Hugo does this by utilizing
|
||||
[archetypes](/content/archetypes/).
|
||||
|
||||
To create a new piece of content, use:
|
||||
|
||||
hugo new relative/path/to/content.md
|
||||
|
||||
For example, if I wanted to create a new post inside the post section, I would type:
|
||||
|
||||
hugo new post/my-newest-post.md
|
||||
|
||||
|
||||
## Defining a content type
|
||||
|
||||
Creating a new content type is easy in Hugo. You simply provide the templates and archetype
|
||||
that the new type will use. You only need to define the templates, archetypes and/or views
|
||||
unique to that content type. Hugo will fall back to using the general templates and default archetype
|
||||
whenever a specific file is not present.
|
||||
|
||||
*Remember, all of the following are optional:*
|
||||
|
||||
### Create Type Directory
|
||||
Create a directory with the name of the type in `/layouts`. Type is always singular. *E.g. `/layouts/post`*.
|
||||
|
||||
### Create single template
|
||||
Create a file called `single.html` inside your directory. *E.g. `/layouts/post/single.html`*.
|
||||
|
||||
### Create list template
|
||||
Create a file called `post.html` inside the section lists template directory, `/layouts/section`. *E.g. `/layouts/section/post.html`*.
|
||||
|
||||
### Create views
|
||||
Many sites support rendering content in a few different ways, for
|
||||
instance, a single page view and a summary view to be used when
|
||||
displaying a [list of contents on a single page](/templates/list).
|
||||
Hugo makes no assumptions here about how you want to display your
|
||||
content, and will support as many different views of a content type
|
||||
as your site requires. All that is required for these additional
|
||||
views is that a template exists in each `/layouts/TYPE` directory
|
||||
with the same name.
|
||||
|
||||
### Create a corresponding archetype
|
||||
|
||||
Create a file called <code><em>type</em>.md</code> in the `/archetypes` directory. *E.g. `/archetypes/post.md`*.
|
||||
|
||||
More details about archetypes can be found at the [archetypes docs](/content/archetypes/).
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Contributing to the Hugo Project
|
||||
linktitle: Contributing to Hugo
|
||||
description: Contribute to Hugo development and documentation.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [contribute]
|
||||
tags: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "contribute"
|
||||
weight: 01
|
||||
weight: 01 #rem
|
||||
draft: false
|
||||
slug:
|
||||
aliases: [/tutorials/how-to-contribute-to-hugo/,/community/contributing/]
|
||||
toc: false
|
||||
---
|
||||
|
||||
Hugo relies heavily on the enthusiasm and participation of the open-source community. We need your support in both its development and documentation.
|
||||
|
||||
Hugo's contribution guidelines are [detailed in a `CONTRIBUTING.md`](https://github.com/spf13/hugo/blob/master/CONTRIBUTING.md) in the Hugo source repository on GitHub.
|
||||
+136
-74
@@ -1,46 +1,92 @@
|
||||
---
|
||||
date: 2016-04-03T13:21:56+02:00
|
||||
linktitle: How to contribute
|
||||
title: Contribute to Hugo Development
|
||||
linktitle: Development
|
||||
description: Hugo relies heavily on contributions from the open source community. You don't need to be a Golang guru to contribute to the project's development.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [contribute]
|
||||
tags: [dev,open source]
|
||||
authors: [digitalcraftsman]
|
||||
menu:
|
||||
main:
|
||||
parent: tutorials
|
||||
next: /tutorials/installing-on-mac/
|
||||
prev: /tutorials/github-pages-blog/
|
||||
title: How to contribute to Hugo
|
||||
docs:
|
||||
parent: "contribute"
|
||||
weight: 10
|
||||
weight: 10
|
||||
sections_weight: 10
|
||||
draft: false
|
||||
aliases: [/contribute/development/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
Hugo is an open source project and lives by the work of its [contributors](https://github.com/gohugoio/hugo/graphs/contributors). Help to make Hugo even more awesome. There are plenty of [open issues](https://github.com/gohugoio/hugo/issues) on GitHub and we need your help.
|
||||
Hugo is an open-source project and lives by the work of its [contributors][]. There are plenty of [open issues][issues], and we need your help to make Hugo even more awesome.
|
||||
|
||||
This tutorial is intended for people who are new to Git, GitHub or open source projects in general. It should help to overcome most of the barriers that newcomers encounter. It describes step by step what you need to do.
|
||||
## Assumptions
|
||||
|
||||
For any kind of questions please take a look at our [forum](https://discourse.gohugo.io/).
|
||||
This contribution guide takes a step-by-step approach in hopes of helping newcomers. Therefore, we only assume the following:
|
||||
|
||||
## Install Go
|
||||
* You are new to Git or open-source projects in general
|
||||
* You are a fan of Hugo and enthusiastic about contributing to the project
|
||||
|
||||
The installation of Go should take only a few minutes. [Download](https://golang.org/dl/) the latest stable version of Go and follow the official [installation guide](https://golang.org/doc/install).
|
||||
{{% note "Additional Questions?" %}}
|
||||
If you're struggling at any point in this contribution guide, reach out to the Hugo community in [Hugo's Discussion forum](https://discourse.gohugo.io).
|
||||
{{% /note %}}
|
||||
|
||||
Let's confirm the correct installation of Go. Open a terminal (or command line under Windows). Execute `go version` and you should see the version number of your Go installation. Next, make sure that you setup the `GOPATH` as described in the installation guide.
|
||||
## Installing Golang
|
||||
|
||||
You can print the `GOPATH` with `echo $GOPATH`. You should see a non-empty string containing a valid path to your Go workspace.
|
||||
The installation of Go should take only a few minutes. You have more than one option to get Go up and running on your machine.
|
||||
|
||||
### GVM as alternative
|
||||
If you are having trouble following the installation guides for go, check out [Go Bootcamp, which contains setups for every platform][gobootcamp] or reach out to the Hugo community in the [Hugo Discussion Forums][forums].
|
||||
|
||||
More experienced users can use the [Go Version Manager](https://github.com/moovweb/gvm), or GVM for short. It allows you to switch between different Go versions *on the same machine*. Probably you don't need this feature. But you can easily upgrade to a new released Go version with a few commands.
|
||||
### Installing Go From Source
|
||||
|
||||
This is handy if you follow the developement of Hugo over a longer period of time. Future versions of Hugo will usually be compiled with the latest version of Go. Sooner or later you have to upgrade if you want to keep up.
|
||||
[Download the latest stable version of Go][godl] and follow the official [Golang installation guide][goinstall].
|
||||
|
||||
Once you're finished installing Go, let's confirm everything is working correctly. Open a terminal---or command line under Windows--and type the following:
|
||||
|
||||
## Create an account on GitHub
|
||||
```bash
|
||||
`go version`
|
||||
```
|
||||
|
||||
You should see something similar to the following written to the console. Note that the version here reflects the most recent version of Go as of the last update for this page:
|
||||
|
||||
```bash
|
||||
go version go1.8 darwin/amd64
|
||||
```
|
||||
|
||||
Next, make sure that you set up your `GOPATH` [as described in the installation guide][setupgopath].
|
||||
|
||||
You can print the `GOPATH` with `echo $GOPATH`. You should see a non-empty string containing a valid path to your Go workspace; .e.g.:
|
||||
|
||||
```bash
|
||||
/Users/<yourusername>/Code/go
|
||||
```
|
||||
|
||||
### Installing Go with Homebrew
|
||||
|
||||
If you are a macOS user and have [Homebrew](https://brew.sh/) installed on your machine, installing Go is as simple as the following command:
|
||||
|
||||
{{% code file="install-go.sh" %}}
|
||||
```bash
|
||||
brew install go
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
### Install Go via GVM
|
||||
|
||||
More experienced users can use the [Go Version Manager][gvm] (GVM). GVM allows you to switch between different Go versions *on the same machine*. If you're a beginner, you probably don't need this feature. However, GVM makes it easy to upgrade to a new released Go version with just a few commands.
|
||||
|
||||
GVM comes in especially handy if you follow the development of Hugo over a longer period of time. Future versions of Hugo will usually be compiled with the latest version of Go. Sooner or later, you will have to upgrade if you want to keep up.
|
||||
|
||||
## Creating a GitHub Account
|
||||
|
||||
If you're going to contribute code, you'll need to have an account on GitHub. Go to [www.github.com/join](https://github.com/join) and set up a personal account.
|
||||
|
||||
## Installing Git on Your System
|
||||
|
||||
## Install Git on your system
|
||||
|
||||
You will need to install Git. This tutorial assumes basic knowledge about Git. Refer to this excellent [Git book](https://git-scm.com/) if you are not sure where to begin. The used terminology will be explained with annotations.
|
||||
You will need to have Git installed on your computer to contribute to Hugo development. Teaching git is outside the scope of the Hugo docs, but if you're looking for an excellent reference to learn the basics of Git, we recommend the [Git book][gitbook] if you are not sure where to begin. The used terminology will be explained with annotations.
|
||||
|
||||
Git is a [version control system](https://en.wikipedia.org/wiki/Version_control) to track the changes of source code. Hugo depends on smaller third-party packages that are used to extend the functionality. We use them because we don't want to reinvent the wheel.
|
||||
|
||||
@@ -54,17 +100,17 @@ Finally, check again with `git version` if Git was installed successfully.
|
||||
|
||||
There are several [GUI clients](https://git-scm.com/downloads/guis) that help you to operate Git. Not all are available for all operating systems and maybe differ in their usage. Thus, so we will use the command line since the commands are everywhere the same.
|
||||
|
||||
### Install Hub on your system (optional)
|
||||
### Install Hub on Your System (Optional)
|
||||
|
||||
Hub is a great tool for working with GitHub. The main site for it is [www.hub.github.com](https://hub.github.com/). Feel free to install this little Git wrapper.
|
||||
|
||||
On a Mac, install Hub using brew:
|
||||
On a Mac, you can install [Hub](https://github.com/github/hub) using [Homebrew](https://brew.sh):
|
||||
|
||||
```sh
|
||||
brew install hub
|
||||
```
|
||||
|
||||
Create an alias (in Bash) so that typing git actually runs Hub:
|
||||
Now we'll create an [alias in Bash](http://tldp.org/LDP/abs/html/aliases.html) so that typing `git` actually runs `Hub`:
|
||||
|
||||
```sh
|
||||
echo "alias git='hub'" >> ~/.bash_profile
|
||||
@@ -77,55 +123,44 @@ git version 2.6.3
|
||||
hub version 2.2.2
|
||||
```
|
||||
|
||||
|
||||
## Set up your working copy
|
||||
|
||||
The working copy is set up locally on your computer. It's what you'll edit, compile, and end up pushing back to GitHub. The main steps are cloning the repository and creating your fork as a remote.
|
||||
|
||||
### Vendored Dependencies
|
||||
|
||||
Hugo uses [govendor](https://github.com/kardianos/govendor) to vendor dependencies, but we don't commit the vendored packages themselves to the Hugo git repository.
|
||||
Therefore, a simple `go get` is not supported since `go get` is not vendor-aware.
|
||||
You **must use govendor** to fetch and manage Hugo's dependencies.
|
||||
|
||||
```sh
|
||||
go get -v -u github.com/kardianos/govendor
|
||||
```
|
||||
|
||||
### Fetch the Sources from GitHub
|
||||
### Clone the repository
|
||||
|
||||
We assume that you've set up your `GOPATH` (see the section above if you're unsure about this). You should now copy the Hugo repository down to your computer. You'll hear this called "clone the repo". GitHub's [help pages](https://help.github.com/articles/cloning-a-repository/) give us a short explanation:
|
||||
|
||||
> When you create a repository on GitHub, it exists as a remote repository. You can create a local clone of your repository on your computer and sync between the two locations.
|
||||
|
||||
We're going to clone the [master Hugo repository](https://github.com/gohugoio/hugo). That seems counter-intuitive, since you won't have commit rights on it. But it's required for the Go workflow. You'll work on a copy of the master and push your changes to your own repository on GitHub.
|
||||
We're going to clone the [master Hugo repository](https://github.com/spf13/hugo). That seems counter-intuitive, since you won't have commit rights on it. But it's required for the Go workflow. You'll work on a copy of the master and push your changes to your own repository on GitHub.
|
||||
|
||||
So, let's clone that master repository with govendor:
|
||||
So, let's clone that master repository:
|
||||
|
||||
```sh
|
||||
govendor get -v github.com/gohugoio/hugo
|
||||
go get -v -u github.com/spf13/hugo
|
||||
```
|
||||
|
||||
### Fork the repository
|
||||
|
||||
If you're not familiar with this term, GitHub's [help pages](https://help.github.com/articles/fork-a-repo/) provide again a simple explanation:
|
||||
If you're not fimiliar with this term, GitHub's [help pages](https://help.github.com/articles/fork-a-repo/) provide again a simple explanation:
|
||||
|
||||
> A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.
|
||||
|
||||
#### Fork by hand
|
||||
|
||||
Open the [Hugo repository](https://github.com/gohugoio/hugo) on GitHub and click on the "Fork" button in the top right.
|
||||
Open the [Hugo repository](https://github.com/spf13/hugo) on GitHub and click on the "Fork" button in the top right.
|
||||
|
||||

|
||||

|
||||
|
||||
Now open your fork repository on GitHub and copy the remote url of your fork. You can choose between HTTPS and SSH as protocol that Git should use for the following operations. HTTPS works always [if you're not sure](https://help.github.com/articles/which-remote-url-should-i-use/).
|
||||
|
||||

|
||||

|
||||
|
||||
Switch back to the terminal and move into the directory of the cloned master repository from the last step.
|
||||
|
||||
```sh
|
||||
cd $GOPATH/src/github.com/gohugoio/hugo
|
||||
cd $GOPATH/src/github.com/spf13/hugo
|
||||
```
|
||||
|
||||
Now Git needs to know that our fork exists by adding the copied remote url:
|
||||
@@ -155,14 +190,13 @@ git remote -v
|
||||
The output should look similar:
|
||||
|
||||
```sh
|
||||
digitalcraftsman git@github.com:digitalcraftsman/hugo.git (fetch)
|
||||
digitalcraftsman git@github.com:digitalcraftsman/hugo.git (push)
|
||||
origin https://github.com/gohugoio/hugo (fetch)
|
||||
origin https://github.com/gohugoio/hugo (push)
|
||||
digitalcraftsman git@github.com:digitalcraftsman/hugo.git (fetch)
|
||||
digitalcraftsman git@github.com:digitalcraftsman/hugo.git (push)
|
||||
origin https://github.com/spf13/hugo (fetch)
|
||||
origin https://github.com/spf13/hugo (push)
|
||||
```
|
||||
|
||||
|
||||
## The contribution workflow
|
||||
## The Hugo Git Contribution Workflow
|
||||
|
||||
### Create a new branch
|
||||
|
||||
@@ -183,37 +217,37 @@ git checkout -b <BRANCH-NAME>
|
||||
|
||||
You can check on which branch your are with `git branch`. You should see a list of all local branches. The current branch is indicated with a little asterisk.
|
||||
|
||||
### Contributing to the documentation
|
||||
### Contributing to Documentation
|
||||
|
||||
Perhaps you want to start contributing to the docs. Then you can ignore most of the following steps. You can find the documentation within the cloned repository in the subfolder `docs`. Change the directory with `cd docs`. Install the [latest release]({{< relref "overview/installing.md" >}}). Or read on and build Hugo from source.
|
||||
Perhaps you want to start contributing to the Hugo docs. If so, you can ignore most of the following steps and focus on the `/docs` directory within your newly cloned repository. You can change directories into the Hugo docs using `cd docs`.
|
||||
|
||||
You can start Hugo's built-in server via `hugo server`. Browse the documentation by entering [http://localhost:1313](http://localhost:1313) in the address bar of your browser. The server automatically updates the page if you change its content.
|
||||
You can start Hugo's built-in server via `hugo server`. Browse the documentation by entering [http://localhost:1313](http://localhost:1313) in the address bar of your browser. The server automatically updates the page whenever you change content.
|
||||
|
||||
We have developed a [separate Hugo documentation contribution guide][docscontrib] for more information on how the Hugo docs are built, organized, and improved by the generosity of people like you.
|
||||
|
||||
### Building Hugo
|
||||
|
||||
While making changes in the codebase it's a good idea to build the binary to test them:
|
||||
|
||||
```sh
|
||||
make hugo
|
||||
go build -o hugo main.go
|
||||
```
|
||||
|
||||
### Testing
|
||||
|
||||
Sometimes changes on the codebase can cause unintended side effects. Or they don't work as expected. Most functions have their own test cases. You can find them in files ending with `_test.go`.
|
||||
|
||||
```sh
|
||||
make check
|
||||
```
|
||||
Make sure the commands `go test ./...` passes, and `go build` completes.
|
||||
|
||||
### Formatting
|
||||
|
||||
The Go code styleguide maybe is opinionated but it ensures that the codebase looks the same, regardless who wrote the code. Go comes with its own formatting tool. Let's apply the styleguide to our additions:
|
||||
The Go code styleguide maybe is opiniated but it ensures that the codebase looks the same, regardless who wrote the code. Go comes with its own formatting tool. Let's apply the styleguide to our addtions:
|
||||
|
||||
```sh
|
||||
govendor fmt +local
|
||||
go fmt ./...
|
||||
```
|
||||
|
||||
Once you made your additions commit your changes. Make sure that you follow our [code contribution guidelines](https://github.com/gohugoio/hugo/blob/master/CONTRIBUTING.md):
|
||||
Once you made your additions commit your changes. Make sure that you follow our [code contribution guidelines](https://github.com/spf13/hugo/blob/master/CONTRIBUTING.md):
|
||||
|
||||
```sh
|
||||
# Add all changed files
|
||||
@@ -253,7 +287,11 @@ git commit --amend
|
||||
|
||||
#### Modifying multiple commits
|
||||
|
||||
This is a bit more advanced. Git allows you to [rebase](https://git-scm.com/docs/git-rebase) commits interactively. In other words: it allows you to rewrite the commit history. **Take care of your actions. They can cause unintended changes. Skip this section if you're not sure!**
|
||||
{{% warning "Be Careful Modifying Multiple Commits"%}}
|
||||
Modifications such as those described in this section can have serious unintended consequences. Skip this section if you're not sure!
|
||||
{{% /warning %}}
|
||||
|
||||
This is a bit more advanced. Git allows you to [rebase](https://git-scm.com/docs/git-rebase) commits interactively. In other words: it allows you to rewrite the commit history.
|
||||
|
||||
```sh
|
||||
git rebase --interactive @~6
|
||||
@@ -274,7 +312,6 @@ In the case above we should merge the last to commits in the commit of this tuto
|
||||
|
||||
All operations are written before the commit message. Replace "pick" with an operation. In this case `squash` or `s` for short:
|
||||
|
||||
|
||||
```sh
|
||||
pick 80d02a1 tpl: Add hasPrefix to the template funcs' "smoke test"
|
||||
pick aaee038 tpl: Sort the smoke tests
|
||||
@@ -297,7 +334,7 @@ squash 33c8973 Begin workflow
|
||||
squash 3502f2e Refactoring and typo fixes
|
||||
```
|
||||
|
||||
Close the editor. It should open again with a new tab. A text is instructing you to define a new commit message for the last two commits that should be merged (a.k.a. squashed). Save the file (<kbd>CTRL</kbd>+<kbd>S</kbd>) and close the editor again.
|
||||
Close the editor. It should open again with a new tab. A text is instructing you to define a new commit message for the last two commits that should be merged (aka "squashed"). Save the file with <kbd>CTRL</kbd>+<kbd>S</kbd> and close the editor again.
|
||||
|
||||
A last time a new tab opens. Enter a new commit message and save again. Your terminal should contain a status message. Hopefully this one:
|
||||
|
||||
@@ -309,7 +346,7 @@ Check the commit log if everything looks as expected. Should an error occur you
|
||||
|
||||
### Push commits
|
||||
|
||||
To push our commits to the fork on GitHub we need to specify a destination. A destination is defined by the remote and a branch name. Earlier, the defined that the remote url of our fork is the same as our GitHub handle, in my case `digitalcraftsman`. The branch should have the same as our local one. This makes it easy to identify corresponding branches.
|
||||
To push our commits to the fork on GitHub we need to speficy a destination. A destination is defined by the remote and a branch name. Earlier, the defined that the remote url of our fork is the same as our GitHub handle, in my case `digitalcraftsman`. The branch should have the same as our local one. This makes it easy to identify corresponding branches.
|
||||
|
||||
```sh
|
||||
git push --set-upstream <YOUR-GITHUB-USERNAME> <BRANCHNAME>
|
||||
@@ -319,14 +356,13 @@ Now Git knows the destination. Next time when you to push commits you just need
|
||||
|
||||
If you modified your commit history in the last step GitHub will reject your try to push. This is a safety-feature because the commit history isn't the same and new commits can't be appended as usual. You can enforce this push explicitly with `git push --force`.
|
||||
|
||||
|
||||
## Open a pull request
|
||||
|
||||
We made a lot of progress. Good work. In this step we finally open a pull request to submit our additions. Open the [Hugo master repository](https://github.com/gohugoio/hugo/) on GitHub in your browser.
|
||||
We made a lot of progress. Good work. In this step we finally open a pull request to submit our additions. Open the [Hugo master repository](https://github.com/spf13/hugo/) on GitHub in your browser.
|
||||
|
||||
You should find a green button labeled with "New pull request". But GitHub is clever and probably suggests you a pull request like in the beige box below:
|
||||
You should find a green button labeld with "New pull request". But GitHub is clever and probably suggests you a pull request like in the beige box below:
|
||||
|
||||
<img src="/img/tutorials/how-to-contribute-to-hugo/open-pull-request.png" alt="Open a pull request">
|
||||

|
||||
|
||||
The new page summaries the most important information of your pull request. Scroll down and you find the additions of all your commits. Make sure everything looks as expected and click on "Create pull request".
|
||||
|
||||
@@ -334,19 +370,45 @@ The new page summaries the most important information of your pull request. Scro
|
||||
|
||||
Last but not least you should accept the contributor license agreement (CLA). A new comment should be added automatically to your pull request. Click on the yellow badge, accept the agreement and authenticate yourself with your GitHub account. It just takes a few clicks and only needs to be done once.
|
||||
|
||||
<img src="/img/tutorials/how-to-contribute-to-hugo/accept-cla.png" alt="Accept the CLA">
|
||||
|
||||

|
||||
|
||||
### Automatic builds
|
||||
|
||||
We use the [Travis CI loop](https://travis-ci.org/gohugoio/hugo) (Linux and OS X) and [AppVeyor](https://ci.appveyor.com/project/gohugoio/hugo/branch/master) (Windows) to compile Hugo with your additions. This should ensure that everything works as expected before merging your pull request. This in most cases only relevant if you made changes to the codebase of Hugo.
|
||||
We use the [Travis CI loop](https://travis-ci.org/spf13/hugo) (Linux and OS X) and [AppVeyor](https://ci.appveyor.com/project/spf13/hugo/branch/master) (Windows) to compile Hugo with your additions. This should ensure that everything works as expected before merging your pull request. This in most cases only relevant if you made changes to the codebase of Hugo.
|
||||
|
||||
<img src="/img/tutorials/how-to-contribute-to-hugo/ci-errors.png" alt="Automic builds and their status">
|
||||

|
||||
|
||||
Above you can see that Travis wasn't able to compile the changes in this pull request. Click on "Details" and try to investigate why the build failed. But it doesn't have to be your fault. Mostly, the `master` branch that we used as foundation for your pull request should build without problems.
|
||||
|
||||
If you have questions leave a comment in the pull request. We are willing to assist you.
|
||||
If you have questions, leave a comment in the pull request. We are willing to assist you.
|
||||
|
||||
## Where to start?
|
||||
|
||||
Thank you for reading this tutorial. Hopefully, we see you again on GitHub. There are plenty of [open issues](https://github.com/gohugoio/hugo/issues) on GitHub. Feel free to open an issue if you think you found a bug or you have a new idea to improve Hugo. We are happy to hear from you.
|
||||
Thank you for reading through this contribution guide. Hopefully, we will see you again soon on GitHub. There are plenty of [open issues][issues] for you to help with.
|
||||
|
||||
Feel free to [open an issue][newissue] if you think you found a bug or you have a new idea to improve Hugo. We are happy to hear from you.
|
||||
|
||||
## Additional References for Learning Git and Golang
|
||||
|
||||
* [Codecademy's Free "Learn Git" Course][codecademy] (Free)
|
||||
* [Code School and GitHub's "Try Git" Tutorial][trygit] (Free)
|
||||
* [The Git Book][gitbook] (Free)
|
||||
* [Go Bootcamp][gobootcamp]
|
||||
* [GitHub Pull Request Tutorial, Thinkful][thinkful]
|
||||
|
||||
|
||||
[codecademy]: https://www.codecademy.com/learn/learn-git
|
||||
[contributors]: https://github.com/spf13/hugo/graphs/contributors
|
||||
[docscontrib]: /contribute/documentation/
|
||||
[forums]: https://discourse.gohugo.io
|
||||
[gitbook]: https://git-scm.com/
|
||||
[gobootcamp]: http://www.golangbootcamp.com/book/get_setup
|
||||
[godl]: https://golang.org/dl/
|
||||
[goinstall]: https://golang.org/doc/install
|
||||
[gvm]: https://github.com/moovweb/gvm
|
||||
[issues]: https://github.com/spf13/hugo/issues
|
||||
[newissue]: https://github.com/spf13/hugo/issues/new
|
||||
[releases]: /getting-started/
|
||||
[setupgopath]: https://golang.org/doc/code.html#Workspaces
|
||||
[thinkful]: https://www.thinkful.com/learn/github-pull-request-tutorial/
|
||||
[trygit]: https://try.github.io/levels/1/challenges/1
|
||||
@@ -0,0 +1,392 @@
|
||||
---
|
||||
title: Contribute to the Hugo Docs
|
||||
linktitle: Documentation
|
||||
description: Documentation is an integral part of any open source project. The Hugo docs are as much a work in progress as the source it attempts to teach its users.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [contribute]
|
||||
tags: [docs,documentation,community, contribute]
|
||||
menu:
|
||||
docs:
|
||||
parent: "contribute"
|
||||
weight: 20
|
||||
weight: 20
|
||||
sections_weight: 20
|
||||
draft: false
|
||||
aliases: [/contribute/docs/]
|
||||
toc: true
|
||||
---
|
||||
|
||||
Documentation is a critical component of any open-source project. The Hugo docs were completely reworked for the release of v0.20, but there is always room for improvement.
|
||||
|
||||
## Create Your Fork
|
||||
|
||||
It's best to make changes to the Hugo docs on your local machine to check for consistent visual styling. Make sure you've created a fork of Hugo on GitHub and cloned the repository locally on your machine. For more information, you can see [GitHub's documentation on "forking"][ghforking] or follow along with [Hugo's development contribution guide][hugodev].
|
||||
|
||||
You can then create a separate branch for your additions. Be sure to choose a descriptive branch name that best fits the type of content. The following is an example of a branch name you might use for adding a new website to the showcase:
|
||||
|
||||
```git
|
||||
git checkout -b jon-doe-showcase-addition
|
||||
```
|
||||
|
||||
## Adding New Content
|
||||
|
||||
The Hugo docs make heavy use of Hugo's [archetypes][] feature. All content sections in Hugo documentation have an assigned archetype.
|
||||
|
||||
Adding new content to the Hugo docs follows the same pattern, regardless of the content section:
|
||||
|
||||
```
|
||||
hugo new <DOCS-SECTION>/<new-content-lowercase>.md
|
||||
```
|
||||
|
||||
{{% note "`title:`, `date:`, and Field Order" %}}
|
||||
`title` and `date` fields are added automatically when using archetypes via `hugo new`. Do not be worried if the order of the new file's front matter fields on your local machine is different than that of the examples provided in the Hugo docs. This is a known issue [(#452)](https://github.com/spf13/hugo/issues/452).
|
||||
{{% /note %}}
|
||||
|
||||
### Adding a New Function
|
||||
|
||||
Once you have cloned the Hugo repository, you can create a new function via the following command. Keep the file name lowercase.
|
||||
|
||||
```
|
||||
hugo new functions/newfunction.md
|
||||
```
|
||||
|
||||
The archetype for `functions` according to the Hugo theme is as follows:
|
||||
|
||||
{{% code file="archetypes/functions.md" %}}
|
||||
```yaml
|
||||
{{< readfile file="/themes/gohugoioTheme/archetypes/functions.md">}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### New Function Required Fields
|
||||
|
||||
Here is a review of the front matter fields automatically generated for you using `hugo new functions/*`:
|
||||
|
||||
***`title`***
|
||||
: this will be auto-populated in all lowercase when you use `hugo new` generator.
|
||||
|
||||
***`linktitle`***
|
||||
: the function's actual casing (e.g., `replaceRE` rather than `replacere`).
|
||||
|
||||
***`description`***
|
||||
: a brief description used to populate the [Functions Quick Reference](/functions/).
|
||||
|
||||
`categories`
|
||||
: currently auto-populated with 'functions` for future-proofing and portability reasons only; ignore this field.
|
||||
|
||||
`tags`
|
||||
: only if you think it will help end users find other related functions
|
||||
|
||||
`signature`
|
||||
: this is a signature/syntax definition for calling the function (e.g., `apply SEQUENCE FUNCTION [PARAM...]`).
|
||||
|
||||
`workson`
|
||||
: acceptable values include `lists`,`taxonomies`, `terms`, `groups`, and `files`.
|
||||
|
||||
`hugoversion`
|
||||
: the version of Hugo that will ship with this new function.
|
||||
|
||||
`relatedfuncs`
|
||||
: other [templating functions][] you feel are related to your new function to help fellow Hugo users.
|
||||
|
||||
`{{.Content}}`
|
||||
: an extended description of the new function; examples are not only welcomed but encouraged.
|
||||
|
||||
In the body of your function, expand the short description used in the front matter. Include as many examples as possible, and leverage the Hugo docs [`code` shortcode](#adding-code-blocks). If you are unable to add examples but would like to solicit help from the Hugo community, add `needsexample: true` to your front matter.
|
||||
|
||||
### Adding a New Tutorial
|
||||
|
||||
Once you have cloned the Hugo repository, you can create a new tutorial via the following command. Name the markdown file accordingly:
|
||||
|
||||
```
|
||||
hugo new tutorials/my-new-tutorial.md
|
||||
```
|
||||
|
||||
The archetype for the `tutorials` content type is as follows:
|
||||
|
||||
{{% code file="archetypes/tutorials.md" %}}
|
||||
```yaml
|
||||
{{< readfile file="/themes/gohugoioTheme/archetypes/tutorials.md">}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
## Adding Code Blocks
|
||||
|
||||
Code blocks are crucial for providing examples of Hugo's new features to end users of the Hugo docs. Whenever possible, create examples that you think Hugo users will be able to implement in their own projects.
|
||||
|
||||
### Standard Syntax
|
||||
|
||||
Across all pages on the Hugo docs, the typical triple-back-tick markdown syntax is used. If you do not want to take the extra time to implement the following code block shortcodes, please use standard GitHub-flavored markdown. The Hugo docs use a version of [highlight.js](https://highlightjs.org/) with a specific set of languages.
|
||||
|
||||
Your options for languages are `xml`/`html`, `go`/`golang`, `md`/`markdown`/`mkd`, `handlebars`, `apache`, `toml`, `yaml`, `json`, `css`, `asciidoc`, `ruby`, `powershell`/`ps`, `scss`, `sh`/`zsh`/`bash`/`git`, `http`/`https`, and `javascript`/`js`.
|
||||
|
||||
````html
|
||||
```html
|
||||
<h1>Hello world!</h1>
|
||||
```
|
||||
````
|
||||
|
||||
### Code Block Shortcode
|
||||
|
||||
The Hugo documentation comes with a very robust shortcode for adding interactive code blocks.
|
||||
|
||||
{{% note %}}
|
||||
With the `code` shortcodes, *you must include triple back ticks and a language declaration*. This was done by design so that the shortcode wrappers were easily added to legacy documentation and will be that much easier to remove if needed in future versions of the Hugo docs.
|
||||
{{% /note %}}
|
||||
|
||||
### `code`
|
||||
|
||||
`code` is the Hugo docs shortcode you'll use most often. `code` requires has only one named parameter: `file`. Here is the pattern:
|
||||
|
||||
````markdown
|
||||
{{%/* code file="smart/file/name/with/path.html" download="download.html" copy="true" */%}}
|
||||
```language
|
||||
A whole bunch of coding going on up in here!
|
||||
```
|
||||
{{%/* /code */%}}
|
||||
````
|
||||
|
||||
The following are the arguments passed into `code`:
|
||||
|
||||
***`file`***
|
||||
: the only *required* argument. `file` is needed for styling but also plays an important role in helping users create a mental model around Hugo's directory structure. Visually, this will be displayed as text in the top left of the code block.
|
||||
|
||||
`download`
|
||||
: if omitted, this will have no effect on the rendered shortcode. When a value is added to `download`, it's used as the filename for a downloadable version of the code block.
|
||||
|
||||
`copy`
|
||||
: a copy button is added automatically to all `code` shortcodes. If you want to keep the filename and styling of `code` but don't want to encourage readers to copy the code (e.g., a "Do not do" snippet in a tutorial), use `copy="false"`.
|
||||
|
||||
#### Example `code` Input
|
||||
|
||||
This example HTML code block tells Hugo users the following:
|
||||
|
||||
1. This file *could* live in `layouts/_default`, as demonstrated by `layouts/_default/single.html` as the value for `file`.
|
||||
2. This snippet is complete enough to be downloaded and implemented in a Hugo project, as demonstrated by `download="single.html"`.
|
||||
|
||||
````md
|
||||
{{%/* code file="layouts/_default/single.html" download="single.html" */%}}
|
||||
```html
|
||||
{{ define "main" }}
|
||||
<main>
|
||||
<article>
|
||||
<header>
|
||||
<h1>{{.Title}}</h1>
|
||||
{{with .Params.subtitle}}
|
||||
<span>{{.}}</span>
|
||||
</header>
|
||||
<div>
|
||||
{{.Content}}
|
||||
</div>
|
||||
<aside>
|
||||
{{.TableOfContents}}
|
||||
</aside>
|
||||
</article>
|
||||
</main>
|
||||
{{ end }}
|
||||
```
|
||||
{{%/* /code */%}}
|
||||
````
|
||||
|
||||
##### Example 'code' Display
|
||||
|
||||
The output of this example will render to the Hugo docs as follows:
|
||||
|
||||
{{% code file="layouts/_default/single.html" download="single.html" %}}
|
||||
```html
|
||||
{{ define "main" }}
|
||||
<main>
|
||||
<article>
|
||||
<header>
|
||||
<h1>{{.Title}}</h1>
|
||||
{{with .Params.subtitle}}
|
||||
<span>{{.}}</span>
|
||||
</header>
|
||||
<div>
|
||||
{{.Content}}
|
||||
</div>
|
||||
<aside>
|
||||
{{.TableOfContents}}
|
||||
</aside>
|
||||
</article>
|
||||
</main>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
<!-- #### Output Code Block
|
||||
|
||||
The `output` shortcode is almost identical to the `code` shortcode but only takes and requires `file`. The purpose of `output` is to show *rendered* HTML and therefore almost always follows another basic code block *or* and instance of the `code` shortcode:
|
||||
|
||||
````html
|
||||
{{%/* output file="post/my-first-post/index.html" */%}}
|
||||
```html
|
||||
<h1>This is my First Hugo Blog Post</h1>
|
||||
<p>I am excited to be using Hugo.</p>
|
||||
```
|
||||
{{%/* /output */%}}
|
||||
````
|
||||
|
||||
The preceding `output` example will render as follows to the Hugo docs:
|
||||
|
||||
{{% output file="post/my-first-post/index.html" %}}
|
||||
```html
|
||||
<h1>This is my First Hugo Blog Post</h1>
|
||||
<p>I am excited to be using Hugo.</p>
|
||||
```
|
||||
{{% /output %}} -->
|
||||
|
||||
## Blockquotes
|
||||
|
||||
Blockquotes can be added to the Hugo documentation using [typical Markdown blockquote syntax][bqsyntax]:
|
||||
|
||||
```markdown
|
||||
> Without the threat of punishment, there is no joy in flight.
|
||||
```
|
||||
|
||||
The preceding blockquote will render as follows in the Hugo docs:
|
||||
|
||||
> Without the threat of punishment, there is no joy in flight.
|
||||
|
||||
However, you can add a quick and easy `<cite>` element (added on the client via JavaScript) by separating your main blockquote and the citation with a hyphen with a single space on each side:
|
||||
|
||||
```markdown
|
||||
> Without the threat of punishment, there is no joy in flight. - [Kobo Abe](https://en.wikipedia.org/wiki/Kobo_Abe)
|
||||
```
|
||||
|
||||
Which will render as follows in the Hugo docs:
|
||||
|
||||
> Without the threat of punishment, there is no joy in flight. - [Kobo Abe][abe]
|
||||
|
||||
{{% note "Blockquotes `!=` Admonitions" %}}
|
||||
Previous versions of Hugo documentation used blockquotes to draw attention to text. This is *not* the [intended semantic use of `<blockquote>`](http://html5doctor.com/cite-and-blockquote-reloaded/). Use blockquotes when quoting. To note or warn your user of specific information, use the admonition shortcodes that follow.
|
||||
{{% /note %}}
|
||||
|
||||
## Admonitions
|
||||
|
||||
**Admonitions** are common in technical documentation. The most popular is that seen in [reStructuredText Directives][sourceforge]. From the SourceForge documentation:
|
||||
|
||||
> Admonitions are specially marked "topics" that can appear anywhere an ordinary body element can. They contain arbitrary body elements. Typically, an admonition is rendered as an offset block in a document, sometimes outlined or shaded, with a title matching the admonition type. - [SourceForge][sourceforge]
|
||||
|
||||
The Hugo docs contain three admonitions: `note`, `tip`, and `warning`.
|
||||
|
||||
### `note` Admonition
|
||||
|
||||
Use the `note` shortcode when you want to draw attention to information subtly. `note` is intended to be less of an interruption in content than is `warning`.
|
||||
|
||||
#### Example `note` Input
|
||||
|
||||
{{% code file="note-with-heading.md" %}}
|
||||
```markdown
|
||||
{{%/* note */%}}
|
||||
Here is a piece of information I would like to draw your **attention** to.
|
||||
{{%/* /note */%}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `note` Output
|
||||
|
||||
{{% output file="note-with-heading.html" %}}
|
||||
```html
|
||||
{{% note %}}
|
||||
Here is a piece of information I would like to draw your **attention** to.
|
||||
{{% /note %}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### Example `note` Display
|
||||
|
||||
{{% note %}}
|
||||
Here is a piece of information I would like to draw your **attention** to.
|
||||
{{% /note %}}
|
||||
|
||||
### `tip` Admonition
|
||||
|
||||
Use the `tip` shortcode when you want to give the reader advice. `tip`, like `note`, is intended to be less of an interruption in content than is `warning`.
|
||||
|
||||
#### Example `tip` Input
|
||||
|
||||
{{% code file="using-tip.md" %}}
|
||||
```markdown
|
||||
{{%/* tip */%}}
|
||||
Here's a bit of advice to improve your productivity with Hugo.
|
||||
{{%/* /tip */%}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `tip` Output
|
||||
|
||||
{{% output file="tip-output.html" %}}
|
||||
```html
|
||||
{{% tip %}}
|
||||
Here's a bit of advice to improve your productivity with Hugo.
|
||||
{{% /tip %}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### Example `tip` Display
|
||||
|
||||
{{% tip %}}
|
||||
Here's a bit of advice to improve your productivity with Hugo.
|
||||
{{% /tip %}}
|
||||
|
||||
### `warning` Admonition
|
||||
|
||||
Use the `warning` shortcode when you want to draw the user's attention to something important. A good usage example is for articulating breaking changes in Hugo versions, known bugs, or templating "gotchas."
|
||||
|
||||
#### Example `warning` Input
|
||||
|
||||
{{% code file="warning-admonition-input.md" %}}
|
||||
```markdown
|
||||
{{%/* warning */%}}
|
||||
This is a warning, which should be reserved for *important* information like breaking changes.
|
||||
{{%/* /warning */%}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
#### Example `warning` Output
|
||||
|
||||
{{% output file="warning-admonition-output.html" %}}
|
||||
```html
|
||||
{{% warning %}}
|
||||
This is a warning, which should be reserved for *important* information like breaking changes.
|
||||
{{% /warning %}}
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
#### Example `warning` Display
|
||||
|
||||
{{% warning %}}
|
||||
This is a warning, which should be reserved for *important* information like breaking changes.
|
||||
{{% /warning %}}
|
||||
|
||||
## Ask for Code Examples
|
||||
|
||||
Sometimes you want to contribute to the docs but don't have enough time to provide lengthy examples. If you want to flag a piece of content as needing more examples, add the following field to your front matter:
|
||||
|
||||
```
|
||||
needsexamples: true
|
||||
```
|
||||
|
||||
## Places to Start
|
||||
|
||||
The preceding `needsexamples` field is used to generate the following list of flagged content. Links will take you directly to the edit URL for the file within the GitHub GUI in the event that you are not comfortable cloning and editing the repository locally.
|
||||
|
||||
{{< needsexamples >}}
|
||||
|
||||
{{% note "Pull Requests and Branches" %}}
|
||||
Similar to [contributing to Hugo development](/contribute/development/), the Hugo team expects you to create a separate branch/fork when you make your generous contributions to the Hugo docs.
|
||||
{{% /note %}}
|
||||
|
||||
[abe]: https://en.wikipedia.org/wiki/Kobo_Abe
|
||||
[archetypes]: /content-management/archetypes/
|
||||
[bqsyntax]: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet#blockquotes
|
||||
[charcount]: http://www.lettercount.com/
|
||||
[`docs/static/images/showcase/`]: https://github.com/spf13/hugo/tree/master/docs/static/images/showcase/
|
||||
[ghforking]: https://help.github.com/articles/fork-a-repo/
|
||||
[hugodev]: /contribute/development/
|
||||
[shortcodeparams]: content-management/shortcodes/#shortcodes-without-markdown
|
||||
[sourceforge]: http://docutils.sourceforge.net/docs/ref/rst/directives.html#admonitions
|
||||
[templating function]: /functions/
|
||||
@@ -0,0 +1,154 @@
|
||||
---
|
||||
title: Add Your Hugo Theme to the Showcase
|
||||
linktitle: Themes
|
||||
description: If you've built a Hugo theme and want to contribute back to the Hugo Community, add your theme to the Hugo Showcase.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-27
|
||||
categories: [contribute]
|
||||
tags: [contribute,themes,design]
|
||||
authors: [digitalcraftsman]
|
||||
menu:
|
||||
docs:
|
||||
parent: "contribute"
|
||||
weight: 30
|
||||
weight: 30
|
||||
sections_weight: 30
|
||||
draft: false
|
||||
aliases: [/contribute/theme/]
|
||||
wip: true
|
||||
toc: true
|
||||
---
|
||||
|
||||
A collection of all themes created by the Hugo community, including screenshots and demos, can be found at <https://themes.gohugo.io>. Every theme in this list will automatically be added to the theme site. Theme updates aren't scheduled but usually happen at least once a week.
|
||||
|
||||
## tl;dr
|
||||
|
||||
1. Create your theme using `hugo new theme <THEMENAME>`;
|
||||
2. Test your theme against <https://github.com/spf13/HugoBasicExample> \*
|
||||
3. Add a `theme.toml` file to the root of the theme with all required metadata
|
||||
4. Add a descriptive `README.md` to the root of the theme source
|
||||
5. Add `/images/screenshot.png` and `/images/tn.png`
|
||||
|
||||
\* If your theme doesn't fit into the `Hugo Basic Example` site, we encourage theme authors to supply a self-contained Hugo site in `/exampleSite`.
|
||||
|
||||
{{% note %}}
|
||||
The folder name here---`exampleSite`---is important, as this folder will be picked up and used by the script that generates the Hugo Theme Site. It mirrors the root directory of a Hugo website and allows you to add custom content, assets, and a `config` file with preset values.
|
||||
{{% /note %}}
|
||||
|
||||
See the [Hugo Artist theme's exampleSite][artistexample] for a good example.
|
||||
|
||||
{{% note %}}
|
||||
Please make your example site's content is as neutral as possible. We hope this goes without saying.
|
||||
{{% /note %}}
|
||||
|
||||
## Theme Requirements
|
||||
|
||||
In order to add your theme to the Hugo Themes Showcase, the following requirements need to be met:
|
||||
|
||||
1. `theme.toml` with all required fields
|
||||
2. Images for thumbnail and screenshot
|
||||
3. A good README file instructions for users
|
||||
4. Addition to the hugoThemes GitHub repository
|
||||
|
||||
### Add Your Theme to the Repo
|
||||
|
||||
The easiest way to add your theme is to [open up a new issue in the theme repository][themeissuenew] with a link to the theme's repository on GitHub.
|
||||
|
||||
### Create a `theme.toml` File
|
||||
|
||||
`theme.toml` contains metadata about the theme and its creator and should be created automatically when running the `hugo new theme`. The auto-generated file is provided here as well for easy downloading:
|
||||
|
||||
{{% code file="theme.toml" download="theme.toml" %}}
|
||||
```toml
|
||||
name = ""
|
||||
license = "MIT"
|
||||
licenselink = "https://github.com/<YOURNAME>/<YOURTHEME>/blob/master/LICENSE.md"
|
||||
description = ""
|
||||
homepage = "http://yoursite.com/"
|
||||
tags = []
|
||||
features = []
|
||||
min_version = 0.19
|
||||
|
||||
[author]
|
||||
name = ""
|
||||
homepage = ""
|
||||
|
||||
# If porting an existing theme
|
||||
[original]
|
||||
name = ""
|
||||
homepage = ""
|
||||
repo = ""
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
The following fields are required:
|
||||
|
||||
```toml
|
||||
name = "Hyde"
|
||||
license = "MIT"
|
||||
licenselink = "https://github.com/spf13/hyde/blob/master/LICENSE.md"
|
||||
description = "An elegant open source and mobile first theme"
|
||||
homepage = "http://siteforthistheme.com/"
|
||||
tags = ["blog", "company"]
|
||||
features = ["blog"]
|
||||
min_version = 0.13
|
||||
|
||||
[author]
|
||||
name = "spf13"
|
||||
homepage = "http://spf13.com/"
|
||||
|
||||
# If porting an existing theme
|
||||
[original]
|
||||
author = "mdo"
|
||||
homepage = "http://hyde.getpoole.com/"
|
||||
repo = "https://www.github.com/mdo/hyde"
|
||||
```
|
||||
|
||||
{{% note %}}
|
||||
1. This is different from the `theme.toml` file created by `hugo new theme` in Hugo versions before v0.14.
|
||||
2. Only `theme.toml` is accepted; ie. not `theme.yaml` andnot `theme.json`.
|
||||
{{% /note %}}
|
||||
|
||||
### Images
|
||||
|
||||
Screenshots are used for previews in the Hugo Theme Gallery. Make sure that they have the right dimensions:
|
||||
|
||||
* Thumbnail should be 900px × 600px
|
||||
* Screenshot should be 1500px × 1000px
|
||||
* Media must be located in
|
||||
* <THEMEDIR>/images/screenshot.png</code>
|
||||
* <THEMEDIR>/images/tn.png</code>
|
||||
|
||||
Additional media may be provided in the same directory.
|
||||
|
||||
### Create a README File
|
||||
|
||||
Your theme's README file should be written in markdown and saved at the root of your theme's directory structure. Your `README.md` serves as
|
||||
|
||||
1. Content for your theme's details page at <https://themes.gohugo.io>
|
||||
2. General information about the theme in your GitHub repository (i.e., it's usual purpose)
|
||||
|
||||
#### Example `README.md`
|
||||
|
||||
You can download the following `README.md` as an outline:
|
||||
|
||||
{{% code file="README.md" download="README.md" %}}
|
||||
```markdown
|
||||
|
||||
# Theme Title
|
||||
|
||||
**Need input from @digitalcraftsman on what could be added to this file.**
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% note "Screenshots in your `README.md`"%}}
|
||||
If you add screenshots to the README, please make use of absolute file paths instead of relative ones like `/images/screenshot.png`. Relative paths work great on GitHub but they don't correspond to the directory structure of [themes.gohugo.io](http://themes.gohugo.io/). Therefore, browsers will not be able to display screenshots on the theme site under the given (relative) path.
|
||||
{{% /note %}}
|
||||
|
||||
[artistexample]: https://github.com/digitalcraftsman/hugo-artists-theme/tree/master/exampleSite
|
||||
[themeissuenew]: https://github.com/spf13/hugoThemes/issues/new
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Hugo Documentation
|
||||
linktitle: Hugo
|
||||
description: Hugo is the world's fastest static website engine. It's written in Golang and developed by spf13 and friends.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
menu:
|
||||
main:
|
||||
parent: "section name"
|
||||
weight: 01
|
||||
weight: 01 #rem
|
||||
draft: false
|
||||
slug:
|
||||
aliases: []
|
||||
toc: false
|
||||
layout: documentation-home
|
||||
---
|
||||
Hugo is the world's fastest static website engine. It's written in Golang and developed by spf13 and friends. Below you will find some of the most common and helpful pages from our documentation.
|
||||
@@ -1,99 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-08-04
|
||||
date: 2014-05-26
|
||||
linktitle: Comments
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/crossreferences
|
||||
prev: /extras/builders
|
||||
title: Comments in Hugo
|
||||
---
|
||||
|
||||
As Hugo is a static site generator, the content produced is static and doesn’t interact with the users. The most common interaction people ask for is comment capability.
|
||||
|
||||
Hugo ships with support for [Disqus](https://disqus.com/), a third-party service that provides comment and community capabilities to website via JavaScript.
|
||||
|
||||
Your theme may already support Disqus, but even it if doesn’t, it is easy to add.
|
||||
|
||||
# Disqus Support
|
||||
|
||||
## Adding Disqus to a template
|
||||
|
||||
Hugo comes with all the code you would need to include load Disqus. Simply include the following line where you want your comments to appear:
|
||||
|
||||
{{ template "_internal/disqus.html" . }}
|
||||
|
||||
## Configuring Disqus
|
||||
|
||||
That template requires you to set a single value in your site config file, e.g. config.yaml.
|
||||
|
||||
disqusShortname = "XYW"
|
||||
|
||||
Additionally, you can optionally set the following in the front matter
|
||||
for a given piece of content:
|
||||
|
||||
* **disqus_identifier**
|
||||
* **disqus_title**
|
||||
* **disqus_url**
|
||||
|
||||
## Conditional Loading of Disqus Comments
|
||||
|
||||
Users have noticed that enabling Disqus comments when running the Hugo web server on localhost causes the creation of unwanted discussions on the associated Disqus account. In order to prevent this, a slightly tweaked partial template is required. So, rather than using the built-in `"_internal/disqus.html"` template referenced above, create a template in your `partials` folder that looks like this:
|
||||
|
||||
```html
|
||||
<div id="disqus_thread"></div>
|
||||
<script type="text/javascript">
|
||||
|
||||
(function() {
|
||||
// Don't ever inject Disqus on localhost--it creates unwanted
|
||||
// discussions from 'localhost:1313' on your Disqus account...
|
||||
if (window.location.hostname == "localhost")
|
||||
return;
|
||||
|
||||
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
|
||||
var disqus_shortname = '{{ .Site.DisqusShortname }}';
|
||||
dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
|
||||
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
|
||||
})();
|
||||
</script>
|
||||
<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
|
||||
<a href="http://disqus.com/" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a>
|
||||
```
|
||||
|
||||
Notice that there is a simple `if` statement that detects when you are running on localhost and skips the initialization of the Disqus comment injection.
|
||||
|
||||
Now, reference the partial template from your page template:
|
||||
|
||||
{{ partial "disqus.html" . }}
|
||||
|
||||
|
||||
# Alternatives
|
||||
|
||||
A few alternatives exist to [Disqus](https://disqus.com/):
|
||||
|
||||
* [txtpen](https://txtpen.com)
|
||||
* [Discourse](http://www.discourse.org)
|
||||
* [IntenseDebate](http://intensedebate.com/)
|
||||
* [Livefyre](http://www.adobe.com/marketing-cloud/enterprise-content-management/ugc-content-platform.html)
|
||||
* [Muut](http://muut.com/)
|
||||
* [多说](http://duoshuo.com/) ([Duoshuo](http://duoshuo.com/), popular in China)
|
||||
* [isso](http://posativ.org/isso/) (Self-hosted, Python)
|
||||
* [Kaiju](https://github.com/spf13/kaiju)
|
||||
|
||||
## Kaiju
|
||||
|
||||
[Kaiju](https://github.com/spf13/kaiju) is an open-source project started by [spf13](http://spf13.com/) (Hugo’s author) to bring easy and fast real time discussions to the web.
|
||||
|
||||
Written using Go, Socket.io and MongoDB, it is very fast and easy to deploy.
|
||||
|
||||
It is in early development but shows promise. If you have interest, please help by contributing whether via a pull request, an issue or even just a tweet. Everything helps.
|
||||
|
||||
## txtpen
|
||||
|
||||
[txtpen](https://txtpen.com) adds highlighting an in-line commenting similar to Medium to your Hugo blog.
|
||||
|
||||
## Discourse
|
||||
|
||||
Additionally, you may recognize [Discourse](http://www.discourse.org) as the system that powers the [Hugo Discussion Forum](https://discourse.gohugo.io).
|
||||
|
||||
@@ -1,153 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-12-23
|
||||
date: 2014-11-25
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/robots-txt
|
||||
prev: /extras/comments
|
||||
title: Cross-References
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo makes it easy to link documents together with the `ref` and `relref` shortcodes. These shortcodes are also used to safely provide links to headings inside of your content, whether across documents or within a document. The only difference between `ref` and `relref` is whether the resulting URL is absolute (`http://1.com/about/`) or relative (`/about/`).
|
||||
|
||||
## Using `ref` and `relref`
|
||||
|
||||
```django
|
||||
{{</* ref "document" */>}}
|
||||
{{</* ref "#anchor" */>}}
|
||||
{{</* ref "document#anchor" */>}}
|
||||
{{</* relref "document" */>}}
|
||||
{{</* relref "#anchor" */>}}
|
||||
{{</* relref "document#anchor" */>}}
|
||||
```
|
||||
|
||||
The single parameter to `ref` is a string with a content _document name_ (`about.md`), an in-document _anchor_ (`#who`), or both (`about.md#who`).
|
||||
|
||||
### Document Names
|
||||
|
||||
The _document name_ is the name of a document including the format extension; this may be just the filename, or the relative path from the `content/` directory. With a document `content/blog/post.md`, either format will produce the same result.
|
||||
|
||||
{{</* relref "blog/post.md" */>}} ⇒ `/blog/post/`
|
||||
{{</* relref "post.md" */>}} ⇒ `/blog/post/`
|
||||
|
||||
If you have multiple sections with the same filename, you should only use the relative path format, because the behaviour is _undefined_. So, if I also have a document `link/post.md`, the output of `ref` is unknown for `post.md`.
|
||||
|
||||
{{</* relref "blog/post.md" */>}} ⇒ `/blog/post/`
|
||||
{{</* relref "post.md" */>}} ⇒ `/blog/post/` (maybe)
|
||||
{{</* relref "post.md" */>}} ⇒ `/link/post/` (maybe)
|
||||
{{</* relref "link/post.md" */>}} ⇒ `/link/post/`
|
||||
|
||||
A relative document name must *not* begin with a slash (`/`).
|
||||
|
||||
{{</* relref "/blog/post.md" */>}} ⇒ `""`
|
||||
|
||||
### Anchors
|
||||
|
||||
When an _anchor_ is provided by itself, the current page’s unique identifier will be appended; when an _anchor_ is provided with a document name, the found page's unique identifier will be appended.
|
||||
|
||||
{{</* relref "#who" */>}} ⇒ `#who:9decaf7`
|
||||
{{</* relref "blog/post.md#who" */>}} ⇒ `/blog/post/#who:badcafe`
|
||||
|
||||
More information about document unique identifiers and headings can be found [below]({{< ref "#hugo-heading-anchors" >}}).
|
||||
|
||||
### Examples
|
||||
|
||||
* `{{</* ref "blog/post.md" */>}}` ⇒ `http://1.com/blog/post/`
|
||||
* `{{</* ref "post.md#tldr" */>}}` ⇒ `http://1.com/blog/post/#tldr:caffebad`
|
||||
* `{{</* relref "post.md" */>}}` ⇒ `/blog/post/`
|
||||
* `{{</* relref "blog/post.md#tldr" */>}}` ⇒ `/blog/post/#tldr:caffebad`
|
||||
* `{{</* ref "#tldr" */>}}` ⇒ `#tldr:badcaffe`
|
||||
* `{{</* relref "#tldr" */>}}` ⇒ `#tldr:badcaffe`
|
||||
|
||||
## Hugo Heading Anchors
|
||||
|
||||
When using Markdown document types, Hugo generates heading anchors automatically. The generated anchor for this section is `hugo-heading-anchors`. Because the heading anchors are generated automatically, Hugo takes some effort to ensure that heading anchors are unique both inside a document and across the entire site.
|
||||
|
||||
Ensuring heading uniqueness across the site is accomplished with a unique identifier for each document based on its path. Unless a document is renamed or moved between sections *in the filesystem*, the unique identifier for the document will not change: `blog/post.md` will always have a unique identifier of `81df004c333b392d34a49fd3a91ba720`.
|
||||
|
||||
`ref` and `relref` were added so you can make these reference links without having to know the document’s unique identifier. (The links in document tables of contents are automatically up-to-date with this value.)
|
||||
|
||||
{{</* relref "extras/crossreferences.md#hugo-heading-anchors" */>}}
|
||||
/extras/crossreferences/#hugo-heading-anchors:77cd9ea530577debf4ce0f28c8dca242
|
||||
|
||||
> What follows is a deeper discussion of *why* and *how* Hugo generates heading anchors. It is not necessary to know this to use `ref` and `relref`, but it may be useful in understanding how some anchors may not match your expectations.
|
||||
|
||||
### How to Generate a Heading Anchor
|
||||
|
||||
Convert the text of the heading to lowercase.
|
||||
|
||||
Hugo: A Fast & Modern Static Web Engine
|
||||
hugo: a fast & modern static web engine
|
||||
|
||||
Replace anything that isn't an ASCII letter (`a-z`) or number (`0-9`) with a dash (`-`).
|
||||
|
||||
hugo: a fast & modern static web engine
|
||||
hugo--a-fast---modern-static-web-engine
|
||||
|
||||
Get rid of extra dashes.
|
||||
|
||||
hugo--a-fast---modern-static-web-engine
|
||||
hugo-a-fast-modern-static-web-engine
|
||||
|
||||
You have just converting the text of a heading to a suitable anchor. If your document has unique heading text, all of the anchors will be unique, too.
|
||||
|
||||
#### Specifying Heading Anchors
|
||||
|
||||
You can also tell Hugo to use a particular heading anchor.
|
||||
|
||||
# Hugo: A Fast & Modern Static Web Engine {#hugo-main}
|
||||
|
||||
Hugo will use `hugo-main` as the heading anchor.
|
||||
|
||||
### What About Duplicate Heading Anchors?
|
||||
|
||||
The technique outlined above works well enough, but some documents have headings with identical text, like the [shortcodes](/extras/shortcodes/) page—there are three headings with the text "Example". You can specify heading anchors manually:
|
||||
|
||||
### Example {#example-1}
|
||||
### Example {#example-2}
|
||||
### Example {#example-3}
|
||||
|
||||
It’s easy to forget to do that all the time, and Hugo is smart enough to do it for you. It just adds `-x` to the end of each heading it has already seen.
|
||||
|
||||
* `### Example` ⇒ `example`
|
||||
* `### Example` ⇒ `example-1`
|
||||
* `### Example` ⇒ `example-2`
|
||||
|
||||
Sometimes it's a little harder, but Hugo can recover from those, too, by adding more suffixes:
|
||||
|
||||
* `# Heading` ⇒ `heading`
|
||||
* `# Heading 1` ⇒ `heading-1`
|
||||
* `# Heading` ⇒ `heading-1-1`
|
||||
* `# Heading` ⇒ `heading-1-2`
|
||||
* `# Heading 1` ⇒ `heading-2`
|
||||
|
||||
This can even affect specified heading anchors that come after a generated heading anchor.
|
||||
|
||||
* `# My Heading` ⇒ `my-heading`
|
||||
* `# My Heading {#my-heading}` ⇒ `my-heading-1`
|
||||
|
||||
> This particular collision and override is unfortunate, but unavoidable because Hugo processes each heading for collision detection as it sees it during conversion.
|
||||
|
||||
This technique works well for documents rendered on individual pages, like blog posts. What about on Hugo list pages?
|
||||
|
||||
### Unique Heading Anchors in Lists
|
||||
|
||||
Hugo converts each document from Markdown independently. it doesn’t know that `blog/post.md` has an "Example" heading that will collide with the "Example" heading in `blog/post2.md`. Even if it did know this, the addition of `blog/post3.md` should not cause the anchors for the headings in the other blog posts to change.
|
||||
|
||||
Enter the document’s unique identifier. To prevent this sort of collision on
|
||||
list pages, Hugo always appends the document's to a generated heading anchor.
|
||||
So, the "Example" heading in `blog/post.md` actually turns into
|
||||
`#example:81df004…`, and the "Example" heading in `blog/post2.md` actually
|
||||
turns into `#example:8cf1599…`. All you have to know is the heading anchor that
|
||||
was generated, not the document identifier; `ref` and `relref` take care of the
|
||||
rest for you.
|
||||
|
||||
<a href='{{</* relref "blog/post.md#example" */>}}'>Post Example</a>
|
||||
<a href='/blog/post.md#81df004…'>Post Example</a>
|
||||
|
||||
[Post Two Example]({{</* relref "blog/post2.md#example" */>}})
|
||||
<a href='/blog/post2.md#8cf1599…'>Post Two Example</a>
|
||||
|
||||
Now you know.
|
||||
@@ -1,142 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/datadrivencontent/
|
||||
lastmod: 2016-03-03
|
||||
date: 2015-02-14
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/gitinfo
|
||||
prev: /extras/datafiles
|
||||
title: Data-driven Content
|
||||
toc: true
|
||||
---
|
||||
|
||||
Data-driven content with a static site generator? Yes, it is possible!
|
||||
|
||||
In addition to the [data files](/extras/datafiles/) feature, we have also
|
||||
implemented the feature "Data-driven Content", which lets you load
|
||||
any [JSON](http://www.json.org/) or
|
||||
[CSV](http://en.wikipedia.org/wiki/Comma-separated_values) file
|
||||
from nearly any resource.
|
||||
|
||||
"Data-driven Content" currently consists of two functions, `getJSON`
|
||||
and `getCSV`, which are available in **all template files**.
|
||||
|
||||
## Implementation details
|
||||
|
||||
### Calling the functions with an URL
|
||||
|
||||
In any HTML template or Markdown document, call the functions like this:
|
||||
|
||||
{{ $dataJ := getJSON "url" }}
|
||||
{{ $dataC := getCSV "separator" "url" }}
|
||||
|
||||
or, if you use a prefix or postfix for the URL, the functions
|
||||
accept [variadic arguments](http://en.wikipedia.org/wiki/Variadic_function):
|
||||
|
||||
{{ $dataJ := getJSON "url prefix" "arg1" "arg2" "arg n" }}
|
||||
{{ $dataC := getCSV "separator" "url prefix" "arg1" "arg2" "arg n" }}
|
||||
|
||||
The separator for `getCSV` must be put in the first position and can only
|
||||
be one character long.
|
||||
|
||||
All passed arguments will be joined to the final URL; for example:
|
||||
|
||||
{{ $urlPre := "https://api.github.com" }}
|
||||
{{ $gistJ := getJSON $urlPre "/users/GITHUB_USERNAME/gists" }}
|
||||
|
||||
will resolve internally to:
|
||||
|
||||
{{ $gistJ := getJSON "https://api.github.com/users/GITHUB_USERNAME/gists" }}
|
||||
|
||||
Finally, you can range over an array. This example will output the
|
||||
first 5 gists for a GitHub user:
|
||||
|
||||
<ul>
|
||||
{{ $urlPre := "https://api.github.com" }}
|
||||
{{ $gistJ := getJSON $urlPre "/users/GITHUB_USERNAME/gists" }}
|
||||
{{ range first 5 $gistJ }}
|
||||
{{ if .public }}
|
||||
<li><a href="{{ .html_url }}" target="_blank">{{ .description }}</a></li>
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</ul>
|
||||
|
||||
|
||||
### Example for CSV files
|
||||
|
||||
For `getCSV`, the one-character long separator must be placed in the
|
||||
first position followed by the URL.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Position</th>
|
||||
<th>Salary</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{{ $url := "http://a-big-corp.com/finance/employee-salaries.csv" }}
|
||||
{{ $sep := "," }}
|
||||
{{ range $i, $r := getCSV $sep $url }}
|
||||
<tr>
|
||||
<td>{{ index $r 0 }}</td>
|
||||
<td>{{ index $r 1 }}</td>
|
||||
<td>{{ index $r 2 }}</td>
|
||||
</tr>
|
||||
{{ end }}
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
The expression `{{index $r number}}` must be used to output the nth-column from
|
||||
the current row.
|
||||
|
||||
### Caching of URLs
|
||||
|
||||
Each downloaded URL will be cached in the default folder `$TMPDIR/hugo_cache/`.
|
||||
The variable `$TMPDIR` will be resolved to your system-dependent
|
||||
temporary directory.
|
||||
|
||||
With the command-line flag `--cacheDir`, you can specify any folder on
|
||||
your system as a caching directory.
|
||||
|
||||
You can also set `cacheDir` in the main configuration file.
|
||||
|
||||
If you don't like caching at all, you can fully disable caching with the
|
||||
command line flag `--ignoreCache`.
|
||||
|
||||
### Authentication when using REST URLs
|
||||
|
||||
Currently, you can only use those authentication methods that can
|
||||
be put into an URL. [OAuth](http://en.wikipedia.org/wiki/OAuth) or
|
||||
other authentication methods are not implemented.
|
||||
|
||||
### Loading local files
|
||||
|
||||
To load local files with the two functions `getJSON` and `getCSV`, the
|
||||
source files must reside within Hugo's working directory. The file
|
||||
extension does not matter but the content does.
|
||||
|
||||
It applies the same output logic as in the topic: *Calling the functions with an URL*.
|
||||
|
||||
## LiveReload
|
||||
|
||||
There is no chance to trigger a [LiveReload](/extras/livereload/) when
|
||||
the content of an URL changes. However, when a local JSON/CSV file changes,
|
||||
then a LiveReload will be triggered of course. Symlinks are not supported.
|
||||
|
||||
**URLs and LiveReload**: If you change any local file and the LiveReload
|
||||
is triggered, Hugo will either read the URL content from the cache or, if
|
||||
you have disabled the cache, Hugo will re-download the content.
|
||||
This can create huge traffic and you may also reach API limits quickly.
|
||||
|
||||
As downloading of content takes a while, Hugo stops processing
|
||||
your Markdown files until the content has been downloaded.
|
||||
|
||||
## Examples
|
||||
|
||||
- Photo gallery JSON powered: [https://github.com/pcdummy/hugo-lightslider-example](https://github.com/pcdummy/hugo-lightslider-example)
|
||||
- GitHub Starred Repositories [in a posts](https://github.com/SchumacherFM/blog-cs/blob/master/content%2Fposts%2Fgithub-starred.md) with the related [short code](https://github.com/SchumacherFM/blog-cs/blob/master/layouts%2Fshortcodes%2FghStarred.html).
|
||||
- More? Please tell us!
|
||||
@@ -1,197 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /extras/highlight/
|
||||
lastmod: 2015-10-27
|
||||
date: 2013-07-01
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/toc
|
||||
prev: /extras/shortcodes
|
||||
title: Syntax Highlighting
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo provides the ability for you to highlight source code in _two different ways_ — either pre-processed server side from your content, or to defer the processing to the client side, using a JavaScript library.
|
||||
|
||||
**The advantage of server side** is that it doesn’t depend on a JavaScript library and consequently works very well when read from an RSS feed.
|
||||
|
||||
**The advantage of client side** is that it doesn’t cost anything when building your site and some of the highlighting scripts available cover more languages than Pygments does.
|
||||
|
||||
## Server-side
|
||||
|
||||
For the pre-processed approach, highlighting is performed by an external Python-based program called [Pygments](http://pygments.org/) and is triggered via an embedded Hugo shortcode (see example below). If Pygments is absent from the path, it will silently simply pass the content along unhighlighted.
|
||||
|
||||
### Pygments
|
||||
|
||||
If you have never worked with Pygments before, here is a brief primer:
|
||||
|
||||
+ Install Python from [python.org](https://www.python.org/downloads/). Version 2.7.x is already sufficient.
|
||||
+ Run `pip install Pygments` in order to install Pygments. Once installed, Pygments gives you a command `pygmentize`. Make sure it sits in your PATH, otherwise Hugo cannot find it.
|
||||
|
||||
On Debian and Ubuntu systems, you may also install Pygments by running `sudo apt-get install python3-pygments`.
|
||||
|
||||
Hugo gives you two options that you can set with the variable `pygmentsuseclasses` (default `false`) in `config.toml` (or `config.yaml`).
|
||||
|
||||
1. Color-codes for highlighting keywords are directly inserted if `pygmentsuseclasses = false` (default). See in the example below. The color-codes depend on your choice of the `pygmentsstyle` (default `"monokai"`). You can explore the different color styles on [pygments.org](http://pygments.org/) after inserting some example code.
|
||||
2. If you choose `pygmentsuseclasses = true`, Hugo includes class names in your code instead of color-codes. For class-names to be meaningful, you need to include a `.css`-file in your website representing your color-scheme. You can either generate this `.css`-files according to this [description](http://pygments.org/docs/cmdline/) or download the standard ones from the [GitHub pygments-css repository](https://github.com/richleland/pygments-css).
|
||||
|
||||
### Usage
|
||||
|
||||
Highlighting is carried out via the in-built shortcode `highlight`. `highlight` takes exactly one required parameter of language, and requires a closing shortcode. Note that `highlight` is _not_ used for client-side javascript highlighting.
|
||||
|
||||
### Example
|
||||
|
||||
```
|
||||
{{</* highlight html */>}}
|
||||
<section id="main">
|
||||
<div>
|
||||
<h1 id="title">{{ .Title }}</h1>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
</div>
|
||||
</section>
|
||||
{{</* /highlight */>}}
|
||||
```
|
||||
|
||||
### Example Output
|
||||
|
||||
```
|
||||
<span style="color: #f92672"><section</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">"main"</span><span style="color: #f92672">></span>
|
||||
<span style="color: #f92672"><div></span>
|
||||
<span style="color: #f92672"><h1</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">"title"</span><span style="color: #f92672">></span>{{ .Title }}<span style="color: #f92672"></h1></span>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
<span style="color: #f92672"></div></span>
|
||||
<span style="color: #f92672"></section></span>
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
Options to control highlighting can be added as a quoted, comma separated key-value list as the second argument in the shortcode. The example below will highlight as language `go` with inline line numbers, with line number 2 and 3 highlighted.
|
||||
|
||||
```
|
||||
{{</* highlight go "linenos=inline,hl_lines=2 3" */>}}
|
||||
var a string
|
||||
var b string
|
||||
var c string
|
||||
var d string
|
||||
{{</* / highlight */>}}
|
||||
```
|
||||
|
||||
Supported keywords: `style`, `encoding`, `noclasses`, `hl_lines`, `linenos`. Note that `style` and `noclasses` will override the similar setting in the global config.
|
||||
|
||||
The keywords are the same you would using with Pygments from the command line, see the [Pygments doc](http://pygments.org/docs/) for more info.
|
||||
|
||||
### Code fences
|
||||
|
||||
It is also possible to add syntax highlighting with GitHub flavoured code fences. To enable this, set the `PygmentsCodeFences` to `true` in Hugo's configuration file.
|
||||
|
||||
````
|
||||
``` html
|
||||
<section id="main">
|
||||
<div>
|
||||
<h1 id="title">{{ .Title }}</h1>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
</div>
|
||||
</section>
|
||||
```
|
||||
````
|
||||
|
||||
### Disclaimers
|
||||
|
||||
* Pygments is relatively slow and _causes a performance hit when building your site_, but Hugo has been designed to cache the results to disk.
|
||||
* The caching can be turned off by setting the `--ignoreCache` flag to `true`.
|
||||
* Languages available depends on your Pygments installation.
|
||||
|
||||
## Client-side
|
||||
|
||||
Alternatively, code highlighting can be done in client-side JavaScript.
|
||||
|
||||
Client-side syntax highlighting is very simple to add. You'll need to pick
|
||||
a library and a corresponding theme. Some popular libraries are:
|
||||
|
||||
- [Highlight.js]
|
||||
- [Prism]
|
||||
- [Rainbow]
|
||||
- [Syntax Highlighter]
|
||||
- [Google Prettify]
|
||||
|
||||
### Highlight.js example
|
||||
|
||||
This example uses the popular [Highlight.js] library, hosted by [Yandex], a popular Russian search engine.
|
||||
|
||||
In your `./layouts/partials/` (or `./layouts/chrome/`) folder, depending on your specific theme, there will be a snippet that will be included in every generated HTML page, such as `header.html` or `header.includes.html`. Simply add the css and js to initialize [Highlight.js]:
|
||||
|
||||
~~~
|
||||
<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.6.0/styles/default.min.css">
|
||||
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.6.0/highlight.min.js"></script>
|
||||
<script>hljs.initHighlightingOnLoad();</script>
|
||||
~~~
|
||||
|
||||
### Prism example
|
||||
|
||||
Prism is another popular highlighter library, used on some major sites. Similar to Highlight.js, you simply load `prism.css` in your `<head>` via whatever Hugo partial template is creating that part of your pages, like so:
|
||||
|
||||
```html
|
||||
...
|
||||
<link href="/css/prism.css" rel="stylesheet" />
|
||||
...
|
||||
```
|
||||
|
||||
... and add `prism.js` near the bottom of your `<body>` tag, again in whatever Hugo partial template is appropriate for your site or theme.
|
||||
|
||||
```html
|
||||
...
|
||||
<script src="/js/prism.js"></script>
|
||||
...
|
||||
</body>
|
||||
```
|
||||
|
||||
In this example, the local paths indicate that your own copy of these files are being added to the site, typically under `./static/`.
|
||||
|
||||
### Using Client-side highlighting
|
||||
|
||||
To use client-side highlighting, most of these javascript libraries expect your code to be wrapped in semantically correct `<code>` tags, with the language expressed in a class attribute on the `<code>` tag, such as `class="language-abc"`, where the `abc` is the code the highlighter script uses to represent that language.
|
||||
|
||||
The script would be looking for classes like `language-go`, `language-html`, or `language-css`. If you look at the page's source, it would be marked up like so:
|
||||
|
||||
~~~html
|
||||
<pre>
|
||||
<code class="language-css">
|
||||
body {
|
||||
font-family: "Noto Sans", sans-serif;
|
||||
}
|
||||
</code>
|
||||
</pre>
|
||||
~~~
|
||||
|
||||
The markup in your content pages (e.g. `my-css-tutorial.md`) needs to look like the following, with the name of the language to be highlighted entered directly after the first "fence", in a fenced code block:
|
||||
|
||||
<pre><code class="language-css">~~~css
|
||||
body {
|
||||
font-family: "Noto Sans", sans-serif;
|
||||
}
|
||||
~~~</code></pre>
|
||||
|
||||
When passed through the highlighter script, it would yield something like this output when viewed on your rendered page:
|
||||
|
||||
~~~css
|
||||
body {
|
||||
font-family: "Noto Sans", sans-serif;
|
||||
}
|
||||
~~~
|
||||
|
||||
Please see individual libraries' documentation for how to implement each of the JavaScript-based libraries.
|
||||
|
||||
[Prism]: http://prismjs.com
|
||||
[Highlight.js]: http://highlightjs.org/
|
||||
[Rainbow]: http://craig.is/making/rainbows
|
||||
[Syntax Highlighter]: http://alexgorbatchev.com/SyntaxHighlighter/
|
||||
[Google Prettify]: https://github.com/google/code-prettify
|
||||
[Yandex]: http://yandex.ru/
|
||||
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/localfiles/
|
||||
lastmod: 2016-09-12
|
||||
date: 2015-06-12
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/urls
|
||||
notoc: true
|
||||
prev: /extras/toc
|
||||
title: Traversing Local Files
|
||||
---
|
||||
## Traversing Local Files
|
||||
|
||||
Using Hugo's function `readDir`,
|
||||
you can traverse your web site's files on your server.
|
||||
## Using _readDir_
|
||||
|
||||
The `readDir` function returns an array
|
||||
of [`os.FileInfo`](https://golang.org/pkg/os/#FileInfo).
|
||||
It takes a single, string argument: a path.
|
||||
This path can be to any directory of your web site
|
||||
(as found on your server's filesystem).
|
||||
|
||||
Whether the path is absolute or relative makes no difference,
|
||||
because—at least for `readDir`—the root of your web site (typically `./public/`)
|
||||
in effect becomes both:
|
||||
|
||||
1. The filesystem root; and
|
||||
1. The current working directory.
|
||||
|
||||
## New Shortcode
|
||||
|
||||
So, let's create a new shortcode using `readDir`:
|
||||
|
||||
**layouts/shortcodes/directoryindex.html**
|
||||
```html
|
||||
{{< readfile "layouts/shortcodes/directoryindex.html" >}}
|
||||
```
|
||||
For the files in any given directory,
|
||||
this shortcode usefully lists their basenames and sizes,
|
||||
while providing links to them.
|
||||
|
||||
Already—actually—this shortcode
|
||||
has been included in this very web site.
|
||||
So, let's list some of its CSS files.
|
||||
(If you click on their names, you can reveal the contents.)
|
||||
{{< directoryindex path="/static/css" pathURL="/css" >}}
|
||||
<br />
|
||||
This is the call that rendered the above output:
|
||||
```html
|
||||
{{</* directoryindex path="/static/css" pathURL="/css" */>}}
|
||||
```
|
||||
By the way,
|
||||
regarding the pathURL argument, the initial slash `/` is important.
|
||||
Otherwise, it becomes relative to the current web page.
|
||||
@@ -1,393 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-08-04
|
||||
date: 2014-05-14T02:36:37Z
|
||||
toc: true
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/pagination
|
||||
prev: /extras/livereload
|
||||
title: Menus
|
||||
---
|
||||
|
||||
Hugo has a simple yet powerful menu system that permits content to be
|
||||
placed in menus with a good degree of control without a lot of work.
|
||||
|
||||
|
||||
*TIP:* If all you want is a simple menu for your sections, see [Section Menu for "the Lazy Blogger"]({{< relref "#section-menu-for-the-lazy-blogger" >}}).
|
||||
|
||||
Some of the features of Hugo Menus:
|
||||
|
||||
* Place content in one or many menus
|
||||
* Handle nested menus with unlimited depth
|
||||
* Create menu entries without being attached to any content
|
||||
* Distinguish active element (and active branch)
|
||||
|
||||
## What is a menu?
|
||||
|
||||
A menu is a named array of menu entries accessible on the site under
|
||||
`.Site.Menus` by name. For example, if I have a menu called `main`, I would
|
||||
access it via `.Site.Menus.main`.
|
||||
|
||||
If you make use of the [multilingual feature]({{< relref "content/multilingual.md#menus">}}) you can define menus language independent.
|
||||
|
||||
A menu entry has the following properties:
|
||||
|
||||
* `URL string`
|
||||
* `Name string`
|
||||
* `Menu string`
|
||||
* `Identifier string`
|
||||
* `Pre template.HTML`
|
||||
* `Post template.HTML`
|
||||
* `Weight int`
|
||||
* `Parent string`
|
||||
* `Children Menu`
|
||||
|
||||
And the following functions:
|
||||
|
||||
* `HasChildren() bool`
|
||||
|
||||
Additionally, the `Page` object has two functions, which can be used when rendering menus:
|
||||
|
||||
* `IsMenuCurrent (menu string, menuEntry *MenuEntry ) bool`
|
||||
* `HasMenuCurrent** (menu string, menuEntry *MenuEntry) bool`
|
||||
|
||||
See [Menu Functions](#menu-functions) for explanations of these functions, and [Rendering Nested Menus](#rendering-nested-menus) for an example of their use.
|
||||
|
||||
## Adding content to menus
|
||||
|
||||
Hugo supports a couple of different methods of adding a piece of content
|
||||
to the front matter.
|
||||
|
||||
### Simple
|
||||
|
||||
If all you need to do is add an entry to a menu, the simple form works
|
||||
well.
|
||||
|
||||
**A single menu:**
|
||||
|
||||
---
|
||||
menu: "main"
|
||||
---
|
||||
|
||||
**Multiple menus:**
|
||||
|
||||
---
|
||||
menu: ["main", "footer"]
|
||||
---
|
||||
|
||||
|
||||
### Advanced
|
||||
|
||||
If more control is required, then the advanced approach gives you the
|
||||
control you want. All of the menu entry properties listed above are
|
||||
available.
|
||||
|
||||
---
|
||||
menu:
|
||||
main:
|
||||
parent: 'extras'
|
||||
weight: 20
|
||||
---
|
||||
|
||||
|
||||
## Adding (non-content) entries to a menu
|
||||
|
||||
You can also add entries to menus that aren’t attached to a piece of
|
||||
content. This takes place in the sitewide [config file](/overview/configuration/).
|
||||
|
||||
Here’s an example `config.toml`:
|
||||
|
||||
[[menu.main]]
|
||||
name = "about hugo"
|
||||
pre = "<i class='fa fa-heart'></i>"
|
||||
weight = -110
|
||||
identifier = "about"
|
||||
url = "/about/"
|
||||
[[menu.main]]
|
||||
name = "getting started"
|
||||
pre = "<i class='fa fa-road'></i>"
|
||||
weight = -100
|
||||
url = "/getting-started/"
|
||||
|
||||
And the equivalent example `config.yaml`:
|
||||
|
||||
---
|
||||
menu:
|
||||
main:
|
||||
- Name: "about hugo"
|
||||
Pre: "<i class='fa fa-heart'></i>"
|
||||
Weight: -110
|
||||
Identifier: "about"
|
||||
URL: "/about/"
|
||||
- Name: "getting started"
|
||||
Pre: "<i class='fa fa-road'></i>"
|
||||
Weight: -100
|
||||
URL: "/getting-started/"
|
||||
---
|
||||
|
||||
|
||||
**NOTE:** The URLs must be relative to the context root. If the `baseURL` is `http://example.com/mysite/`, then the URLs in the menu must not include the context root `mysite`. Using an absolute URL will overide the baseURL. If the `URL` is `http://subdomain.example.com/`, the output will be `http://subdomain.example.com`.
|
||||
|
||||
## Nesting
|
||||
|
||||
All nesting of content is done via the `parent` field.
|
||||
|
||||
The parent of an entry should be the identifier of another entry.
|
||||
Identifier should be unique (within a menu).
|
||||
|
||||
The following order is used to determine an Identifier:
|
||||
|
||||
> Name > LinkTitle > Title.
|
||||
|
||||
This means that the title will be used unless
|
||||
linktitle is present, etc. In practice Name and Identifier are never
|
||||
displayed and only used to structure relationships.
|
||||
|
||||
In this example, the top level of the menu is defined in the config file
|
||||
and all content entries are attached to one of these entries via the
|
||||
`parent` field.
|
||||
|
||||
## Rendering menus
|
||||
|
||||
Hugo makes no assumptions about how your rendered HTML will be
|
||||
structured. Instead, it provides all of the functions you will need to be
|
||||
able to build your menu however you want.
|
||||
|
||||
|
||||
The following is an example:
|
||||
|
||||
<!--sidebar start-->
|
||||
<aside>
|
||||
<div id="sidebar" class="nav-collapse">
|
||||
<!-- sidebar menu start-->
|
||||
<ul class="sidebar-menu">
|
||||
{{ $currentPage := . }}
|
||||
{{ range .Site.Menus.main }}
|
||||
{{ if .HasChildren }}
|
||||
|
||||
<li class="sub-menu{{if $currentPage.HasMenuCurrent "main" . }} active{{end}}">
|
||||
<a href="javascript:;" class="">
|
||||
{{ .Pre }}
|
||||
<span>{{ .Name }}</span>
|
||||
<span class="menu-arrow arrow_carrot-right"></span>
|
||||
</a>
|
||||
<ul class="sub">
|
||||
{{ range .Children }}
|
||||
<li{{if $currentPage.IsMenuCurrent "main" . }} class="active"{{end}}><a href="{{.URL}}"> {{ .Name }} </a> </li>
|
||||
{{ end }}
|
||||
</ul>
|
||||
{{else}}
|
||||
<li>
|
||||
<a href="{{.URL}}">
|
||||
{{ .Pre }}
|
||||
<span>{{ .Name }}</span>
|
||||
</a>
|
||||
{{end}}
|
||||
</li>
|
||||
{{end}}
|
||||
<li> <a href="https://github.com/gohugoio/hugo/issues" target="blank">Questions and Issues</a> </li>
|
||||
<li> <a href="#" target="blank">Edit this Page</a> </li>
|
||||
</ul>
|
||||
<!-- sidebar menu end-->
|
||||
</div>
|
||||
</aside>
|
||||
<!--sidebar end-->
|
||||
|
||||
> **Note**: use the `absLangURL` or `relLangURL` if your theme makes use of the [multilingual feature]({{< relref "content/multilingual.md" >}}). In contrast to `absURL` and `relURL` it adds the correct language prefix to the url. [Read more]({{< relref "templates/functions.md#urls" >}}).
|
||||
|
||||
## Section Menu for "the Lazy Blogger"
|
||||
|
||||
To enable this menu, add this to your site config, i.e. `config.toml`:
|
||||
|
||||
```
|
||||
SectionPagesMenu = "main"
|
||||
```
|
||||
|
||||
The menu name can be anything, but take a note of what it is.
|
||||
|
||||
This will create a menu with all the sections as menu items and all the sections' pages as "shadow-members". The _shadow_ implies that the pages isn't represented by a menu-item themselves, but this enables you to create a top-level menu like this:
|
||||
|
||||
```
|
||||
<nav class="sidebar-nav">
|
||||
{{ $currentPage := . }}
|
||||
{{ range .Site.Menus.main }}
|
||||
<a class="sidebar-nav-item{{if or ($currentPage.IsMenuCurrent "main" .) ($currentPage.HasMenuCurrent "main" .) }} active{{end}}" href="{{.URL}}">{{ .Name }}</a>
|
||||
{{ end }}
|
||||
</nav>
|
||||
|
||||
```
|
||||
|
||||
In the above, the menu item is marked as active if on the current section's list page or on a page in that section.
|
||||
|
||||
The above is all that's needed. But if you want custom menu items, e.g. changing weight or name, you can define them manually in the site config, i.e. `config.toml`:
|
||||
|
||||
```
|
||||
[[menu.main]]
|
||||
name = "This is the blog section"
|
||||
weight = -110
|
||||
identifier = "blog"
|
||||
url = "/blog/"
|
||||
|
||||
```
|
||||
|
||||
**Note** that the `identifier` must match the section name.
|
||||
|
||||
|
||||
|
||||
|
||||
## Menu Functions
|
||||
|
||||
Suppose you have the menu structure shown below.
|
||||
|
||||
```
|
||||
[menu.main]
|
||||
│
|
||||
├───colour
|
||||
│ │
|
||||
│ ├───warm
|
||||
│ │ ├───orange
|
||||
│ │ ├───red
|
||||
│ │ └───yellow
|
||||
│ │
|
||||
│ └───cool
|
||||
│ ├───blue
|
||||
│ ├───green
|
||||
│ └───purple
|
||||
│
|
||||
└───tool
|
||||
├───hammer
|
||||
├───shovel
|
||||
└───saw
|
||||
```
|
||||
|
||||
For each menu item, you can determine:
|
||||
|
||||
* If the menu item has any children: `.HasChildren()`
|
||||
* If the menu item is a parent of the page you are currently rendering: `.Page.HasMenuCurrent()`
|
||||
* If the menu item **is** the page you are currently rendering: `.Page.IsMenuCurrent()`
|
||||
|
||||
For example, if you are currently rendering the page `/colour/warm`, the values of `.HasChildren`, `HasMenuCurrent`, and `IsMenuCurrent` would be as shown below:
|
||||
|
||||
```
|
||||
|
||||
[menu.main] | | | |
|
||||
│ | | | |
|
||||
├───colour | HasMenuCurrent | | HasChildren |
|
||||
│ ├───<< WARM >> | | IsMenuCurrent | HasChildren |
|
||||
│ │ ├───orange | | | |
|
||||
│ │ ├───red | | | |
|
||||
│ │ └───yellow | | | |
|
||||
│ └───cool | | | HasChildren |
|
||||
│ ├───blue | | | |
|
||||
│ ├───green | | | |
|
||||
│ └───purple | | | |
|
||||
└───tool | | | HasChildren |
|
||||
├───hammer | | | |
|
||||
├───shovel | | | |
|
||||
└───saw | | | |
|
||||
```
|
||||
|
||||
## Rendering nested menus
|
||||
|
||||
Hugo supports nested menus with as many levels as you like.
|
||||
|
||||
Nested menus can be rendered using a recursive partial template, such as the example below.
|
||||
|
||||
```
|
||||
<!-- layouts/index.html, layouts/_default/single.html, ... -->
|
||||
<h1>{{ .Title }}</h1>
|
||||
<!-- Put this line in your main template, at the place where you want to
|
||||
render the menu. -->
|
||||
{{ partial "menu_include.html" . }}
|
||||
```
|
||||
|
||||
```
|
||||
<!-- layouts/partials/menu_include.html -->
|
||||
{{ partial "menu_recursive.html" (dict "menu" .Site.Menus.main "page" . "site" .Site) }}
|
||||
```
|
||||
|
||||
```
|
||||
<!-- layouts/partials/menu_recursive.html -->
|
||||
{{ $page := .page }}
|
||||
{{ $site := .site }}
|
||||
<ul>
|
||||
{{ range .menu }}
|
||||
{{ $is := $page.IsMenuCurrent "main" . }}
|
||||
{{ $has := $page.HasMenuCurrent "main" . }}
|
||||
{{ if .HasChildren }}
|
||||
<li>
|
||||
<a href="{{ .URL }}">
|
||||
{{ .Name }}
|
||||
{{ if $is }}[Is]{{ end }}
|
||||
{{ if $has }}[Has]{{ end }}
|
||||
{{ if .HasChildren }}[Children]{{ end }}
|
||||
</a>
|
||||
<!-- If the menu item has children, include this partial template again (recursively) -->
|
||||
{{ partial "menu_recursive.html" (dict "menu" .Children "page" $page "site" $site) }}
|
||||
</li>
|
||||
{{ else }}
|
||||
<li>
|
||||
<a href="{{ .URL }}">
|
||||
{{ .Name }}
|
||||
{{ if $is }}[Is]{{ end }}
|
||||
{{ if $has }}[Has]{{ end }}
|
||||
{{ if .HasChildren }}[Children]{{ end }}
|
||||
</a>
|
||||
</li>
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</ul>
|
||||
```
|
||||
|
||||
This example code renders the words `[Is]`, `[Has]`, and `[Children]` to demonstrate how the `IsMenuCurrent()`, `HasMenuCurrent()`, and `HasChildren()` functions work.
|
||||
|
||||
You can customise this example to implement features such as:
|
||||
|
||||
* Highlight the current item, by applying a CSS style:
|
||||
|
||||
<a href="{{ .URL }}"{{ if $is }} class="active"{{ end }}>
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Highlight parents of the current item, by applying a CSS style:
|
||||
|
||||
<a href="{{ .URL }}"{{ if $has }} class="parent-active"{{ end }}>
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Only render sub-menus for parents of the current menu item, and the current menu item itself:
|
||||
|
||||
{{ if or $is $has }}
|
||||
{{ partial "menu_recursive.html" (dict "menu" .Children "page" $page "site" $site) }}
|
||||
{{ end }}
|
||||
|
||||
A working example, implementing these features, is shown below.
|
||||
|
||||
```
|
||||
<!-- layouts/partials/menu_recursive.html -->
|
||||
{{ $page := .page }}
|
||||
{{ $site := .site }}
|
||||
<ul>
|
||||
<!-- Menu items sorted alphabetically by name -->
|
||||
{{ range .menu.ByName }}
|
||||
{{ $is := $page.IsMenuCurrent "main" . }}
|
||||
{{ $has := $page.HasMenuCurrent "main" . }}
|
||||
{{ if .HasChildren }}
|
||||
<li>
|
||||
<a href="{{ .URL }}" class="{{ if $is }} active{{ end }}{{ if $has }} parent-active{{ end }}">
|
||||
{{ .Name }}
|
||||
<!-- Show a » symbol if there is a sub-menu we haven't rendered -->
|
||||
{{ if not (or $is $has) }}»{{ end }}
|
||||
</a>
|
||||
<!-- Only render sub-menu for parent items and the current item -->
|
||||
{{ if or $is $has }}
|
||||
{{ partial "menu_recursive.html" (dict "menu" .Children "page" $page "site" $site) }}
|
||||
{{ end }}
|
||||
</li>
|
||||
{{ else }}
|
||||
<li>
|
||||
<a href="{{ .URL }}" class="{{ if $is }}active{{end}}">{{ .Name }}</a>
|
||||
</li>
|
||||
{{ end }}
|
||||
{{ end }}
|
||||
</ul>
|
||||
```
|
||||
@@ -1,106 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/pagination/
|
||||
lastmod: 2015-07-16
|
||||
date: 2014-01-01
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/permalinks
|
||||
prev: /extras/menus
|
||||
title: Pagination
|
||||
---
|
||||
|
||||
Hugo supports pagination for the home page, sections and taxonomies. It's built to be easy use, but with loads of flexibility when needed. The real power shines when you combine it with [`where`](/templates/functions/), with its SQL-like operators, `first` and others --- you can even [order the content](/templates/list/) the way you've become used to with Hugo.
|
||||
|
||||
## Configuration
|
||||
|
||||
Pagination can be configured in the site configuration (e.g. `config.toml`):
|
||||
|
||||
* `Paginate` (default `10`) (this setting can be overridden in the template)
|
||||
* `PaginatePath` (default `page`)
|
||||
|
||||
Setting `Paginate` to a positive value will split the list pages for the home page, sections and taxonomies into chunks of that size. But note that the generation of the pagination pages for sections, taxonomies and home page is *lazy* --- the pages will not be created if not referenced by a `.Paginator` (see below).
|
||||
|
||||
`PaginatePath` is used to adapt the `URL` to the pages in the paginator (the default setting will produce URLs on the form `/page/1/`.
|
||||
|
||||
## List the pages
|
||||
|
||||
**A `.Paginator` is provided to help building a pager menu. This is currently only relevant for the templates for the home page and the list pages (sections and taxonomies).**
|
||||
|
||||
There are two ways to configure and use a `.Paginator`:
|
||||
|
||||
1. The simplest way is just to call `.Paginator.Pages` from a template. It will contain the pages for *that page* .
|
||||
2. Select a sub-set of the pages with the available template functions and ordering options, and pass the slice to `.Paginate`, e.g. `{{ range (.Paginate ( first 50 .Data.Pages.ByTitle )).Pages }}`.
|
||||
|
||||
For a given **Page**, it's one of the options above. The `.Paginator` is static and cannot change once created.
|
||||
|
||||
The global page size setting (`Paginate`) can be overridden by providing a positive integer as the last argument. The examples below will give five items per page:
|
||||
|
||||
* `{{ range (.Paginator 5).Pages }}`
|
||||
* `{{ $paginator := .Paginate (where .Data.Pages "Type" "post") 5 }}`
|
||||
|
||||
It is also possible to use the `GroupBy` functions in combination with pagination:
|
||||
|
||||
```
|
||||
{{ range (.Paginate (.Data.Pages.GroupByDate "2006")).PageGroups }}
|
||||
```
|
||||
|
||||
## Build the navigation
|
||||
|
||||
The `.Paginator` contains enough information to build a paginator interface.
|
||||
|
||||
The easiest way to add this to your pages is to include the built-in template (with `Bootstrap`-compatible styles):
|
||||
|
||||
```
|
||||
{{ template "_internal/pagination.html" . }}
|
||||
```
|
||||
|
||||
**Note:** If you use any filters or ordering functions to create your `.Paginator` **and** you want the navigation buttons to be shown before the page listing, you must create the `.Paginator` before it's used:
|
||||
|
||||
```
|
||||
{{ $paginator := .Paginate (where .Data.Pages "Type" "post") }}
|
||||
{{ template "_internal/pagination.html" . }}
|
||||
{{ range $paginator.Pages }}
|
||||
{{ .Title }}
|
||||
{{ end }}
|
||||
```
|
||||
|
||||
Without the where-filter, the above is simpler:
|
||||
|
||||
```
|
||||
{{ template "_internal/pagination.html" . }}
|
||||
{{ range .Paginator.Pages }}
|
||||
{{ .Title }}
|
||||
{{ end }}
|
||||
```
|
||||
|
||||
If you want to build custom navigation, you can do so using the `.Paginator` object:
|
||||
|
||||
* `PageNumber`: The current page's number in the pager sequence
|
||||
* `URL`: The relative URL to the current pager
|
||||
* `Pages`: The pages in the current pager
|
||||
* `NumberOfElements`: The number of elements on this page
|
||||
* `HasPrev`: Whether there are page(s) before the current
|
||||
* `Prev`: The pager for the previous page
|
||||
* `HasNext`: Whether there are page(s) after the current
|
||||
* `Next`: The pager for the next page
|
||||
* `First`: The pager for the first page
|
||||
* `Last`: The pager for the last page
|
||||
* `Pagers`: A list of pagers that can be used to build a pagination menu
|
||||
* `PageSize`: Size of each pager
|
||||
* `TotalPages`: The number of pages in the paginator
|
||||
* `TotalNumberOfElements`: The number of elements on all pages in this paginator
|
||||
|
||||
## Additional information
|
||||
|
||||
The pages are built on the following form (`BLANK` means no value):
|
||||
|
||||
```
|
||||
[SECTION/TAXONOMY/BLANK]/index.html
|
||||
[SECTION/TAXONOMY/BLANK]/page/1/index.html => redirect to [SECTION/TAXONOMY/BLANK]/index.html
|
||||
[SECTION/TAXONOMY/BLANK]/page/2/index.html
|
||||
....
|
||||
```
|
||||
|
||||
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/permalinks/
|
||||
lastmod: 2015-01-19
|
||||
date: 2013-11-18
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/scratch
|
||||
notoc: true
|
||||
prev: /extras/pagination
|
||||
title: Permalinks
|
||||
---
|
||||
|
||||
By default, content is laid out into the target `publishdir` (public)
|
||||
namespace matching its layout within the `contentdir` hierarchy.
|
||||
The `permalinks` site configuration option allows you to adjust this on a
|
||||
per-section basis.
|
||||
This will change where the files are written to and will change the page's
|
||||
internal "canonical" location, such that template references to
|
||||
`.RelPermalink` will honour the adjustments made as a result of the mappings
|
||||
in this option.
|
||||
|
||||
For instance, if one of your sections is called `post`, and you want to adjust
|
||||
the canonical path to be hierarchical based on the year and month, then you
|
||||
might use:
|
||||
|
||||
```yaml
|
||||
permalinks:
|
||||
post: /:year/:month/:title/
|
||||
```
|
||||
|
||||
Only the content under `post/` will be so rewritten.
|
||||
A file named `content/post/sample-entry` which contains a line
|
||||
`date: 2013-11-18T19:20:00-05:00` might end up with the rendered page
|
||||
appearing at `public/2013/11/sample-entry/index.html` and be reachable via
|
||||
the URL <http://yoursite.example.com/2013/11/sample-entry/>.
|
||||
|
||||
The following is a list of values that can be used in a permalink definition.
|
||||
All references to time are dependent on the content's date.
|
||||
|
||||
* **:year** the 4-digit year
|
||||
* **:month** the 2-digit month
|
||||
* **:monthname** the name of the month
|
||||
* **:day** the 2-digit day
|
||||
* **:weekday** the 1-digit day of the week (Sunday = 0)
|
||||
* **:weekdayname** the name of the day of the week
|
||||
* **:yearday** the 1- to 3-digit day of the year
|
||||
* **:section** the content's section
|
||||
* **:title** the content's title
|
||||
* **:slug** the content's slug (or title if no slug)
|
||||
* **:filename** the content's filename (without extension)
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
lastmod: 2016-01-06
|
||||
date: 2015-12-08
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/datafiles
|
||||
prev: /extras/crossreferences
|
||||
title: Custom robots.txt
|
||||
---
|
||||
|
||||
Hugo can generate a customized [robots.txt](http://www.robotstxt.org/) in the
|
||||
[same way as any other templates]({{< ref "templates/go-templates.md" >}}).
|
||||
|
||||
To enable it, just set `enableRobotsTXT` option to `true` in the [configuration file]({{< ref "overview/configuration.md" >}}). By default, it generates a robots.txt, which allows everything, with the following content:
|
||||
|
||||
```http
|
||||
User-agent: *
|
||||
```
|
||||
|
||||
|
||||
Hugo will use the template `robots.txt` according to the following list in descending precedence:
|
||||
|
||||
* /layouts/robots.txt
|
||||
* /themes/`THEME`/layout/robots.txt
|
||||
|
||||
An example of a robots.txt layout is:
|
||||
|
||||
```http
|
||||
User-agent: *
|
||||
|
||||
{{range .Data.Pages}}
|
||||
Disallow: {{.RelPermalink}}{{end}}
|
||||
```
|
||||
|
||||
This template disallows and all the pages of the site creating one `Disallow` entry for each one.
|
||||
@@ -1,413 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
- /doc/shortcodes/
|
||||
lastmod: 2016-02-03
|
||||
date: 2013-07-01
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/highlighting
|
||||
prev: /extras/scratch
|
||||
title: Shortcodes
|
||||
toc: true
|
||||
---
|
||||
|
||||
Hugo uses Markdown for its simple content format. However, there are a lot
|
||||
of things that Markdown doesn’t support well.
|
||||
|
||||
We are unwilling to accept being constrained by our simple format. Also
|
||||
unacceptable is writing raw HTML in our Markdown every time we want to include
|
||||
unsupported content such as a video. To do so is in complete opposition to the
|
||||
intent of using a bare-bones format for our content and utilizing templates to
|
||||
apply styling for display.
|
||||
|
||||
To avoid both of these limitations, Hugo created shortcodes.
|
||||
|
||||
A shortcode is a simple snippet inside a content file that Hugo will render
|
||||
using a predefined template. Note that shortcodes will not work in template
|
||||
files---if you need a functionality like that in a template, you most likely
|
||||
want a [partial template](/templates/partials/) instead.
|
||||
|
||||
Another benefit is, you can update your shortcode with any related new classes or
|
||||
techniques, and upon generation, Hugo will easily merge in your changes. You
|
||||
avoid a possibly complicated search and replace operation.
|
||||
|
||||
## Using a shortcode
|
||||
|
||||
In your content files, a shortcode can be called by using the `{{%/* name parameters
|
||||
*/%}}` form. Shortcode parameters are space delimited. Parameters with spaces
|
||||
can be quoted.
|
||||
|
||||
The first word is always the name of the shortcode. Parameters follow the name.
|
||||
Depending upon how the shortcode is defined, the parameters may be named,
|
||||
positional or both (although you can't mix parameter types in a single call).
|
||||
The format for named parameters models that of HTML with the format
|
||||
`name="value"`.
|
||||
|
||||
Some shortcodes use or require closing shortcodes. Like HTML, the opening and closing
|
||||
shortcodes match (name only), the closing being prepended with a slash.
|
||||
|
||||
Example of a paired shortcode:
|
||||
|
||||
{{</* highlight go */>}} A bunch of code here {{</* /highlight */>}}
|
||||
|
||||
The examples above use two different delimiters, the difference being the `%` and the `<` character:
|
||||
|
||||
### Shortcodes with Markdown
|
||||
|
||||
The `%` characters indicates that the shortcode's inner content needs further processing by the page's rendering processor (i.e. Markdown), needed to get the **bold** text in the example below:
|
||||
|
||||
|
||||
{{%/* myshortcode */%}}Hello **World!**{{%/* /myshortcode */%}}
|
||||
|
||||
|
||||
### Shortcodes without Markdown
|
||||
|
||||
The `<` character indicates that the shortcode's inner content doesn't need any further rendering, this will typically be pure HTML:
|
||||
|
||||
{{</* myshortcode */>}}<p>Hello <strong>World!</strong></p>{{</* /myshortcode */>}}
|
||||
|
||||
|
||||
## Built-in Shortcodes
|
||||
|
||||
Hugo ships with a set of predefined shortcodes.
|
||||
|
||||
### highlight
|
||||
|
||||
This shortcode will convert the source code provided into syntax highlighted
|
||||
HTML. Read more on [highlighting](/extras/highlighting/).
|
||||
|
||||
#### Usage
|
||||
|
||||
`highlight` takes exactly one required parameter of _language_ and requires a
|
||||
closing shortcode.
|
||||
|
||||
#### Example
|
||||
|
||||
{{</* highlight html */>}}
|
||||
<section id="main">
|
||||
<div>
|
||||
<h1 id="title">{{ .Title }}</h1>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
</div>
|
||||
</section>
|
||||
{{</* /highlight */>}}
|
||||
|
||||
|
||||
#### Example Output
|
||||
|
||||
<span style="color: #f92672"><section</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">"main"</span><span style="color: #f92672">></span>
|
||||
<span style="color: #f92672"><div></span>
|
||||
<span style="color: #f92672"><h1</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">"title"</span><span style="color: #f92672">></span>{{ .Title }}<span style="color: #f92672"></h1></span>
|
||||
{{ range .Data.Pages }}
|
||||
{{ .Render "summary"}}
|
||||
{{ end }}
|
||||
<span style="color: #f92672"></div></span>
|
||||
<span style="color: #f92672"></section></span>
|
||||
|
||||
### figure
|
||||
|
||||
`figure` is simply an extension of the image capabilities present with Markdown.
|
||||
`figure` provides the ability to add captions, CSS classes, alt text, links etc.
|
||||
|
||||
#### Usage
|
||||
|
||||
`figure` can use the following named parameters:
|
||||
|
||||
* src
|
||||
* link
|
||||
* title
|
||||
* caption
|
||||
* class
|
||||
* attr (attribution)
|
||||
* attrlink
|
||||
* alt
|
||||
|
||||
#### Example
|
||||
|
||||
{{</* figure src="/media/spf13.jpg" title="Steve Francia" */>}}
|
||||
|
||||
#### Example output
|
||||
|
||||
<figure>
|
||||
<img src="/media/spf13.jpg" />
|
||||
<figcaption>
|
||||
<h4>Steve Francia</h4>
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
### ref, relref
|
||||
|
||||
These shortcodes will look up the pages by their relative path (e.g.,
|
||||
`blog/post.md`) or their logical name (`post.md`) and return the permalink
|
||||
(`ref`) or relative permalink (`relref`) for the found page.
|
||||
|
||||
`ref` and `relref` also make it possible to make fragmentary links that work
|
||||
for the header links generated by Hugo.
|
||||
|
||||
Read more on [cross-references]({{% ref "extras/crossreferences.md" %}}).
|
||||
|
||||
#### Usage
|
||||
|
||||
`ref` and `relref` take exactly one required parameter of _reference_.
|
||||
|
||||
#### Example
|
||||
|
||||
[Neat]({{</* ref "blog/neat.md" */>}})
|
||||
[Who]({{</* relref "about.md#who" */>}})
|
||||
|
||||
If the page exists in multiple [output formats]({{< relref "extras/output-formats.md" >}}), `ref` or `relref` can be used with a output format name:
|
||||
|
||||
[Neat]({{</* ref "blog/neat.md" "amp" */>}})
|
||||
|
||||
|
||||
#### Example Output
|
||||
|
||||
Assuming that standard Hugo pretty URLs are turned on.
|
||||
|
||||
<a href="/blog/neat">Neat</a>
|
||||
<a href="/about/#who:c28654c202e73453784cfd2c5ab356c0">Who</a>
|
||||
|
||||
### Twitter
|
||||
|
||||
You want to include a single tweet into your blog post? Everything you need is the URL of the tweet, e.g.:
|
||||
|
||||
* https://twitter.com/spf13/status/666616452582129664
|
||||
|
||||
Pass the tweet's ID from the URL as parameter to the shortcode as shown below:
|
||||
|
||||
{{</* tweet 666616452582129664 */>}}
|
||||
|
||||
### YouTube
|
||||
|
||||
This shortcode embeds a responsive video player for [YouTube](https://www.youtube.com/) videos. Only the ID of the video is required, e.g.:
|
||||
|
||||
* https://www.youtube.com/watch?v=w7Ft2ymGmfc
|
||||
|
||||
Copy the ID from behind `v=` and pass it to the shortcode:
|
||||
|
||||
{{</* youtube w7Ft2ymGmfc */>}}
|
||||
|
||||
Furthermore, you can autoplay the embedded video by setting the `autoplay` parameter to true. Remember that you can't mix named and unnamed parameters. Assign the yet unnamed video id to the parameter `id` like below too.
|
||||
|
||||
{{</* youtube id="w7Ft2ymGmfc" autoplay="true" */>}}
|
||||
|
||||
|
||||
### Vimeo
|
||||
|
||||
Adding a video from [Vimeo](https://vimeo.com/) is equivalent to the YouTube shortcode above. Extract the ID from the URL, e.g.:
|
||||
|
||||
* https://vimeo.com/channels/staffpicks/146022717
|
||||
|
||||
and pass it to the shortcode:
|
||||
|
||||
{{</* vimeo 146022717 */>}}
|
||||
|
||||
### GitHub gists
|
||||
|
||||
Including code snippets with GitHub gists while writing a tutorial is common situation bloggers face. With a given URL of the gist, e.g.:
|
||||
|
||||
* https://gist.github.com/spf13/7896402
|
||||
|
||||
pass the owner and the ID of the gist to the shortcode:
|
||||
|
||||
{{</* gist spf13 7896402 */>}}
|
||||
|
||||
If the gist contains several files and you want to quote just one of them, you can pass the filename (quoted) as an optional third argument:
|
||||
|
||||
{{</* gist spf13 7896402 "img.html" */>}}
|
||||
|
||||
### Speaker Deck
|
||||
|
||||
To embed slides from [Speaker Deck](https://speakerdeck.com/), click on "< /> Embed" (under Share right next to the template on Speaker Deck) and copy the URL, e.g.:
|
||||
|
||||
<script async class="speakerdeck-embed" data-id="4e8126e72d853c0060001f97" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>
|
||||
|
||||
Extract the value from the field `data-id` and pass it to the shortcode:
|
||||
|
||||
{{</* speakerdeck 4e8126e72d853c0060001f97 */>}}
|
||||
|
||||
### Instagram
|
||||
|
||||
If you'd like to embed photo from [Instagram](https://www.instagram.com/), all you need is photo ID from the URL, e. g.:
|
||||
|
||||
* https://www.instagram.com/p/BMokmydjG-M/
|
||||
|
||||
Pass it to the shortcode:
|
||||
|
||||
{{</* instagram BMokmydjG-M */>}}
|
||||
|
||||
Optionally, hide caption:
|
||||
|
||||
{{</* instagram BMokmydjG-M hidecaption */>}}
|
||||
|
||||
## Creating your own shortcodes
|
||||
|
||||
To create a shortcode, place a template in the layouts/shortcodes directory. The
|
||||
template name will be the name of the shortcode.
|
||||
|
||||
In creating a shortcode, you can choose if the shortcode will use _positional
|
||||
parameters_, or _named parameters_, or _both_. A good rule of thumb is that if a
|
||||
shortcode has a single required value in the case of the `youtube` example below,
|
||||
then positional works very well. For more complex layouts with optional
|
||||
parameters, named parameters work best. Allowing both types of parameters is
|
||||
useful for complex layouts where you want to set default values that can be
|
||||
overridden.
|
||||
|
||||
**Inside the template**
|
||||
|
||||
To access a parameter by position, the `.Get` method can be used:
|
||||
|
||||
{{ .Get 0 }}
|
||||
|
||||
To access a parameter by name, the `.Get` method should be utilized:
|
||||
|
||||
{{ .Get "class" }}
|
||||
|
||||
`with` is great when the output depends on a parameter being set:
|
||||
|
||||
{{ with .Get "class"}} class="{{.}}"{{ end }}
|
||||
|
||||
`.Get` can also be used to check if a parameter has been provided. This is
|
||||
most helpful when the condition depends on either one value or another...
|
||||
or both:
|
||||
|
||||
{{ or .Get "title" | .Get "alt" | if }} alt="{{ with .Get "alt"}}{{.}}{{else}}{{.Get "title"}}{{end}}"{{ end }}
|
||||
|
||||
If a closing shortcode is used, the variable `.Inner` will be populated with all
|
||||
of the content between the opening and closing shortcodes. If a closing
|
||||
shortcode is required, you can check the length of `.Inner` and provide a warning
|
||||
to the user.
|
||||
|
||||
A shortcode with `.Inner` content can be used without the inline content, and without the closing shortcode, by using the self-closing syntax:
|
||||
|
||||
{{</* innershortcode /*/>}}
|
||||
|
||||
The variable `.Params` contains the list of parameters in case you need to do
|
||||
more complicated things than `.Get`. It is sometimes useful to provide a
|
||||
flexible shortcode that can take named or positional parameters. To meet this
|
||||
need, Hugo shortcodes have a `.IsNamedParams` boolean available that can be used
|
||||
such as `{{ if .IsNamedParams }}...{{ else }}...{{ end }}`. See the
|
||||
`Single Flexible Example` below for an example.
|
||||
|
||||
You can also use the variable `.Page` to access all the normal [Page Variables](/templates/variables/).
|
||||
|
||||
A shortcodes can be nested. In a nested shortcode you can access the parent shortcode context with `.Parent`. This can be very useful for inheritance of common shortcode parameters from the root.
|
||||
|
||||
## Single Positional Example: youtube
|
||||
|
||||
{{</* youtube 09jf3ow9jfw */>}}
|
||||
|
||||
Would load the template /layouts/shortcodes/youtube.html
|
||||
|
||||
<div class="embed video-player">
|
||||
<iframe class="youtube-player" type="text/html" width="640" height="385" src="http://www.youtube.com/embed/{{ index .Params 0 }}" allowfullscreen frameborder="0">
|
||||
</iframe>
|
||||
</div>
|
||||
|
||||
This would be rendered as:
|
||||
|
||||
<div class="embed video-player">
|
||||
<iframe class="youtube-player" type="text/html"
|
||||
width="640" height="385"
|
||||
src="http://www.youtube.com/embed/09jf3ow9jfw"
|
||||
allowfullscreen frameborder="0">
|
||||
</iframe>
|
||||
</div>
|
||||
|
||||
## Single Named Example: image with caption
|
||||
|
||||
{{</* img src="/media/spf13.jpg" title="Steve Francia" */>}}
|
||||
|
||||
Would load the template /layouts/shortcodes/img.html
|
||||
|
||||
<!-- image -->
|
||||
<figure {{ with .Get "class" }}class="{{.}}"{{ end }}>
|
||||
{{ with .Get "link"}}<a href="{{.}}">{{ end }}
|
||||
<img src="{{ .Get "src" }}" {{ if or (.Get "alt") (.Get "caption") }}alt="{{ with .Get "alt"}}{{.}}{{else}}{{ .Get "caption" }}{{ end }}"{{ end }} />
|
||||
{{ if .Get "link"}}</a>{{ end }}
|
||||
{{ if or (or (.Get "title") (.Get "caption")) (.Get "attr")}}
|
||||
<figcaption>{{ if isset .Params "title" }}
|
||||
<h4>{{ .Get "title" }}</h4>{{ end }}
|
||||
{{ if or (.Get "caption") (.Get "attr")}}<p>
|
||||
{{ .Get "caption" }}
|
||||
{{ with .Get "attrlink"}}<a href="{{.}}"> {{ end }}
|
||||
{{ .Get "attr" }}
|
||||
{{ if .Get "attrlink"}}</a> {{ end }}
|
||||
</p> {{ end }}
|
||||
</figcaption>
|
||||
{{ end }}
|
||||
</figure>
|
||||
<!-- image -->
|
||||
|
||||
Would be rendered as:
|
||||
|
||||
<figure >
|
||||
<img src="/media/spf13.jpg" />
|
||||
<figcaption>
|
||||
<h4>Steve Francia</h4>
|
||||
</figcaption>
|
||||
</figure>
|
||||
|
||||
## Single Flexible Example: vimeo with defaults
|
||||
|
||||
{{</* vimeo 49718712 */>}}
|
||||
{{</* vimeo id="49718712" class="flex-video" */>}}
|
||||
|
||||
Would load the template /layouts/shortcodes/vimeo.html
|
||||
|
||||
{{ if .IsNamedParams }}
|
||||
<div class="{{ if .Get "class" }}{{ .Get "class" }}{{ else }}vimeo-container{{ end }}">
|
||||
<iframe src="//player.vimeo.com/video/{{ .Get "id" }}" allowfullscreen></iframe>
|
||||
</div>
|
||||
{{ else }}
|
||||
<div class="{{ if len .Params | eq 2 }}{{ .Get 1 }}{{ else }}vimeo-container{{ end }}">
|
||||
<iframe src="//player.vimeo.com/video/{{ .Get 0 }}" allowfullscreen></iframe>
|
||||
</div>
|
||||
{{ end }}
|
||||
|
||||
Would be rendered as:
|
||||
|
||||
<div class="vimeo-container">
|
||||
<iframe src="//player.vimeo.com/video/49718712" allowfullscreen></iframe>
|
||||
</div>
|
||||
<div class="flex-video">
|
||||
<iframe src="//player.vimeo.com/video/49718712" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## Paired Example: Highlight
|
||||
*Hugo already ships with the `highlight` shortcode*
|
||||
|
||||
{{</* highlight html */>}}
|
||||
<html>
|
||||
<body> This HTML </body>
|
||||
</html>
|
||||
{{</* /highlight */>}}
|
||||
|
||||
The template for this utilizes the following code (already included in Hugo)
|
||||
|
||||
{{ .Get 0 | highlight .Inner }}
|
||||
|
||||
And will be rendered as:
|
||||
|
||||
<div class="highlight" style="background: #272822"><pre style="line-height: 125%"><span style="color: #f92672"><html></span>
|
||||
<span style="color: #f92672"><body></span> This HTML <span style="color: #f92672"></body></span>
|
||||
<span style="color: #f92672"></html></span>
|
||||
</pre></div>
|
||||
|
||||
Please notice that this template makes use of a Hugo-specific template function
|
||||
called `highlight` which uses Pygments to add the highlighting code.
|
||||
|
||||
## Simple Single-word Example: Year
|
||||
|
||||
Let's assume you would like to have a shortcode to be replaced by the current year in your Markdown content files, for a license or copyright statement. Calling a shortcode like this:
|
||||
|
||||
{{</* year */>}}
|
||||
|
||||
... would load your one-line template ``/layouts/shortcodes/year.html``, which contains:
|
||||
|
||||
{{ .Page.Now.Year }}
|
||||
|
||||
More shortcode examples can be found at [spf13.com](https://github.com/spf13/spf13.com/tree/master/layouts/shortcodes).
|
||||
@@ -1,37 +0,0 @@
|
||||
---
|
||||
lastmod: 2015-01-27
|
||||
date: 2013-07-09
|
||||
menu:
|
||||
main:
|
||||
parent: extras
|
||||
next: /extras/localfiles
|
||||
prev: /extras/highlighting
|
||||
title: Table of Contents
|
||||
---
|
||||
|
||||
Hugo will automatically parse the Markdown for your content and create
|
||||
a Table of Contents you can use to guide readers to the sections within
|
||||
your content.
|
||||
|
||||
## Usage
|
||||
|
||||
Simply create content like you normally would with the appropriate
|
||||
headers.
|
||||
|
||||
Hugo will take this Markdown and create a table of contents stored in the
|
||||
[content variable](/layout/variables/) `.TableOfContents`
|
||||
|
||||
|
||||
## Template Example
|
||||
|
||||
This is example code of a [single.html template](/layout/content/).
|
||||
|
||||
{{ partial "header.html" . }}
|
||||
<div id="toc" class="well col-md-4 col-sm-6">
|
||||
{{ .TableOfContents }}
|
||||
</div>
|
||||
<h1>{{ .Title }}</h1>
|
||||
{{ .Content }}
|
||||
{{ partial "footer.html" . }}
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: getpage
|
||||
linktitle: GetPage
|
||||
description: Looks up the index page (`_index.md`) of a given `Kind` and `path`.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [sections,lists,indexes]
|
||||
ns:
|
||||
signature: ["GetPage TYPE PATH"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
Every `Page` has a `Kind` attribute that shows what kind of page it is. While this attribute can be used to list pages of a certain `kind` using `where`, often it can be useful to fetch a single page by its path.
|
||||
|
||||
`GetPage` looks up an index page of a given `Kind` and `path`. This method may support regular pages in the future, but currently it is a convenient way of getting the index pages, such as the homepage or a section, from a template:
|
||||
|
||||
```
|
||||
{{ with .Site.GetPage "section" "blog" }}{{ .Title }}{{ end }}
|
||||
```
|
||||
|
||||
This method wil return `nil` when no page could be found, so the above will not print anything if the blog section isn't found.
|
||||
|
||||
The valid page kinds are: *home, section, taxonomy and taxonomyTerm.*
|
||||
|
||||
## `.GetPage` Example
|
||||
|
||||
This code snippet---in the form of a [partial template][partials]---allows you to do the following:
|
||||
|
||||
1. Grab the index object of your `tags` [taxonomy][].
|
||||
2. Assign this object to a variable, `$t`
|
||||
3. Sort the terms associated with the taxonomy by popularity.
|
||||
4. Grab the top two most popular terms in the taxonomy (i.e., the two most popular tags assigned to content.
|
||||
|
||||
{{% code file="grab-top-two-tags.html" %}}
|
||||
```html
|
||||
<ul class="most-popular-tags">
|
||||
{{ $t := $.Site.GetPage "taxonomyTerm" "tags" }}
|
||||
{{ range first 2 $t.Data.Terms.ByCount }}
|
||||
<li>{{.}}</li>
|
||||
{{ end }}
|
||||
</ul>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
|
||||
[partials]: /templates/partials/
|
||||
[taxonomy]: /content-management/taxonomies/
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: numfmt
|
||||
linktitle: NumFmt
|
||||
description: "Formats a number with a given precision using the requested `decimal`, `grouping`, and `negative` characters."
|
||||
godocref: ""
|
||||
workson: []
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
tags: [numbers]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
toc: false
|
||||
ns: "lang"
|
||||
signature: ["NumFmt <decimal> <grouping> <negative> <precision> <number>"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
draft: false
|
||||
aliases: []
|
||||
comments:
|
||||
---
|
||||
|
||||
`lang.NumFmt` formats a number with a given precision using the requested `decimal`, `grouping`, and `negative` characters. The default options value is `- . ,`.
|
||||
|
||||
Numbers greater than or equal to 5 are rounded up. For example, if precision is set to `0`, `1.5` becomes `2`, and `1.4` becomes `1`.
|
||||
|
||||
```
|
||||
{{ lang.NumFmt "," "." "-" 2 12345.6789 }} → 12.345,68
|
||||
{{ lang.NumFmt "." "" "-" 6 -12345.6789 }} → -12345.678900
|
||||
{{ lang.NumFmt "." "," "-" 0 -12345.6789 }} → -12,346
|
||||
{{ -98765.4321 | lang.NumFmt "." "," "-" 2 }} → -98,765.43
|
||||
```
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: Functions Quick Reference
|
||||
linktitle: Functions Quick Reference
|
||||
description: Comprehensive list of Hugo templating functions, including basic and advanced usage examples.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
tags: []
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
weight: 01 #rem
|
||||
draft: false
|
||||
aliases: [/layout/functions/]
|
||||
---
|
||||
|
||||
Go templates are lightweight but extensible. Go itself supplies built-in functions, including comparison operators and other basic tools. These are listed in the [Go template documentation][gofuncs]. Hugo has added additional functions to the basic template logic.
|
||||
|
||||
[gofuncs]: http://golang.org/pkg/text/template/#hdr-Functions
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: abslangurl
|
||||
linktitle: absLangURL
|
||||
description: Adds the absolute URL with correct language prefix according to site configuration for multilingual.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [multilingual,i18n,urls]
|
||||
ns:
|
||||
signature: ["absLangURL INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: [relLangURL]
|
||||
deprecated: false
|
||||
aliases: []
|
||||
needsexamples: true
|
||||
---
|
||||
|
||||
Both `absLangURL` and [`relLangURL`](/functions/rellangurl/) are similar to their [`absURL`](/functions/absurl/) and [`relURL`](/functions/relurl) relatives but will add the correct language prefix when the site is configured with more than one language.
|
||||
|
||||
So for a site `baseURL` set to `http://yoursite.com/hugo/` and the current language is `en`:
|
||||
|
||||
```golang
|
||||
{{ "blog/" | absLangURL }} → "http://yoursite.com/hugo/en/blog/"
|
||||
{{ "blog/" | relLangURL }} → "/hugo/en/blog/"
|
||||
```
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: absurl
|
||||
linktitle: absURL
|
||||
description: Given a string, prepends the full absolute URL according to position in file structure and the configured baseURL.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [urls]
|
||||
ns:
|
||||
signature: ["absURL INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: [relURL]
|
||||
deprecated: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
Both `absURL` and `relURL` consider the configured value of `baseURL` in your site's [`config` file][configuration]. Given a `baseURL` set to `http://yoursite.com/hugo/`:
|
||||
|
||||
```golang
|
||||
{{ "mystyle.css" | absURL }} → "http://yoursite.com/hugo/mystyle.css"
|
||||
{{ "mystyle.css" | relURL }} → "/hugo/mystyle.css"
|
||||
{{ "http://gohugo.io/" | relURL }} → "http://gohugo.io/"
|
||||
{{ "http://gohugo.io/" | absURL }} → "http://gohugo.io/"
|
||||
```
|
||||
|
||||
The last two examples may look strange but can be very useful. For example, the following shows how to use `absURL` in [JSON-LD structured data (SEO)][jsonld], where some of your images for a piece of content may or may not be hosted locally:
|
||||
|
||||
{{% code file="layouts/partials/schemaorg-metadata.html" download="schemaorg-metadata.html" %}}
|
||||
```html
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context" : "http://schema.org",
|
||||
"@type" : "BlogPosting",
|
||||
"image" : {{ apply .Params.images "absURL" "." }}
|
||||
}
|
||||
</script>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
The above uses the [apply function][] and also exposes how the Go template parser JSON-encodes objects inside `<script>` tags. See [the safeJS template function][safejs] for examples of how to tell Hugo not to escape strings inside of such tags.
|
||||
|
||||
{{% note "Ending Slash" %}}
|
||||
`absURL` and `relURL` are smart about missing slashes, but they will *not* add a closing slash to a URL if it is not present.
|
||||
{{% /note %}}
|
||||
|
||||
[apply function]: /functions/apply/
|
||||
[configuration]: /getting-started/configuration/
|
||||
[jsonld]: https://developers.google.com/search/docs/guides/intro-structured-data
|
||||
[safejs]: /functions/safejs
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: adddate
|
||||
linktitle: AddDate
|
||||
description: Returns the time corresponding to adding the given number of years, months, and days passed to the function.
|
||||
godocref: https://golang.org/pkg/time/#Time.AddDate
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [dates,time]
|
||||
ns:
|
||||
signature: ["AddDate YEARS MONTHS DAYS"]
|
||||
workson: [times]
|
||||
hugoversion:
|
||||
relatedfuncs: [now]
|
||||
deprecated: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
|
||||
The `AddDate` function takes three arguments in logical order of `years`, `months`, and `days`.
|
||||
|
||||
## Example: Randomized Tweets from the Last 2 Years
|
||||
|
||||
Let's assume you have a file at `data/tweets.toml` that contains a list of Tweets to display on your site's homepage. The file is filled with `[[tweet]]` blocks; e.g.---
|
||||
|
||||
```toml
|
||||
[[tweet]]
|
||||
name = "Steve Francia"
|
||||
twitter_handle = "@spf13"
|
||||
quote = "I'm creator of Hugo. #metadocreference"
|
||||
link = "https://twitter.com/spf13"
|
||||
date = "2017-01-07T00:00:00Z"
|
||||
```
|
||||
|
||||
Let's assume you want to grab Tweets from the last two years and present them in a random order. In conjunction with the [`where`](/functions/where/) and [`now`](/functions/now/) functions, you can limit our range to the last two years via `now.AddDate -2 0 0`, which represents a point in time 2 years, 0 days, and 0 hours before the time of your last site build.
|
||||
|
||||
{{% code file="partials/templates/random-tweets.html" download="tweets.html" %}}
|
||||
```html
|
||||
{{ range where $.Site.Data.tweets.tweet "date" "ge" (now.AddDate -2 0 0) | shuffle }}
|
||||
<div class="item">
|
||||
<blockquote>
|
||||
<p>
|
||||
{{ .quote | safeHTML }}
|
||||
</p>
|
||||
— {{ .name }} ({{ .twitter_handle }}) <a href="{{ .link }}">
|
||||
{{ dateFormat "January 2, 2006" .date }}
|
||||
</a>
|
||||
</blockquote>
|
||||
</div>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
@@ -0,0 +1,70 @@
|
||||
---
|
||||
title: after
|
||||
linktitle: after
|
||||
description: Slices an array to only the items after the Nth item.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [iteration]
|
||||
ns:
|
||||
signature: ["after INDEX COLLECTION"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: [last,first,seq]
|
||||
deprecated: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
`after` slices an array to only the items after the <em>N</em>th item. The following shows `after` being used in conjunction with the [`slice` function][slice]:
|
||||
|
||||
```html
|
||||
{{ $data := slice "one" "two" "three" "four" }}
|
||||
{{ range after 2 $data }}
|
||||
{{ . }}
|
||||
{{ end }}
|
||||
→ ["three", "four"]
|
||||
```
|
||||
|
||||
## Example of `after` with `first`: 2nd–4th Most Recent Articles
|
||||
|
||||
You can use `after` in combination with the [`first` function][] and Hugo's [powerful sorting methods][lists]. Let's assume you have a list page at `yoursite.com/articles`. You have 10 articles, but you want your templating for the [list/section page][] to show only two rows:
|
||||
|
||||
1. The top row is titled "Featured" and shows only the most recently published article (i.e. by `publishdate` in the content files' front matter).
|
||||
2. The second row is titled "Recent Articles" and shows only the 2nd- to 4th-most recently published articles.
|
||||
|
||||
{{% code file="layouts/section/articles.html" download="articles.html" %}}
|
||||
```html
|
||||
{{ define "main" }}
|
||||
<section class="row featured-article">
|
||||
<h2>Featured Article</h2>
|
||||
{{ range first 1 .Data.Pages.ByPublishDate.Reverse }}
|
||||
<header>
|
||||
<h3><a href="{{.Permalink}}">{{.Title}}</a></h3>
|
||||
</header>
|
||||
<p>{{.Description}}</p>
|
||||
{{ end }}
|
||||
</section>
|
||||
<div class="row recent-articles">
|
||||
<h2>Recent Articles</h2>
|
||||
{{ range first 3 (after 1 .Data.Pages.ByPublishDate.Reverse) }}
|
||||
<section class="recent-article">
|
||||
<header>
|
||||
<h3><a href="{{.Permalink}}">{{.Title}}</a></h3>
|
||||
</header>
|
||||
<p>{{.Description}}</p>
|
||||
</section>
|
||||
{{ end }}
|
||||
</div>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
[`first` function]: /functions/first/
|
||||
[list/section page]: /templates/section-templates/
|
||||
[lists]: /lists/
|
||||
[slice]: /functions/slice/
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
title: apply
|
||||
linktitle: apply
|
||||
description: Given a map, array, or slice, `description` returns a new slice with a function applied over it.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [advanced]
|
||||
ns:
|
||||
signature: ["apply COLLETION FUNCTION [PARAM...]"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
draft: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
<!-- POTENTIAL NEW CONTENT: see apply/sequence discussion: https://discourse.gohugo.io/t/apply-printf-on-a-sequence/5722; -->
|
||||
|
||||
Given a map, array, or slice, `apply` returns a new slice with a function applied over it. `apply` expects at least three parameters, depending on the function being applied.
|
||||
|
||||
1. The first parameter is the sequence to operate on
|
||||
2. The second parameter is the name of the function as a string, which must be the name of a valid [Hugo function][functions].
|
||||
3. After that, the parameters to the applied function are provided, with the string `"."` standing in for each element of the sequence the function is to be applied against.
|
||||
|
||||
Here is an example of a content file with `name:` as a front matter field:
|
||||
|
||||
```toml
|
||||
+++
|
||||
names: [ "Derek Perkins", "Joe Bergevin", "Tanner Linsley" ]
|
||||
+++
|
||||
```
|
||||
|
||||
You can then use `apply` as follows:
|
||||
|
||||
```golang
|
||||
{{ apply .Params.names "urlize" "." }}
|
||||
```
|
||||
|
||||
Which will result as follows:
|
||||
|
||||
```
|
||||
"derek-perkins", "joe-bergevin", "tanner-linsley"
|
||||
```
|
||||
|
||||
This is *roughly* equivalent to using the following with [range][]
|
||||
|
||||
```golang
|
||||
{{ range .Params.names }}{{ . | urlize }}{{ end }}
|
||||
```
|
||||
|
||||
However, it isn’t possible to provide the output of a range to the [`delimit` function][delimit], so you need to `apply` it.
|
||||
|
||||
If you have `post-tag-list.html` and `post-tag-link.html` as [partials][], you *could* use the following snippets, respectively:
|
||||
|
||||
{{% code file="layouts/partial/post-tag-list.html" copy="false" %}}
|
||||
```html
|
||||
{{ with .Params.tags }}
|
||||
<div class="tags-list">
|
||||
Tags:
|
||||
{{ $len := len . }}
|
||||
{{ if eq $len 1 }}
|
||||
{{ partial "post/tag/link" (index . 0) }}
|
||||
{{ else }}
|
||||
{{ $last := sub $len 1 }}
|
||||
{{ range first $last . }}
|
||||
{{ partial "post/tag/link" . }},
|
||||
{{ end }}
|
||||
{{ partial "post/tag/link" (index . $last) }}
|
||||
{{ end }}
|
||||
</div>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% code file="layouts/partial/post-tag-link.html" copy="false" %}}
|
||||
```html
|
||||
<a class="post-tag post-tag-{{ . | urlize }}" href="/tags/{{ . | urlize }}">{{ . }}</a>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
This works, but the complexity of `post-tag-list.html` is fairly high. The Hugo template needs to perform special behavior for the case where there’s only one tag, and it has to treat the last tag as special. Additionally, the tag list will be rendered something like `Tags: tag1 , tag2 , tag3` because of the way that the HTML is generated and then interpreted by a browser.
|
||||
|
||||
This first version of `layouts/partials/post-tag-list.html` separates all of the operations for ease of reading. The combined and DRYer version is shown next:
|
||||
|
||||
```html
|
||||
{{ with .Params.tags }}
|
||||
<div class="tags-list">
|
||||
Tags:
|
||||
{{ $sort := sort . }}
|
||||
{{ $links := apply $sort "partial" "post-tag-link" "." }}
|
||||
{{ $clean := apply $links "chomp" "." }}
|
||||
{{ delimit $clean ", " }}
|
||||
</div>
|
||||
{{ end }}
|
||||
```
|
||||
|
||||
Now in the completed version, you can sort the tags, convert the tags to links with `layouts/partials/post-tag-link.html`, [chomp][] off stray newlines, and join the tags together in a delimited list for presentation. Here is an even DRYer version of the preceding example:
|
||||
|
||||
{{% code file="layouts/partials/post-tag-list.html" download="post-tag-list.html" %}}
|
||||
```html
|
||||
{{ with .Params.tags }}
|
||||
<div class="tags-list">
|
||||
Tags:
|
||||
{{ delimit (apply (apply (sort .) "partial" "post-tag-link" ".") "chomp" ".") ", " }}
|
||||
</div>
|
||||
{{ end }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% note %}}
|
||||
`apply` does not work when receiving the sequence as an argument through a pipeline.
|
||||
{{% /note %}}
|
||||
|
||||
[chomp]: /functions/chomp/ "See documentation for the chomp function"
|
||||
[delimit]: /functions/delimit/ "See documentation for the delimit function"
|
||||
[functions]: /functions/ "See the full list of Hugo functions to see what can be passed as an argument to the apply function."
|
||||
[partials]: /templates/partials/
|
||||
[range]: /functions/range/ "Learn the importance of the range function, a fundamental keyword in both Hugo templates and the Go programming language."
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: base64
|
||||
linktitle: base64
|
||||
description: base64Encode and base64Decode let you easily decode content with a base64 encoding and vice versa through pipes.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: []
|
||||
relatedfuncs: []
|
||||
ns:
|
||||
signature: ["base64Decode INPUT", "base64Encode INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
deprecated: false
|
||||
draft: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
`base64Encode` and `base64Decode` let you easily decode content with a base64 encoding and vice versa through pipes. Let's take a look at an example:
|
||||
|
||||
{{% code file="base64-input.html" %}}
|
||||
```html
|
||||
<p>Hello world = {{ "Hello world" | base64Encode }}</p>
|
||||
<p>SGVsbG8gd29ybGQ = {{ "SGVsbG8gd29ybGQ=" | base64Decode }}</p>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% output file="base-64-output.html" %}}
|
||||
```html
|
||||
<p>Hello world = SGVsbG8gd29ybGQ=</p>
|
||||
<p>SGVsbG8gd29ybGQ = Hello world</p>
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
You can also pass other data types as arguments to the template function which tries to convert them. The following will convert *42* from an integer to a string because both `base64Encode` and `base64Decode` always return a string.
|
||||
|
||||
```
|
||||
{{ 42 | base64Encode | base64Decode }}
|
||||
=> "42" rather than 42
|
||||
```
|
||||
|
||||
## `base64` with APIs
|
||||
|
||||
Using base64 to decode and encode becomes really powerful if we have to handle
|
||||
responses from APIs.
|
||||
|
||||
```golang
|
||||
{{ $resp := getJSON "https://api.github.com/repos/spf13/hugo/readme" }}
|
||||
{{ $resp.content | base64Decode | markdownify }}
|
||||
```
|
||||
|
||||
The response of the GitHub API contains the base64-encoded version of the [README.md](https://github.com/spf13/hugo/blob/master/README.md) in the Hugo repository. Now we can decode it and parse the Markdown. The final output will look similar to the rendered version on GitHub.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: chomp
|
||||
linktitle: chomp
|
||||
description: Removes any trailing newline characters.
|
||||
godocref: Removes any trailing newline characters.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [trim]
|
||||
ns:
|
||||
signature: ["chomp INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: [truncate]
|
||||
deprecated: false
|
||||
---
|
||||
|
||||
Removes any trailing newline characters. Useful in a pipeline to remove newlines added by other processing (e.g., [`markdownify`](/functions/markdownify/)).
|
||||
|
||||
```golang
|
||||
{{chomp "<p>Blockhead</p>\n"}} → "<p>Blockhead</p>"
|
||||
```
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: countrunes
|
||||
linktitle: countrunes
|
||||
description: Determines the number of runes in a string and excludes any whitespace.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [counting, word count]
|
||||
ns:
|
||||
signature: ["countrunes INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
aliases: [/functions/countrunes/,/functions/countwords/]
|
||||
---
|
||||
|
||||
In contrast with `countwords` function, which counts every word in a string, the `countrunes` function determines the number of runes in the content and excludes any whitespace. This has specific utility if you are dealing with CJK-like languages.
|
||||
|
||||
```html
|
||||
{{ "Hello, 世界" | countrunes }}
|
||||
<!-- outputs a content length of 8 runes. -->
|
||||
```
|
||||
|
||||
[pagevars]: /variables/page/
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: countwords
|
||||
linktitle: countwords
|
||||
description: Counts the number of words in a string that has been passed to it.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [counting, word count]
|
||||
ns:
|
||||
signature: ["countwords INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: [countrunes]
|
||||
deprecated: false
|
||||
aliases: [/functions/countrunes/,/functions/countwords/]
|
||||
---
|
||||
|
||||
`countwords` tries to convert the passed content to a string and counts each word in it. The template function works similar to the [.WordCount page variable][pagevars].
|
||||
|
||||
```html
|
||||
{{ "Hugo is a static site generator." | countwords }}
|
||||
<!-- outputs a content length of 6 words. -->
|
||||
```
|
||||
|
||||
|
||||
[pagevars]: /variables/page/
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: dateFormat
|
||||
linktitle:
|
||||
description: Converts the textual representation of the `datetime` into the specified format.
|
||||
godocref: https://golang.org/pkg/time/
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [dates,time,strings]
|
||||
ns:
|
||||
signature: ["dateFormat LAYOUT INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: [Format,now,Unix,time]
|
||||
deprecated: false
|
||||
---
|
||||
|
||||
`dateFormat` converts the textual representation of the `datetime` into the specified format or returns it as a Go `time.Time` type value. These are formatted with the layout string.
|
||||
|
||||
```
|
||||
{{ dateFormat "Monday, Jan 2, 2006" "2015-01-21" }} → "Wednesday, Jan 21, 2015"
|
||||
```
|
||||
|
||||
{{% warning %}}
|
||||
As of v0.19 of Hugo, the `dateFormat` function is *not* supported as part of Hugo's [multilingual feature](/content-management/multilingual/).
|
||||
{{% /warning %}}
|
||||
|
||||
See the [`Format` function](/functions/format/) for a more complete list of date formatting options in your templates.
|
||||
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
title: default
|
||||
linktitle: default
|
||||
description: Allows setting a default value that can be returned if a first value is not set.
|
||||
qref: "Returns a default value if a value is not set when checked."
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
tags: [defaults]
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
toc:
|
||||
ns:
|
||||
signature: ["default DEFAULT INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
draft: false
|
||||
aliases: [/functions/default/]
|
||||
needsexamples: false
|
||||
---
|
||||
|
||||
`default` checks whether a given value is set and returns a default value if it is not. *Set* in this context means different things depending on date type:
|
||||
|
||||
* non-zero for numeric types and times
|
||||
* non-zero length for strings, arrays, slices, and maps
|
||||
* any boolean or struct value
|
||||
* non-nil for any other types
|
||||
|
||||
`default` function examples reference the following content page:
|
||||
|
||||
{{% code file="content/posts/default-function-example.md" %}}
|
||||
```yaml
|
||||
---
|
||||
title: Sane Defaults
|
||||
seo_title:
|
||||
date: 2017-02-18
|
||||
font:
|
||||
oldparam: The default function helps make your templating DRYer.
|
||||
newparam:
|
||||
---
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
`default` can be written in more than one way:
|
||||
|
||||
```golang
|
||||
{{ index .Params "font" | default "Roboto" }}
|
||||
{{ default "Roboto" (index .Params "font") }}
|
||||
```
|
||||
|
||||
Both of the above `default` function calls return `Roboto`.
|
||||
|
||||
A `default` value, however, does not need to be hard coded like the previous example. The `default` value can be a variable or pulled directly from the front matter using dot notation:
|
||||
|
||||
{{% code file="variable-as-default-value.html" nocopy="true" %}}
|
||||
```golang
|
||||
{{$old := .Params.oldparam }}
|
||||
<p>{{ .Params.newparam | default $old }}</p>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Which would return:
|
||||
|
||||
```
|
||||
<p>The default function helps make your templating DRYer.</p>
|
||||
```
|
||||
|
||||
And then using dot notation
|
||||
|
||||
{{% code file="dot-notation-default-value.html" %}}
|
||||
```golang
|
||||
<title>{{ .Params.seo_title | default .Title }}</title>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Which would return
|
||||
|
||||
{{% output file="dot-notation-default-return-value.html" %}}
|
||||
```html
|
||||
<title>Sane Defaults</title>
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
The following have equivalent return values but are far less terse. This demonstrates the utility of `default`:
|
||||
|
||||
Using `if`:
|
||||
|
||||
{{% code file="if-instead-of-default.html" nocopy="true" %}}
|
||||
```golang
|
||||
<title>{{if .Params.seo_title}}{{.Params.seo_title}}{{else}}{{.Title}}{{end}}</title>
|
||||
=> Sane Defaults
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
Using `with`:
|
||||
|
||||
{{% code file="with-instead-of-default.html" nocopy="true" %}}
|
||||
```golang
|
||||
<title>{{with .Params.seo_title}}{{.}}{{else}}{{.Title}}{{end}}</title>
|
||||
=> Sane Defaults
|
||||
```
|
||||
{{% /code %}}
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: delimit
|
||||
linktitle: delimit
|
||||
description: Loops through any array, slice, or map and returns a string of all the values separated by a delimiter.
|
||||
godocref:
|
||||
workson: []
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [iteration]
|
||||
toc: false
|
||||
ns:
|
||||
signature: ["delimit COLLECTION DELIMIT LAST"]
|
||||
workson: [lists,taxonomies,terms]
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
draft: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
`delimit` called in your template takes the form of
|
||||
|
||||
```
|
||||
{{ delimit array/slice/map delimiter optionallastdelimiter}}
|
||||
```
|
||||
|
||||
`delimit` loops through any array, slice, or map and returns a string of all the values separated by a delimiter, the second argument in the function call. There is an optional third parameter that lets you choose a different delimiter to go between the last two values in the loop.
|
||||
|
||||
To maintain a consistent output order, maps will be sorted by keys and only a slice of the values will be returned.
|
||||
|
||||
The examples of `delimit` that follow all use the same front matter:
|
||||
|
||||
{{% code file="delimit-example-front-matter.toml" nocopy="true" %}}
|
||||
```toml
|
||||
+++
|
||||
title: I love Delimit
|
||||
tags: [ "tag1", "tag2", "tag3" ]
|
||||
+++
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% code file="delimit-page-tags-input.html" %}}
|
||||
```html
|
||||
<p>Tags: {{ delimit .Params.tags ", " }}</p>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% output file="delimit-page-tags-output.html" %}}
|
||||
```html
|
||||
<p>Tags: tag1, tag2, tag3</p>
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
Here is the same example but with the optional "last" delimiter:
|
||||
|
||||
{{% code file="delimit-page-tags-final-and-input.html" %}}
|
||||
```golang
|
||||
Tags: {{ delimit .Params.tags ", " ", and " }}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
{{% output file="delimit-page-tags-final-and-output.html" %}}
|
||||
```html
|
||||
<p>Tags: tag1, tag2, and tag3</p>
|
||||
```
|
||||
{{% /output %}}
|
||||
|
||||
|
||||
[lists]: /templates/lists/
|
||||
[taxonomies]: /templates/taxonomy-templates/#taxonomy-list-templates
|
||||
[terms]: /templates/taxonomy-templates/#terms-list-templates
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
title: dict
|
||||
linktitle: dict
|
||||
description: Creates a dictionary `(map[string, interface{})` that expects parameters added in a value:object fashion.
|
||||
godocref:
|
||||
workson: []
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-26
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [dictionary]
|
||||
ns:
|
||||
signature: ["dict KEY VALUE [KEY VALUE]..."]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
aliases: []
|
||||
needsexamples: true
|
||||
---
|
||||
|
||||
`dict` creates a dictionary `(map[string, interface{})` that expects parameters added in a value:object fashion.
|
||||
|
||||
Invalid combinations---e.g., keys that are not strings or an uneven number of parameters---will result in an exception being thrown. `dict` is especially useful for passing maps to partials being added to a template.
|
||||
|
||||
For example, the following snippet passes a map with the keys "important, content" into "foo.html"
|
||||
|
||||
{{% code file="dict-example.html" %}}
|
||||
```html
|
||||
{{$important := .Site.Params.SomethingImportant }}
|
||||
{{range .Site.Params.Bar}}
|
||||
{{partial "foo" (dict "content" . "important" $important)}}
|
||||
{{end}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
These keys can then be called in `foo.html` as follows:
|
||||
|
||||
```golang
|
||||
Important {{.important}}
|
||||
{{.content}}
|
||||
```
|
||||
|
||||
`dict` also allows you to create a map on the fly to pass into your [partial templates][partials]:
|
||||
|
||||
{{% code file="dict-create-map.html" %}}
|
||||
```golang
|
||||
{{partial "foo" (dict "important" "Smiles" "content" "You should do more")}}
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
## Example: `dict` with Embedded SVGs
|
||||
|
||||
Let's suppose you want to pass values into embedded SVG icons on the fly in your template without having to change your CSS. The following is the XML for an "external link" SVG icon:
|
||||
|
||||
{{% code file="layouts/partials/svgs/external-links.svg" copy="false" %}}
|
||||
```xml
|
||||
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="#000000" width="40" height="40" viewBox="0 0 32 32" aria-label="External Link">
|
||||
<path d="M25.152 16.576v5.696q0 2.144-1.504 3.648t-3.648 1.504h-14.848q-2.144 0-3.648-1.504t-1.504-3.648v-14.848q0-2.112 1.504-3.616t3.648-1.536h12.576q0.224 0 0.384 0.16t0.16 0.416v1.152q0 0.256-0.16 0.416t-0.384 0.16h-12.576q-1.184 0-2.016 0.832t-0.864 2.016v14.848q0 1.184 0.864 2.016t2.016 0.864h14.848q1.184 0 2.016-0.864t0.832-2.016v-5.696q0-0.256 0.16-0.416t0.416-0.16h1.152q0.256 0 0.416 0.16t0.16 0.416zM32 1.152v9.12q0 0.48-0.352 0.8t-0.8 0.352-0.8-0.352l-3.136-3.136-11.648 11.648q-0.16 0.192-0.416 0.192t-0.384-0.192l-2.048-2.048q-0.192-0.16-0.192-0.384t0.192-0.416l11.648-11.648-3.136-3.136q-0.352-0.352-0.352-0.8t0.352-0.8 0.8-0.352h9.12q0.48 0 0.8 0.352t0.352 0.8z"></path>
|
||||
</svg>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
You can then call this [partial template][partials] using `{{ partial "svgs/external-links.svg" . }}`, but what if you want to pass specific values such as `fill` `height` and `width` into the icon? To allow for more flexibility, you can abstract these values into variables that you will later define when calling the partial template:
|
||||
|
||||
{{% code file="layouts/partials/svgs/external-links.svg" download="external-links.svg" %}}
|
||||
```xml
|
||||
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="{{ .fill }}" width="{{ .size }}" height="{{ .size }}" viewBox="0 0 32 32" aria-label="External Link">
|
||||
<path d="M25.152 16.576v5.696q0 2.144-1.504 3.648t-3.648 1.504h-14.848q-2.144 0-3.648-1.504t-1.504-3.648v-14.848q0-2.112 1.504-3.616t3.648-1.536h12.576q0.224 0 0.384 0.16t0.16 0.416v1.152q0 0.256-0.16 0.416t-0.384 0.16h-12.576q-1.184 0-2.016 0.832t-0.864 2.016v14.848q0 1.184 0.864 2.016t2.016 0.864h14.848q1.184 0 2.016-0.864t0.832-2.016v-5.696q0-0.256 0.16-0.416t0.416-0.16h1.152q0.256 0 0.416 0.16t0.16 0.416zM32 1.152v9.12q0 0.48-0.352 0.8t-0.8 0.352-0.8-0.352l-3.136-3.136-11.648 11.648q-0.16 0.192-0.416 0.192t-0.384-0.192l-2.048-2.048q-0.192-0.16-0.192-0.384t0.192-0.416l11.648-11.648-3.136-3.136q-0.352-0.352-0.352-0.8t0.352-0.8 0.8-0.352h9.12q0.48 0 0.8 0.352t0.352 0.8z"></path>
|
||||
</svg>
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
You can then pass these values to customize the SVG by calling the partials with `dict`:
|
||||
|
||||
{{% code file="layouts/_default/list.html" %}}
|
||||
```html
|
||||
...
|
||||
{{ partial "svg/link-ext.svg" (dict "fill" "#01589B" "size" "10") }}
|
||||
...
|
||||
```
|
||||
{{% /code %}}
|
||||
|
||||
The above partial will generate the following code when Hugo builds your site:
|
||||
|
||||
```html
|
||||
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill="#01589B" width="10" height="10" viewBox="0 0 32 32" aria-label="External Link">
|
||||
<path d="M25.152 16.576v5.696q0 2.144-1.504 3.648t-3.648 1.504h-14.848q-2.144 0-3.648-1.504t-1.504-3.648v-14.848q0-2.112 1.504-3.616t3.648-1.536h12.576q0.224 0 0.384 0.16t0.16 0.416v1.152q0 0.256-0.16 0.416t-0.384 0.16h-12.576q-1.184 0-2.016 0.832t-0.864 2.016v14.848q0 1.184 0.864 2.016t2.016 0.864h14.848q1.184 0 2.016-0.864t0.832-2.016v-5.696q0-0.256 0.16-0.416t0.416-0.16h1.152q0.256 0 0.416 0.16t0.16 0.416zM32 1.152v9.12q0 0.48-0.352 0.8t-0.8 0.352-0.8-0.352l-3.136-3.136-11.648 11.648q-0.16 0.192-0.416 0.192t-0.384-0.192l-2.048-2.048q-0.192-0.16-0.192-0.384t0.192-0.416l11.648-11.648-3.136-3.136q-0.352-0.352-0.352-0.8t0.352-0.8 0.8-0.352h9.12q0.48 0 0.8 0.352t0.352 0.8z"></path>
|
||||
</svg>
|
||||
```
|
||||
|
||||
|
||||
[partials]: /templates/partials/
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: echoparam
|
||||
linktitle: echoParam
|
||||
description: Prints a parameter if it is set.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: []
|
||||
ns:
|
||||
signature: ["echoParam DICTIONARY KEY"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
draft: false
|
||||
aliases: []
|
||||
---
|
||||
|
||||
`echoParam` prints a parameter if it is set.
|
||||
|
||||
```
|
||||
{{ echoParam .Params "project_url" }}
|
||||
```
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: emojify
|
||||
linktitle:
|
||||
description: Runs a string through the Emoji emoticons processor.
|
||||
godocref:
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
lastmod: 2017-02-01
|
||||
categories: [functions]
|
||||
menu:
|
||||
docs:
|
||||
parent: "functions"
|
||||
tags: [strings,emojis]
|
||||
ns:
|
||||
signature: ["emojify INPUT"]
|
||||
workson: []
|
||||
hugoversion:
|
||||
relatedfuncs: []
|
||||
deprecated: false
|
||||
---
|
||||
|
||||
`emoji` runs a passed string through the Emoji emoticons processor. The result will be declared as "safe" to prevent Go templates from filtering it as unsafe HTML.
|
||||
|
||||
See the [Emoji cheat sheet][emojis] for available emoticons.
|
||||
|
||||
The `emojify` function can be called in your templates but not directly in your content files by default. To add emojis directly into content without further templating or shortcode considerations, set `enableEmoji` to `true` in your site's [configuration][config].
|
||||
|
||||
## Example
|
||||
|
||||
When enabled, you can write emoji shorthand directly into your content files; e.g. <code>I :</code><code>heart</code><code>: Hugo!</code>:
|
||||
|
||||
I :heart: Hugo!
|
||||
|
||||
|
||||
[config]: /getting-started/configuration/
|
||||
[emojis]: http://www.emoji-cheat-sheet.com/
|
||||
[sc]: /templates/shortcode-templates/
|
||||
[scsource]: https://github.com/spf13/hugo/tree/master/docs/layouts/shortcodes
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user