Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/gohugoio/hugo.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>2018-05-04 10:44:59 +0300
committerBjørn Erik Pedersen <bjorn.erik.pedersen@gmail.com>2018-05-04 10:44:59 +0300
commit914cc85e22af2e6c28f24a5fc70de94e4b9f1b1b (patch)
treee7b5fcc856003415c613312c80ba2f301eeae03c /docs/content/en/content-management
parenta6816db77574ba3d48a6414c97a53a691c34e705 (diff)
parent83bef6955e014d40c0f00db9cebe09113154e999 (diff)
Merge commit '83bef6955e014d40c0f00db9cebe09113154e999'
Diffstat (limited to 'docs/content/en/content-management')
-rw-r--r--docs/content/en/content-management/_index.md20
-rw-r--r--docs/content/en/content-management/archetypes.md75
-rw-r--r--docs/content/en/content-management/authors.md185
-rw-r--r--docs/content/en/content-management/comments.md80
-rw-r--r--docs/content/en/content-management/cross-references.md130
-rw-r--r--docs/content/en/content-management/formats.md249
-rw-r--r--docs/content/en/content-management/front-matter.md174
-rw-r--r--docs/content/en/content-management/image-processing/index.md195
-rw-r--r--docs/content/en/content-management/image-processing/sunset.jpgbin0 -> 90587 bytes
-rw-r--r--docs/content/en/content-management/menus.md161
-rw-r--r--docs/content/en/content-management/multilingual.md386
-rw-r--r--docs/content/en/content-management/organization/1-featured-content-bundles.pngbin0 -> 63640 bytes
-rw-r--r--docs/content/en/content-management/organization/index.md240
-rw-r--r--docs/content/en/content-management/page-bundles.md185
-rw-r--r--docs/content/en/content-management/page-resources.md150
-rw-r--r--docs/content/en/content-management/related.md143
-rw-r--r--docs/content/en/content-management/sections.md98
-rw-r--r--docs/content/en/content-management/shortcodes.md424
-rw-r--r--docs/content/en/content-management/static-files.md48
-rw-r--r--docs/content/en/content-management/summaries.md81
-rw-r--r--docs/content/en/content-management/syntax-highlighting.md193
-rw-r--r--docs/content/en/content-management/taxonomies.md193
-rw-r--r--docs/content/en/content-management/toc.md95
-rw-r--r--docs/content/en/content-management/types.md99
-rw-r--r--docs/content/en/content-management/urls.md275
25 files changed, 3879 insertions, 0 deletions
diff --git a/docs/content/en/content-management/_index.md b/docs/content/en/content-management/_index.md
new file mode 100644
index 000000000..28f2ecf82
--- /dev/null
+++ b/docs/content/en/content-management/_index.md
@@ -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
+keywords: [source, organization]
+categories: [content management]
+weight: 01 #rem
+draft: false
+aliases: [/content/,/content/organization]
+toc: false
+---
+
+A static site generator needs to extend beyond front matter and a couple of templates to be both scalable and *manageable*. Hugo was designed with not only developers in mind, but also content managers and authors.
diff --git a/docs/content/en/content-management/archetypes.md b/docs/content/en/content-management/archetypes.md
new file mode 100644
index 000000000..904ca8c31
--- /dev/null
+++ b/docs/content/en/content-management/archetypes.md
@@ -0,0 +1,75 @@
+---
+title: Archetypes
+linktitle: Archetypes
+description: Archetypes are templates used when creating new content.
+date: 2017-02-01
+publishdate: 2017-02-01
+keywords: [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 template files in the [archetypes directory][] of your project that contain preconfigured [front matter][] and possibly also a content disposition for your website's [content types][]. These will be used when you run `hugo new`.
+
+
+The `hugo new` uses the `content-section` to find the most suitable archetype template in your project. If your project does not contain any archetype files, it will also look in the theme.
+
+{{< code file="archetype-example.sh" >}}
+hugo new posts/my-first-post.md
+{{< /code >}}
+
+The above will create a new content file in `content/posts/my-first-post.md` using the first archetype file found of these:
+
+1. `archetypes/posts.md`
+2. `archetypes/default.md`
+3. `themes/my-theme/archetypes/posts.md`
+4. `themes/my-theme/archetypes/default.md`
+
+The last two list items is only applicable if you use a theme and it uses the `my-theme` theme name as an example.
+
+## Create a New Archetype Template
+
+A fictional example for the section `newsletter` and the archetype file `archetypes/newsletter.md`. Create a new file in `archetypes/newsletter.md` and open it in a text editor.
+
+{{< code file="archetypes/newsletter.md" >}}
+---
+title: "{{ replace .Name "-" " " | title }}"
+date: {{ .Date }}
+draft: true
+---
+
+**Insert Lead paragraph here.**
+
+## New Cool Posts
+
+{{ range first 10 ( where .Site.RegularPages "Type" "cool" ) }}
+* {{ .Title }}
+{{ end }}
+{{< /code >}}
+
+When you create a new newsletter with:
+
+```bash
+hugo new newsletter/the-latest-cool.stuff.md
+```
+
+It will create a new newsletter type of content file based on the archetype template.
+
+**Note:** the site will only be built if the `.Site` is in use in the archetype file, and this can be time consuming for big sites.
+
+The above _newsletter type archetype_ illustrates the possibilities: The full Hugo `.Site` and all of Hugo&#39;s template funcs can be used in the archetype file.
+
+
+[archetypes directory]: /getting-started/directory-structure/
+[content types]: /content-management/types/
+[front matter]: /content-management/front-matter/
diff --git a/docs/content/en/content-management/authors.md b/docs/content/en/content-management/authors.md
new file mode 100644
index 000000000..afc94fa62
--- /dev/null
+++ b/docs/content/en/content-management/authors.md
@@ -0,0 +1,185 @@
+---
+title: Authors
+linktitle: Authors
+description:
+date: 2016-08-22
+publishdate: 2017-03-12
+lastmod: 2017-03-12
+keywords: [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" >}}
+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.
+
+## Associate 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.
+
+```
+---
+title: Why Hugo is so Awesome
+date: 2016-08-22T14:27:502:00
+authors: ["alice"]
+---
+
+Nothing to read here. Move along...
+```
+
+```
++++
+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.
+
+## Work 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 %}}
+
+### Link 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" >}}
+{{ 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:
+
+```
+taxonomies:
+ author: authors
+```
+
+```
+[taxonomies]
+ author = "authors"
+```
+
+
+### List 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" >}}
+<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).
+
+### List 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" >}}
+{{ 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/
diff --git a/docs/content/en/content-management/comments.md b/docs/content/en/content-management/comments.md
new file mode 100644
index 000000000..20932a825
--- /dev/null
+++ b/docs/content/en/content-management/comments.md
@@ -0,0 +1,80 @@
+---
+title: Comments
+linktitle: Comments
+description: Hugo ships with an internal Disqus template, but this 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
+keywords: [sections,content,organization]
+categories: [project organization, fundamentals]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 140
+weight: 140 #rem
+draft: false
+aliases: [/extras/comments/]
+toc: true
+---
+
+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].
+
+## Add 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].
+
+### Configure Disqus
+
+Disqus comments require you set a single value in your [site's configuration file][configuration] like so:
+
+{{< code-toggle copy="false" >}}
+disqusShortname = "yourdiscussshortname"
+{{</ code-toggle >}}
+
+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`
+
+### Render 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.
+
+## Comments 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
diff --git a/docs/content/en/content-management/cross-references.md b/docs/content/en/content-management/cross-references.md
new file mode 100644
index 000000000..2980719e9
--- /dev/null
+++ b/docs/content/en/content-management/cross-references.md
@@ -0,0 +1,130 @@
+---
+title: Links and Cross References
+description: Hugo makes it easy to link documents together.
+date: 2017-02-01
+publishdate: 2017-02-01
+lastmod: 2017-03-31
+categories: [content management]
+keywords: ["cross references","references", "anchors", "urls"]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 100
+weight: 100 #rem
+aliases: [/extras/crossreferences/]
+toc: true
+---
+
+
+ The `ref` and `relref` shortcodes link documents together, both of which are [built-in Hugo shortcodes][]. These shortcodes are also used to 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.
+
+## Use `ref` and `relref`
+
+```
+{{</* ref "document.md" */>}}
+{{</* ref "#anchor" */>}}
+{{</* ref "document.md#anchor" */>}}
+{{</* relref "document.md" */>}}
+{{</* relref "#anchor" */>}}
+{{</* relref "document.md#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:
+
+```
+{{</* 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:
+
+```
+.
+└── content
+ ├── events
+ │   └── my-birthday.md
+ ├── galleries
+ │   └── my-birthday.md
+ ├── meta
+ │   └── my-article.md
+ └── posts
+ └── my-birthday.md
+```
+
+To be sure to get the correct reference in this case, use the full path:
+
+{{< code file="content/meta/my-article.md" copy="false" >}}
+{{</* relref "events/my-birthday.md" */>}} => /events/my-birthday/
+{{< /code >}}
+
+### 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:
+
+```
+{{</* 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
+
+```
+{{</* 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" */>}}` => `https://example.com/blog/post/`
+* `{{</* ref "post.md#tldr" */>}}` => `https://example.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 "content-management/cross-references.md#hugo-heading-anchors" */>}}
+/content-management/cross-references/#hugo-heading-anchors:77cd9ea530577debf4ce0f28c8dca242
+```
+
+### Manually Specifying Anchors
+
+For Markdown content files, if the `headerIds` [Blackfriday extension][bfext] is
+enabled (which it is by default), user can manually specify the anchor for any
+heading.
+
+Few examples:
+
+```
+## Alpha 101 {#alpha}
+
+## Version 1.0 {#version-1-dot-0}
+```
+
+[built-in Hugo shortcodes]: /content-management/shortcodes/#using-the-built-in-shortcodes
+[lists]: /templates/lists/
+[output formats]: /templates/output-formats/
+[shortcode]: /content-management/shortcodes/
+[bfext]: /content-management/formats/#blackfriday-extensions
diff --git a/docs/content/en/content-management/formats.md b/docs/content/en/content-management/formats.md
new file mode 100644
index 000000000..6c53ab467
--- /dev/null
+++ b/docs/content/en/content-management/formats.md
@@ -0,0 +1,249 @@
+---
+title: Supported Content Formats
+linktitle: Supported Content Formats
+description: Markdown and Emacs Org-Mode have native support, and additional formats (e.g. Asciidoc) come via external helpers.
+date: 2017-01-10
+publishdate: 2017-01-10
+lastmod: 2017-04-06
+categories: [content management]
+keywords: [markdown,asciidoc,mmark,pandoc,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 is the main content format** and comes in two flavours: The excellent [Blackfriday project][blackfriday] (name your files `*.md` or set `markup = "markdown"` in front matter) or its fork [Mmark][mmark] (name your files `*.mmark` or set `markup = "mmark"` in front matter), both very fast markdown engines written in Go.
+
+For Emacs users, [goorgeous](https://github.com/chaseadamsio/goorgeous) provides built-in native support for Org-mode (name your files `*.org` or set `markup = "org"` in front matter)
+
+{{% 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 %}}
+
+## Configure 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/en/readfiles/bfconfig.md" markdown="true" >}}
+
+## Extend 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" >}}
+- [ ] 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:
+
+```
+<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
+
+To add emojis directly to content, set `enableEmoji` to `true` in your [site configuration][config]. To use emojis in templates or shortcodes, see [`emojify` function][].
+
+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. This is one of the most powerful features in Hugo and allows you to 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` shortcode][hlsc], and syntax highlights those code blocks natively using *Chroma*. Users also have an option to use *Pygments* instead. See the [Syntax Highlighting][hl] section for details.
+
+## 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][].
+
+### Use 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:
+
+```
+---
+title: My Post
+date: 2017-04-01
+markup: mmark
+---
+```
+
+{{% warning %}}
+Thare are some features not available in Mmark; one example being that shortcodes are not translated when used in an included `.mmark` file ([#3131](https://github.com/gohugoio/hugo/issues/3137)), and `EXTENSION_ABBREVIATION` ([#1970](https://github.com/gohugoio/hugo/issues/1970)) and the aforementioned GFM todo lists ([#2270](https://github.com/gohugoio/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.
+
+### Enable 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" >}}
+<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" >}}
+<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" >}}
+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
+
+Hugo has a new concept called _external helpers_. It means that you can write your content using [Asciidoc][ascii], [reStructuredText][rest], or [pandoc]. 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.
+
+Hugo passes reasonable default arguments to these external helpers by default:
+
+- `asciidoc`: `--no-header-footer --safe -`
+- `asciidoctor`: `--no-header-footer --safe --trace -`
+- `rst2html`: `--leave-comments --initial-header-level=2`
+- `pandoc`: `--mathjax`
+
+{{% warning "Performance of External Helpers" %}}
+Because additional formats are external commands 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://asciidoctor.org/
+[bfconfig]: /getting-started/configuration/#configuring-blackfriday-rendering
+[blackfriday]: https://github.com/russross/blackfriday
+[mmark]: https://github.com/miekg/mmark
+[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/gohugoio/hugo/blob/77c60a3440806067109347d04eb5368b65ea0fe8/helpers/general.go#L65
+[hl]: /content-management/syntax-highlighting/
+[hlsc]: /content-management/shortcodes/#highlight
+[hugocss]: /css/style.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/
+[pandoc]: http://www.pandoc.org/
+[Pygments]: http://pygments.org/
+[rest]: http://docutils.sourceforge.net/rst.html
+[sc]: /content-management/shortcodes/
+[sct]: /templates/shortcode-templates/
diff --git a/docs/content/en/content-management/front-matter.md b/docs/content/en/content-management/front-matter.md
new file mode 100644
index 000000000..bf067797c
--- /dev/null
+++ b/docs/content/en/content-management/front-matter.md
@@ -0,0 +1,174 @@
+---
+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]
+keywords: ["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.
+
+{{< youtube Yh2xKRJGff4 >}}
+
+## 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 `---`.
+
+JSON
+: a single JSON object surrounded by '`{`' and '`}`', followed by a new line.
+
+### Example
+
+{{< code-toggle >}}
++++
+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-toggle >}}
+
+## 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.
+
+headless
+: if `true`, sets a leaf bundle to be [headless][headless-bundle].
+
+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`.
+
+resources
+: used for configuring page bundle resources. See [Page Resources][page-resources].
+
+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.
+
+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].
+
+\<taxonomies\>
+: field name of the *plural* form of the index. See `tags` and `categories` in the above front matter examples. _Note that the plural form of user-defined taxonomies cannot be the same as any of the predefined front matter variables._
+
+{{% 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.
+
+{{< code-toggle copy="false" >}}
+include_toc: true
+show_comments: false
+{{</ code-toggle >}}
+
+
+## Order 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.
+
+## Override Global Markdown 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"
+[headless-bundle]: /content-management/page-bundles/#headless-bundle
+[json]: https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.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"
+[page-resources]: /content-management/page-resources/
+[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"
diff --git a/docs/content/en/content-management/image-processing/index.md b/docs/content/en/content-management/image-processing/index.md
new file mode 100644
index 000000000..ecc85bb51
--- /dev/null
+++ b/docs/content/en/content-management/image-processing/index.md
@@ -0,0 +1,195 @@
+---
+title: "Image Processing"
+description: "Image Page resources can be resized and cropped."
+date: 2018-01-24T13:10:00-05:00
+lastmod: 2018-01-26T15:59:07-05:00
+linktitle: "Image Processing"
+categories: ["content management"]
+keywords: [bundle,content,resources,images]
+weight: 4004
+draft: false
+toc: true
+menu:
+ docs:
+ parent: "content-management"
+ weight: 32
+---
+
+## The Image Page Resource
+
+The `image` is a [Page Resource]({{< relref "content-management/page-resources" >}}), and the processing methods listed below does not work on images inside your `/static` folder.
+
+
+To get all images in a [Page Bundle]({{< relref "content-management/organization#page-bundles" >}}):
+
+
+```go-html-template
+{{ with .Resources.ByType "image" }}
+{{ end }}
+
+```
+
+## Image Processing Methods
+
+
+The `image` resource implements the methods `Resize`, `Fit` and `Fill`, each returning the transformed image using the specified dimensions and processing options.
+
+Resize
+: Resizes the image to the specified width and height.
+
+```go
+// Resize to a width of 600px and preserve ratio
+{{ $image := $resource.Resize "600x" }}
+
+// Resize to a height of 400px and preserve ratio
+{{ $image := $resource.Resize "x400" }}
+
+// Resize to a width 600px and a height of 400px
+{{ $image := $resource.Resize "600x400" }}
+```
+
+Fit
+: Scale down the image to fit the given dimensions while maintaining aspect ratio. Both height and width are required.
+
+```go
+{{ $image := $resource.Fit "600x400" }}
+```
+
+Fill
+: Resize and crop the image to match the given dimensions. Both height and width are required.
+
+```go
+{{ $image := $resource.Fill "600x400" }}
+```
+
+
+{{% note %}}
+Image operations in Hugo currently **do not preserve EXIF data** as this is not supported by Go's [image package](https://github.com/golang/go/search?q=exif&type=Issues&utf8=%E2%9C%93). This will be improved on in the future.
+{{% /note %}}
+
+
+## Image Processing Options
+
+In addition to the dimensions (e.g. `600x400`), Hugo supports a set of additional image options.
+
+
+JPEG Quality
+: Only relevant for JPEG images, values 1 to 100 inclusive, higher is better. Default is 75.
+
+```go
+{{ $image.Resize "600x q50" }}
+```
+
+Rotate
+: Rotates an image by the given angle counter-clockwise. The rotation will be performed first to get the dimensions correct. The main use of this is to be able to manually correct for [EXIF orientation](https://github.com/golang/go/issues/4341) of JPEG images.
+
+```go
+{{ $image.Resize "600x r90" }}
+```
+
+Anchor
+: Only relevant for the `Fill` method. This is useful for thumbnail generation where the main motive is located in, say, the left corner.
+Valid are `Center`, `TopLeft`, `Top`, `TopRight`, `Left`, `Right`, `BottomLeft`, `Bottom`, `BottomRight`.
+
+```go
+{{ $image.Fill "300x200 BottomLeft" }}
+```
+
+Resample Filter
+: Filter used in resizing. Default is `Box`, a simple and fast resampling filter appropriate for downscaling.
+
+Examples are: `Box`, `NearestNeighbor`, `Linear`, `Gaussian`.
+
+See https://github.com/disintegration/imaging for more. If you want to trade quality for faster processing, this may be a option to test.
+
+```go
+{{ $image.Resize "600x400 Gaussian" }}
+```
+
+## Image Processing Examples
+
+_The photo of the sunset used in the examples below is Copyright [Bjørn Erik Pedersen](https://commons.wikimedia.org/wiki/User:Bep) (Creative Commons Attribution-Share Alike 4.0 International license)_
+
+
+{{< imgproc sunset Resize "300x" />}}
+
+{{< imgproc sunset Fill "90x120 left" />}}
+
+{{< imgproc sunset Fill "90x120 right" />}}
+
+{{< imgproc sunset Fit "90x90" />}}
+
+{{< imgproc sunset Resize "300x q10" />}}
+
+
+This is the shortcode used in the examples above:
+
+
+{{< code file="layouts/shortcodes/imgproc.html" >}}
+{{< readfile file="layouts/shortcodes/imgproc.html" >}}
+{{< /code >}}
+
+And it is used like this:
+
+```go-html-template
+{{</* imgproc sunset Resize "300x" /*/>}}
+```
+
+
+{{% note %}}
+**Tip:** Note the self-closing shortcode syntax above. The `imgproc` shortcode can be called both with and without **inner content**.
+{{% /note %}}
+
+## Image Processing Config
+
+You can configure an `imaging` section in `config.toml` with default image processing options:
+
+```toml
+[imaging]
+# Default resample filter used for resizing. Default is Box,
+# a simple and fast averaging filter appropriate for downscaling.
+# See https://github.com/disintegration/imaging
+resampleFilter = "box"
+
+# Defatult JPEG quality setting. Default is 75.
+quality = 75
+
+# Anchor used when cropping pictures.
+# Default is "smart" which does Smart Cropping, using https://github.com/muesli/smartcrop
+# Smart Cropping is content aware and tries to find the best crop for each image.
+# Valid values are Smart, Center, TopLeft, Top, TopRight, Left, Right, BottomLeft, Bottom, BottomRight
+anchor = "smart"
+
+```
+
+All of the above settings can also be set per image procecssing.
+
+## Smart Cropping of Images
+
+By default, Hugo will use the [Smartcrop](https://github.com/muesli/smartcrop), a library created by [muesli](https://github.com/muesli), when cropping images with `.Fill`. You can set the anchor point manually, but in most cases the smart option will make a good choice. And we will work with the libray author to improve this in the future.
+
+An example using the sunset image from above:
+
+
+{{< imgproc sunset Fill "200x200 smart" />}}
+
+
+## Image Processing Performance Consideration
+
+Processed images are stored below `<project-dir>/resources` (can be set with `resourceDir` config setting). This folder is deliberately placed in the project, as it is recommended to check these into source control as part of the project. These images are not "Hugo fast" to generate, but once generated they can be reused.
+
+If you change your image settings (e.g. size), remove or rename images etc., you will end up with unused images taking up space and cluttering your project.
+
+To clean up, run:
+
+```bash
+hugo --gc
+```
+
+
+{{% note %}}
+**GC** is short for **Garbage Collection**.
+{{% /note %}}
+
+
+
diff --git a/docs/content/en/content-management/image-processing/sunset.jpg b/docs/content/en/content-management/image-processing/sunset.jpg
new file mode 100644
index 000000000..7d7307bed
--- /dev/null
+++ b/docs/content/en/content-management/image-processing/sunset.jpg
Binary files differ
diff --git a/docs/content/en/content-management/menus.md b/docs/content/en/content-management/menus.md
new file mode 100644
index 000000000..c2eadf50f
--- /dev/null
+++ b/docs/content/en/content-management/menus.md
@@ -0,0 +1,161 @@
+---
+title: Menus
+linktitle: Menus
+description: Hugo has a simple yet powerful menu system.
+date: 2017-02-01
+publishdate: 2017-02-01
+lastmod: 2017-03-31
+categories: [content management]
+keywords: [menus]
+draft: false
+menu:
+ docs:
+ parent: "content-management"
+ weight: 120
+weight: 120 #rem
+aliases: [/extras/menus/]
+toc: true
+---
+
+{{% 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-bloggers).
+{{% /note %}}
+
+You can do this:
+
+* 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
+
+## Add 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
+
+```
+---
+menu: "main"
+---
+```
+
+#### Multiple Menus
+
+```
+---
+menu: ["main", "footer"]
+---
+```
+
+#### Advanced
+
+
+```
+---
+menu:
+ docs:
+ parent: 'extras'
+ weight: 20
+---
+```
+
+## Add 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 configuration file:
+
+{{< code-toggle file="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/"
+{{< /code-toggle >}}
+
+{{% note %}}
+The URLs must be relative to the context root. If the `baseURL` is `https://example.com/mysite/`, then the URLs in the menu must not include the context root `mysite`. Using an absolute URL will override the baseURL. If the value used for `URL` in the above example is `https://subdomain.example.com/`, the output will be `https://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.
+
+## Render 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/
diff --git a/docs/content/en/content-management/multilingual.md b/docs/content/en/content-management/multilingual.md
new file mode 100644
index 000000000..28a6e4fec
--- /dev/null
+++ b/docs/content/en/content-management/multilingual.md
@@ -0,0 +1,386 @@
+---
+title: Multilingual Mode
+linktitle: Multilingual and i18n
+description: 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]
+keywords: [multilingual,i18n, internationalization]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 150
+weight: 150 #rem
+draft: false
+aliases: [/content/multilingual/,/content-management/multilingual/,/tutorials/create-a-multilingual-site/]
+toc: true
+---
+
+You should define the available languages in a `languages` section in your site configuration.
+
+## Configure Languages
+
+The following is an example of a site configuration for a multilingual Hugo project:
+
+{{< code-toggle file="config" >}}
+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.params.navigation]
+help = "Aide"
+{{< /code-toggle >}}
+
+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.
+
+## Disable a Language
+
+You can disable one or more languages. This can be useful when working on a new translation.
+
+```toml
+disableLanguages = ["fr", "jp"]
+```
+
+Note that you cannot disable the default content language.
+
+We kept this as a standalone setting to make it easier to set via [OS environment](/getting-started/configuration/#configure-with-environment-variables):
+
+```bash
+HUGO_DISABLELANGUAGES="fr jp" hugo
+```
+If you have already a list of disabled languages in `config.toml`, you can enable them in development like this:
+
+```bash
+HUGO_DISABLELANGUAGES=" " hugo server
+```
+
+
+## Configure Multilingual Multihost
+
+From **Hugo 0.31** we support multiple languages in a multihost configuration. See [this issue](https://github.com/gohugoio/hugo/issues/4027) for details.
+
+This means that you can now configure a `baseURL` per `language`:
+
+
+> If a `baseURL` is set on the `language` level, then all languages must have one and they must all be different.
+
+Example:
+
+{{< code-toggle file="config" >}}
+[languages]
+[languages.no]
+baseURL = "https://example.no"
+languageName = "Norsk"
+weight = 1
+title = "På norsk"
+
+[languages.en]
+baseURL = "https://example.com"
+languageName = "English"
+weight = 2
+title = "In English"
+{{</ code-toggle >}}
+
+With the above, the two sites will be generated into `public` with their own root:
+
+```bash
+public
+├── en
+└── no
+```
+
+**All URLs (i.e `.Permalink` etc.) will be generated from that root. So the English home page above will have its `.Permalink` set to `https://example.com/`.**
+
+When you run `hugo server` we will start multiple HTTP servers. You will typlically see something like this in the console:
+
+```bash
+Web Server is available at 127.0.0.1:1313 (bind address 127.0.0.1)
+Web Server is available at 127.0.0.1:1314 (bind address 127.0.0.1)
+Press Ctrl+C to stop
+```
+
+Live reload and `--navigateToChanged` between the servers work as expected.
+
+## Taxonomies and Blackfriday
+
+Taxonomies and [Blackfriday configuration][config] can also be set per language:
+
+
+{{< code-toggle file="config" >}}
+[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-toggle >}}
+
+## Translate 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`
+
+In this example, the `about.md` will be assigned the configured `defaultContentLanguage`.
+
+1. `/content/about.md`
+2. `/content/about.fr.md`
+
+This way, you can slowly start to translate your current content without having to rename everything. If left unspecified, the default value for `defaultContentLanguage` is `en`.
+
+By having the same **directory and base filename**, the content pieces are linked together as translated pieces.
+
+You can also set the key used to link the translations explicitly in front matter:
+
+```yaml
+translationKey: "my-story"
+```
+
+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.
+
+For merging of content from other languages (i.e. missing content translations), see [lang.Merge](/functions/lang.merge/).
+
+## 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" >}}
+{{ 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.
+
+The above also uses the [`i18n` function][i18func] described in the next section.
+
+## List All Available Languages
+
+`.AllTranslations` on a `Page` can be used to list all translations, including itself. Called on the home page it can be used to build a language navigator:
+
+
+{{< code file="layouts/partials/allLanguages.html" >}}
+<ul>
+{{ range $.Site.Home.AllTranslations }}
+<li><a href="{{ .Permalink }}">{{ .Language.LanguageName }}</a></li>
+{{ end }}
+</ul>
+{{< /code >}}
+
+## 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.
+
+{{% note %}}
+From **Hugo 0.31** you no longer need to use a valid language code. It _can be_ anything.
+
+See https://github.com/gohugoio/hugo/issues/3564
+
+{{% /note %}}
+
+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:
+
+```
+ 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:
+
+```
+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.
+
+```
+<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 %}}
+
+For merging of content from other languages (i.e. missing content translations), see [lang.Merge](/functions/lang.merge/).
+
+## 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/
diff --git a/docs/content/en/content-management/organization/1-featured-content-bundles.png b/docs/content/en/content-management/organization/1-featured-content-bundles.png
new file mode 100644
index 000000000..1706a29d6
--- /dev/null
+++ b/docs/content/en/content-management/organization/1-featured-content-bundles.png
Binary files differ
diff --git a/docs/content/en/content-management/organization/index.md b/docs/content/en/content-management/organization/index.md
new file mode 100644
index 000000000..b810f6179
--- /dev/null
+++ b/docs/content/en/content-management/organization/index.md
@@ -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,fundamentals]
+keywords: [sections,content,organization,bundle,resources]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 10
+weight: 10 #rem
+draft: false
+aliases: [/content/sections/]
+toc: true
+---
+
+## Page Bundles
+
+Hugo `0.32` announced page-relative images and other resources packaged into `Page Bundles`.
+
+These terms are connected, and you also need to read about [Page Resources]({{< relref "content-management/page-resources" >}}) and [Image Processing]({{< relref "content-management/image-processing" >}}) to get the full picture.
+
+{{% imgproc 1-featured Resize "300x" %}}
+The illustration shows 3 bundles. Note that the home page bundle cannot contain other content pages, but other files (images etc.) are fine.
+{{% /imgproc %}}
+
+
+{{% note %}}
+The bundle documentation is **work in progress**. We will publish more comprehensive docs about this soon.
+{{% /note %}}
+
+
+# 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 type used to determine layouts etc. To read more about sections, including how to nest them, see [sections][].
+
+Without any additional configuration, the following will just work:
+
+```
+.
+└── content
+ └── about
+ | └── _index.md // <- https://example.com/about/
+ ├── post
+ | ├── firstpost.md // <- https://example.com/post/firstpost/
+ | ├── happy
+ | | └── ness.md // <- https://example.com/post/happy/ness/
+ | └── secondpost.md // <- https://example.com/post/secondpost/
+ └── quote
+ ├── first.md // <- https://example.com/quote/first/
+ └── second.md // <- https://example.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 = "https://example.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]. These templates include those for [section templates][], [taxonomy templates][], [taxonomy terms templates][], and your [homepage template][].
+
+{{% note %}}
+**Tip:** You can get a reference to the content and metadata in `_index.md` using the [`.Site.GetPage` function](/functions/getpage/).
+{{% /note %}}
+
+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:
+
+
+```
+. url
+. ⊢--^-⊣
+. path slug
+. ⊢--^-⊣⊢---^---⊣
+. filepath
+. ⊢------^------⊣
+content/posts/_index.md
+```
+
+At build, this will output to the following destination with the associated values:
+
+```
+
+ url ("/posts/")
+ ⊢-^-⊣
+ baseurl section ("posts")
+⊢--------^---------⊣⊢-^-⊣
+ permalink
+⊢----------^-------------⊣
+https://example.com/posts/index.html
+```
+
+The [sections][] can be nested as deeply as you need. The important part to understand is, that to make the section tree fully navigational, at least the lower-most section needs a content file. (i.e. `_index.md`).
+
+
+### 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`:
+
+
+```
+ 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:
+
+```
+
+ url ("/posts/my-first-hugo-post/")
+ ⊢------------^----------⊣
+ baseurl section slug
+⊢--------^--------⊣⊢-^--⊣⊢-------^---------⊣
+ permalink
+⊢--------------------^---------------------⊣
+https://example.com/posts/my-first-hugo-post/index.html
+```
+
+
+## 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*
+
+## Override 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 `example.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" >}}
+---
+title: New Post
+slug: "new-post"
+---
+{{< /code >}}
+
+This will render to the following destination according to Hugo's default behavior:
+
+```
+example.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" >}}
+---
+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" >}}
+---
+title: Old URL
+url: /blog/new-url/
+---
+{{< /code >}}
+
+Assuming your `baseURL` is [configured][config] to `https://example.com`, the addition of `url` to the front matter will make `old-url.md` render to the following destination:
+
+```
+https://example.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/
diff --git a/docs/content/en/content-management/page-bundles.md b/docs/content/en/content-management/page-bundles.md
new file mode 100644
index 000000000..639d81eff
--- /dev/null
+++ b/docs/content/en/content-management/page-bundles.md
@@ -0,0 +1,185 @@
+---
+title : "Page Bundles"
+description : "Content organization using Page Bundles"
+date : 2018-01-24T13:09:00-05:00
+lastmod : 2018-01-28T22:26:40-05:00
+linktitle : "Page Bundles"
+keywords : ["page", "bundle", "leaf", "branch"]
+categories : ["content management"]
+toc : true
+menu :
+ docs:
+ identifier : "page-bundles"
+ parent : "content-management"
+ weight : 11
+---
+
+Page Bundles are a way to group [Page Resources](/content-management/page-resources/).
+
+A Page Bundle can be one of:
+
+- Leaf Bundle (leaf means it has no children)
+- Branch Bundle (home page, section, taxonomy terms, taxonomy list)
+
+| | Leaf Bundle | Branch Bundle |
+|-------------------------------------|----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Usage | Collection of content and attachments for single pages | Collection of attachments for section pages (home page, section, taxonomy terms, taxonomy list) |
+| Index file name | `index.md` [^fn:1] | `_index.md` [^fn:1] |
+| Allowed Resources | Page and non-page (like images, pdf, etc.) types | Only non-page (like images, pdf, etc.) types |
+| Where can the Resources live? | At any directory level within the leaf bundle directory. | Only in the directory level **of** the branch bundle directory i.e. the directory containing the `_index.md` ([ref](https://discourse.gohugo.io/t/question-about-content-folder-structure/11822/4?u=kaushalmodi)). |
+| Layout type | `single` | `list` |
+| Nesting | Does not allow nesting of more bundles under it | Allows nesting of leaf or branch bundles under it |
+| Example | `content/posts/my-post/index.md` | `content/posts/_index.md` |
+| Content from non-index page files .. | Accessed only as page resources | Accessed only as regular pages |
+
+
+## Leaf Bundles {#leaf-bundles}
+
+A _Leaf Bundle_ is a directory at any hierarchy within the `content/`
+directory, that contains an **`index.md`** file.
+
+### Examples of Leaf Bundle organization {#examples-of-leaf-bundle-organization}
+
+```text
+content/
+├── about
+│ ├── index.md
+├── posts
+│ ├── my-post
+│ │ ├── content1.md
+│ │ ├── content2.md
+│ │ ├── image1.jpg
+│ │ ├── image2.png
+│ │ └── index.md
+│ └── my-another-post
+│    └── index.md
+│
+└── another-section
+ ├── ..
+    └── not-a-leaf-bundle
+ ├── ..
+    └── another-leaf-bundle
+    └── index.md
+```
+
+In the above example `content/` directory, there are four leaf
+bundles:
+
+about
+: This leaf bundle is at the root level (directly under
+ `content` directory) and has only the `index.md`.
+
+my-post
+: This leaf bundle has the `index.md`, two other content
+ Markdown files and two image files.
+
+my-another-post
+: This leaf bundle has only the `index.md`.
+
+another-leaf-bundle
+: This leaf bundle is nested under couple of
+ directories. This bundle also has only the `index.md`.
+
+{{% note %}}
+The hierarchy depth at which a leaf bundle is created does not matter,
+as long as it is not inside another **leaf** bundle.
+{{% /note %}}
+
+
+### Headless Bundle {#headless-bundle}
+
+A headless bundle is a bundle that is configured to not get published
+anywhere:
+
+- It will have no `Permalink` and no rendered HTML in `public/`.
+- It will not be part of `.Site.RegularPages`, etc.
+
+But you can get it by `.Site.GetPage`. Here is an example:
+
+```go-html-template
+{{ $headless := .Site.GetPage "page" "some-headless-bundle" }}
+{{ $reusablePages := $headless.Resources.Match "author*" }}
+<h2>Authors</h2>
+{{ range $reusablePages }}
+ <h3>{{ .Title }}</h3>
+ {{ .Content }}
+{{ end }}
+```
+
+_In this example, we are assuming the `some-headless-bundle` to be a headless
+ bundle containing one or more **page** resources whose `.Name` matches
+ `"author*"`._
+
+Explanation of the above example:
+
+1. Get the `some-headless-bundle` Page "object".
+2. Collect a *slice* of resources in this *Page Bundle* that matches
+ `"author*"` using `.Resources.Match`.
+3. Loop through that *slice* of nested pages, and output their `.Title` and
+ `.Content`.
+
+---
+
+A leaf bundle can be made headless by adding below in the Front Matter
+(in the `index.md`):
+
+```toml
+headless = true
+```
+
+{{% note %}}
+Only leaf bundles can be made headless.
+{{% /note %}}
+
+There are many use cases of such headless page bundles:
+
+- Shared media galleries
+- Reusable page content "snippets"
+
+
+## Branch Bundles {#branch-bundles}
+
+A _Branch Bundle_ is any directory at any hierarchy within the
+`content/` directory, that contains at least an **`_index.md`** file.
+
+This `_index.md` can also be directly under the `content/` directory.
+
+{{% note %}}
+Here `md` (markdown) is used just as an example. You can use any file
+type as a content resource as long as it is a content type recognized by Hugo.
+{{% /note %}}
+
+
+### Examples of Branch Bundle organization {#examples-of-branch-bundle-organization}
+
+```text
+content/
+├── branch-bundle-1
+│   ├── branch-content1.md
+│   ├── branch-content2.md
+│   ├── image1.jpg
+│   ├── image2.png
+│   └── _index.md
+└── branch-bundle-2
+ ├── _index.md
+ └── a-leaf-bundle
+ └── index.md
+```
+
+In the above example `content/` directory, there are two branch
+bundles (and a leaf bundle):
+
+`branch-bundle-1`
+: This branch bundle has the `_index.md`, two
+ other content Markdown files and two image files.
+
+`branch-bundle-2`
+: This branch bundle has the `_index.md` and a
+ nested leaf bundle.
+
+{{% note %}}
+The hierarchy depth at which a branch bundle is created does not
+matter.
+{{% /note %}}
+
+[^fn:1]: The `.md` extension is just an example. The extension can be `.html`, `.json` or any of any valid MIME type.
diff --git a/docs/content/en/content-management/page-resources.md b/docs/content/en/content-management/page-resources.md
new file mode 100644
index 000000000..cefb1cd47
--- /dev/null
+++ b/docs/content/en/content-management/page-resources.md
@@ -0,0 +1,150 @@
+---
+title : "Page Resources"
+description : "Page Resources -- images, other pages, documents etc. -- have page-relative URLs and their own metadata."
+date: 2018-01-24
+categories: ["content management"]
+keywords: [bundle,content,resources]
+weight: 4003
+draft: false
+toc: true
+linktitle: "Page Resources"
+menu:
+ docs:
+ parent: "content-management"
+ weight: 31
+---
+
+## Properties
+
+ResourceType
+: The main type of the resource. For example, a file of MIME type `image/jpg` has for ResourceType `image`.
+
+Name
+: Default value is the filename (relative to the owning page). Can be set in front matter.
+
+Title
+: Default blank. Can be set in front matter.
+
+Permalink
+: The absolute URL to the resource. Resources of type `page` will have no value.
+
+RelPermalink
+: The relative URL to the resource. Resources of type `page` will have no value.
+
+## Methods
+ByType
+: Returns the page resources of the given type.
+
+```go
+{{ .Resources.ByType "image" }}
+```
+Match
+: Returns all the page resources (as a slice) whose `Name` matches the given Glob pattern ([examples](https://github.com/gobwas/glob/blob/master/readme.md)). The matching is case-insensitive.
+
+```go
+{{ .Resources.Match "images/*" }}
+```
+
+GetMatch
+: Same as `Match` but will return the first match.
+
+### Pattern Matching
+```go
+// Using Match/GetMatch to find this images/sunset.jpg ?
+.Resources.Match "images/sun*" ✅
+.Resources.Match "**/Sunset.jpg" ✅
+.Resources.Match "images/*.jpg" ✅
+.Resources.Match "**.jpg" ✅
+.Resources.Match "*" 🚫
+.Resources.Match "sunset.jpg" 🚫
+.Resources.Match "*sunset.jpg" 🚫
+
+```
+
+## Page Resources Metadata
+
+Page Resources' metadata is managed from their page's front matter with an array/table parameter named `resources`. You can batch assign values using a [wildcards](http://tldp.org/LDP/GNU-Linux-Tools-Summary/html/x11655.htm).
+
+{{% note %}}
+Resources of type `page` get `Title` etc. from their own front matter.
+{{% /note %}}
+
+name
+: Sets the value returned in `Name`.
+
+{{% warning %}}
+The methods `Match` and `GetMatch` use `Name` to match the resources.
+{{%/ warning %}}
+
+title
+: Sets the value returned in `Title`
+
+params
+: A map of custom key/values.
+
+
+### Resources metadata example
+
+{{< code-toggle copy="false">}}
+title: Application
+date : 2018-01-25
+resources :
+- src : "images/sunset.jpg"
+ name : "header"
+- src : "documents/photo_specs.pdf"
+ title : "Photo Specifications"
+ params:
+ icon : "photo"
+- src : "documents/guide.pdf"
+ title : "Instruction Guide"
+- src : "documents/checklist.pdf"
+ title : "Document Checklist"
+- src : "documents/payment.docx"
+ title : "Proof of Payment"
+- src : "**.pdf"
+ name : "pdf-file-:counter"
+ params :
+ icon : "pdf"
+- src : "**.docx"
+ params :
+ icon : "word"
+{{</ code-toggle >}}
+
+From the example above:
+
+- `sunset.jpg` will receive a new `Name` and can now be found with `.GetMatch "header"`.
+- `documents/photo_specs.pdf` will get the `photo` icon.
+- `documents/checklist.pdf`, `documents/guide.pdf` and `documents/payment.docx` will get `Title` as set by `title`.
+- Every `PDF` in the bundle except `documents/photo_specs.pdf` will get the `pdf` icon.
+- All `PDF` files will get a new `Name`. The `name` parameter contains a special placeholder [`:counter`](#counter), so the `Name` will be `pdf-file-1`, `pdf-file-2`, `pdf-file-3`.
+- Every docx in the bundle will receive the `word` icon.
+
+{{% warning %}}
+The __order matters__ --- Only the **first set** values of the `title`, `name` and `params`-**keys** will be used. Consecutive parameters will be set only for the ones not already set. For example, in the above example, `.Params.icon` is already first set to `"photo"` in `src = "documents/photo_specs.pdf"`. So that would not get overridden to `"pdf"` by the later set `src = "**.pdf"` rule.
+{{%/ warning %}}
+
+### The `:counter` placeholder in `name` and `title`
+
+The `:counter` is a special placeholder recognized in `name` and `title` parameters `resources`.
+
+The counter starts at 1 the first time they are used in either `name` or `title`.
+
+For example, if a bundle has the resources `photo_specs.pdf`, `other_specs.pdf`, `guide.pdf` and `checklist.pdf`, and the front matter has specified the `resources` as:
+
+{{< code-toggle copy="false">}}
+[[resources]]
+ src = "*specs.pdf"
+ title = "Specification #:counter"
+[[resources]]
+ src = "**.pdf"
+ name = "pdf-file-:counter"
+{{</ code-toggle >}}
+
+the `Name` and `Title` will be assigned to the resource files as follows:
+
+| Resource file | `Name` | `Title` |
+|-------------------|-------------------|-----------------------|
+| checklist.pdf | `"pdf-file-1.pdf` | `"checklist.pdf"` |
+| guide.pdf | `"pdf-file-2.pdf` | `"guide.pdf"` |
+| other\_specs.pdf | `"pdf-file-3.pdf` | `"Specification #1"` |
+| photo\_specs.pdf | `"pdf-file-4.pdf` | `"Specification #2"` |
diff --git a/docs/content/en/content-management/related.md b/docs/content/en/content-management/related.md
new file mode 100644
index 000000000..6f66e4468
--- /dev/null
+++ b/docs/content/en/content-management/related.md
@@ -0,0 +1,143 @@
+---
+title: Related Content
+description: List related content in "See Also" sections.
+date: 2017-09-05
+categories: [content management]
+keywords: [content]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 40
+weight: 30
+draft: false
+aliases: [/content/related/,/related/]
+toc: true
+---
+
+{{% note %}}
+We currently do not index **Page content**. We thought we would release something that will make most people happy before we start solving [Sherlock's last case](https://github.com/joearms/sherlock).
+{{% /note %}}
+
+## List Related Content
+
+To list up to 5 related pages is as simple as including something similar to this partial in your single page template:
+
+{{< code file="layouts/partials/related.html" >}}
+{{ $related := .Site.RegularPages.Related . | first 5 }}
+{{ with $related }}
+<h3>See Also</h3>
+<ul>
+ {{ range . }}
+ <li><a href="{{ .RelPermalink }}">{{ .Title }}</a></li>
+ {{ end }}
+</ul>
+{{ end }}
+{{< /code >}}
+
+
+{{% note %}}
+Read [this blog article](https://regisphilibert.com/blog/2018/04/hugo-optmized-relashionships-with-related-content/) for a great explanation more advanced usage of this feature.
+{{% /note %}}
+
+The full set of methods available on the page lists can bee seen in this Go interface:
+
+```go
+// A PageGenealogist finds related pages in a page collection. This interface is implemented
+// by Pages and PageGroup, which makes it available as `{{ .RegularPages.Related . }}` etc.
+type PageGenealogist interface {
+
+ // Template example:
+ // {{ $related := .RegularPages.Related . }}
+ Related(doc related.Document) (Pages, error)
+
+ // Template example:
+ // {{ $related := .RegularPages.RelatedIndices . "tags" "date" }}
+ RelatedIndices(doc related.Document, indices ...interface{}) (Pages, error)
+
+ // Template example:
+ // {{ $related := .RegularPages.RelatedTo ( keyVals "tags" "hugo" "rocks") ( keyVals "date" .Date ) }}
+ RelatedTo(args ...types.KeyValues) (Pages, error)
+}
+```
+## Configure Related Content
+Hugo provides a sensible default configuration of Related Content, but you can fine-tune this in your configuration, on the global or language level if needed.
+
+{{% note %}}
+If you add a `related` config section, you need to add a complete configuration. It is not possible to just set, say, `includeNewer` and use the rest from the Hugo defaults.
+{{% /note %}}
+
+Below is a sample `config.toml` section:
+
+```
+[related]
+
+# Only include matches with rank >= threshold. This is a normalized rank between 0 and 100.
+threshold = 80
+
+# To get stable "See also" sections we, by default, exclude newer related pages.
+includeNewer = false
+
+# Will lower case keywords in both queries and in the indexes.
+toLower = false
+
+[[related.indices]]
+name = "keywords"
+weight = 150
+[[related.indices]]
+name = "author"
+toLower = true
+weight = 30
+[[related.indices]]
+name = "tags"
+weight = 100
+[[related.indices]]
+name = "date"
+weight = 10
+pattern = "2006"
+```
+### Top Level Config Options
+
+threshold
+: A value between 0-100. Lower value will give more, but maybe not so relevant, matches.
+
+includeNewer
+: Set to true to include **pages newer than the current page** in the related content listing. This will mean that the output for older posts may change as new related content gets added.
+
+toLower
+: Set to true to lower case keywords in both the indexes and the queries. This may give more accurate results at a slight performance penalty. Note that this can also be set per index.
+
+### Config Options per Index
+
+name
+: The index name. This value maps directly to a page param. Hugo supports string values (`author` in the example) and lists (`tags`, `keywords` etc.) and time and date objects.
+
+weight
+: An integer weight that indicates _how important_ this parameter is relative to the other parameters. It can be 0, which has the effect of turning this index off, or even negative. Test with different values to see what fits your content best.
+
+pattern
+: This is currently only relevant for dates. When listing related content, we may want to list content that is also close in time. Setting "2006" (default value for date indexes) as the pattern for a date index will add weight to pages published in the same year. For busier blogs, "200601" (year and month) may be a better default.
+
+toLower
+: See above.
+
+## Performance Considerations
+
+**Fast is Hugo's middle name** and we would not have released this feature had it not been blistering fast.
+
+This feature has been in the back log and requested by many for a long time. The development got this recent kick start from this Twitter thread:
+
+{{< tweet 898398437527363585 >}}
+
+Scott S. Lowe removed the "Related Content" section built using the `intersect` template function on tags, and the build time dropped from 30 seconds to less than 2 seconds on his 1700 content page sized blog.
+
+He should now be able to add an improved version of that "Related Content" section without giving up the fast live-reloads. But it's worth noting that:
+
+* If you don't use any of the `Related` methods, you will not use the Relate Content feature, and performance will be the same as before.
+* Calling `.RegularPages.Related` etc. will create one inverted index, also sometimes named posting list, that will be reused for any lookups in that same page collection. Doing that in addition to, as an example, calling `.Pages.Related` will work as expected, but will create one additional inverted index. This should still be very fast, but worth having in mind, especially for bigger sites.
+
+
+
+
+
+
+
diff --git a/docs/content/en/content-management/sections.md b/docs/content/en/content-management/sections.md
new file mode 100644
index 000000000..79ae201d4
--- /dev/null
+++ b/docs/content/en/content-management/sections.md
@@ -0,0 +1,98 @@
+---
+title: Content Sections
+linktitle: Sections
+description: "Hugo generates a **section tree** that matches your content."
+date: 2017-02-01
+publishdate: 2017-02-01
+lastmod: 2017-02-01
+categories: [content management]
+keywords: [lists,sections,content types,organization]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 50
+weight: 50 #rem
+draft: false
+aliases: [/content/sections/]
+toc: true
+---
+
+A **Section** is a collection of pages that gets defined based on the
+organization structure under the `content/` directory.
+
+By default, all the **first-level** directories under `content/` form their own
+sections (**root sections**).
+
+If a user needs to define a section `foo` at a deeper level, they need to create
+a directory named `foo` with an `_index.md` file (see [Branch Bundles][branch bundles]
+for more information).
+
+
+{{% note %}}
+A **section** cannot be defined or overridden by a front matter parameter -- it
+is strictly derived from the content organization structure.
+{{% /note %}}
+
+## Nested Sections
+
+The sections can be nested as deeply as you need.
+
+```bash
+content
+└── blog <-- Section, because first-level dir under content/
+ ├── funny-cats
+ │   ├── mypost.md
+ │   └── kittens <-- Section, because contains _index.md
+ │   └── _index.md
+ └── tech <-- Section, because contains _index.md
+ └── _index.md
+```
+
+**The important part to understand is, that to make the section tree fully navigational, at least the lower-most section needs a content file. (e.g. `_index.md`).**
+
+{{% note %}}
+When we talk about a **section** in correlation with template selection, it is
+currently always the *root section* only (`/blog/funny-cats/mypost/ => blog`).
+
+If you need a specific template for a sub-section, you need to adjust either the `type` or `layout` in front matter.
+{{% /note %}}
+
+## Example: Breadcrumb Navigation
+
+With the available [section variables and methods](#section-page-variables-and-methods) you can build powerful navigation. One common example would be a partial to show Breadcrumb navigation:
+
+{{< code file="layouts/partials/breadcrumb.html" download="breadcrumb.html" >}}
+<ol class="nav navbar-nav">
+ {{ template "breadcrumbnav" (dict "p1" . "p2" .) }}
+</ol>
+{{ define "breadcrumbnav" }}
+{{ if .p1.Parent }}
+{{ template "breadcrumbnav" (dict "p1" .p1.Parent "p2" .p2 ) }}
+{{ else if not .p1.IsHome }}
+{{ template "breadcrumbnav" (dict "p1" .p1.Site.Home "p2" .p2 ) }}
+{{ end }}
+<li{{ if eq .p1 .p2 }} class="active"{{ end }}>
+ <a href="{{ .p1.Permalink }}">{{ .p1.Title }}</a>
+</li>
+{{ end }}
+{{< /code >}}
+
+## Section Page Variables and Methods
+
+Also see [Page Variables](/variables/page/).
+
+{{< readfile file="/content/en/readfiles/sectionvars.md" markdown="true" >}}
+
+## Content Section Lists
+
+Hugo will automatically create pages for each *root section* 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.
+
+## Content *Section* vs Content *Type*
+
+By default, everything created within a section will use the [content `type`][content type] that matches the *root 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/
+[branch bundles]: /content-management/page-bundles/#branch-bundles
diff --git a/docs/content/en/content-management/shortcodes.md b/docs/content/en/content-management/shortcodes.md
new file mode 100644
index 000000000..e56873312
--- /dev/null
+++ b/docs/content/en/content-management/shortcodes.md
@@ -0,0 +1,424 @@
+---
+title: Shortcodes
+linktitle:
+description: Shortcodes are simple snippets inside your content files calling built-in or custom templates.
+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]
+keywords: [markdown,content,shortcodes]
+draft: false
+aliases: [/extras/shortcodes/]
+toc: true
+---
+
+## What a Shortcode is
+
+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.
+
+## Use Shortcodes
+
+{{< youtube 2xkNJL4gJ9E >}}
+
+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:
+
+```
+{{%/* mdshortcode */%}}Stuff to `process` in the *center*.{{%/* /mdshortcode */%}}
+```
+
+```
+{{</* 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>`:
+
+```
+{{%/* 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:
+
+```
+{{</* 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].
+
+## Use 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
+: URL of the image to be displayed.
+
+link
+: If the image needs to be hyperlinked, URL of the destination.
+
+target
+: Optional `target` attribute for the URL if `link` parameter is set.
+
+rel
+: Optional `rel` attribute for the URL if `link` parameter is set.
+
+alt
+: Alternate text for the image if the image cannot be displayed.
+
+title
+: Image title.
+
+caption
+: Image caption.
+
+class
+: `class` attribute of the HTML `figure` tag.
+
+height
+: `height` attribute of the image.
+
+width
+: `width` attribute of the image.
+
+attr
+: Image attribution text.
+
+attrlink
+: If the attribution text needs to be hyperlinked, URL of the destination.
+
+#### Example `figure` Input
+
+{{< code file="figure-input-example.md" >}}
+{{</* figure src="/media/spf13.jpg" title="Steve Francia" */>}}
+{{< /code >}}
+
+#### Example `figure` Output
+
+{{< output file="figure-output-example.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]:
+
+```
+https://gist.github.com/spf13/7896402
+```
+
+We can embed the gist in our content via username and gist ID pulled from the URL:
+
+```
+{{</* 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" >}}
+{{</* gist spf13 7896402 "img.html" */>}}
+{{< /code >}}
+
+#### Example `gist` Output
+
+{{< output file="gist-output.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" >}}
+{{</* 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" >}}
+<span style="color: #f92672">&lt;section</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">&quot;main&quot;</span><span style="color: #f92672">&gt;</span>
+ <span style="color: #f92672">&lt;div&gt;</span>
+ <span style="color: #f92672">&lt;h1</span> <span style="color: #a6e22e">id=</span><span style="color: #e6db74">&quot;title&quot;</span><span style="color: #f92672">&gt;</span>{{ .Title }}<span style="color: #f92672">&lt;/h1&gt;</span>
+ {{ range .Data.Pages }}
+ {{ .Render &quot;summary&quot;}}
+ {{ end }}
+ <span style="color: #f92672">&lt;/div&gt;</span>
+<span style="color: #f92672">&lt;/section&gt;</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:
+
+```
+https://www.instagram.com/p/BWNjjyYFxVx/
+```
+
+#### Example `instagram` Input
+
+{{< code file="instagram-input.md" >}}
+{{</* instagram BWNjjyYFxVx */>}}
+{{< /code >}}
+
+You also have the option to hide the caption:
+
+{{< code file="instagram-input-hide-caption.md" >}}
+{{</* instagram BWNjjyYFxVx 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" >}}
+{{< instagram BWNjjyYFxVx 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 BWNjjyYFxVx 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
+
+```
+[Neat]({{</* ref "blog/neat.md" */>}})
+[Who]({{</* relref "about.md#who" */>}})
+```
+
+#### Example `ref` and `relref` Output
+
+Assuming that standard Hugo pretty URLs are turned on.
+
+```
+<a href="/blog/neat">Neat</a>
+<a href="/about/#who:c28654c202e73453784cfd2c5ab356c0">Who</a>
+```
+
+### `speakerdeck`
+
+To embed slides from [Speaker Deck][], click on "&lt;&#8239;/&gt;&nbsp;Embed" (under Share right next to the template on Speaker Deck) and copy the URL:
+
+```
+<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" >}}
+{{</* speakerdeck 4e8126e72d853c0060001f97 */>}}
+{{< /code >}}
+
+#### `speakerdeck` Example Output
+
+{{< output file="speakerdeck-example-input.md" >}}
+{{< 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/877500564405444608
+```
+
+#### Example `tweet` Input
+
+Pass the tweet's ID from the URL as a parameter to the `tweet` shortcode:
+
+{{< code file="example-tweet-input.md" >}}
+{{</* tweet 877500564405444608 */>}}
+{{< /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" >}}
+{{< tweet 877500564405444608 >}}
+{{< /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 877500564405444608 >}}
+
+### `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" >}}
+{{</* 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" >}}
+{{< 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.
+
+```
+{{</* 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" >}}
+{{</* 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" >}}
+{{</* 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" >}}
+{{< 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 >}}
+
+## Create 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/
diff --git a/docs/content/en/content-management/static-files.md b/docs/content/en/content-management/static-files.md
new file mode 100644
index 000000000..fe5ea77e0
--- /dev/null
+++ b/docs/content/en/content-management/static-files.md
@@ -0,0 +1,48 @@
+---
+title: Static Files
+description: "The `static` folder is where you place all your **static files**."
+date: 2017-11-18
+categories: [content management]
+keywords: [source, directories]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 130
+weight: 130 #rem
+aliases: [/static-files]
+toc: true
+---
+
+The `static` folder is where you place all your **static files**, e.g. stylesheets, JavaScript, images etc.
+
+You can set the name of the static folder to use in your configuration file. From **Hugo 0.31** you can configure as many static directories as you need. All the files in all the static directories will form a union filesystem.
+
+Example:
+
+{{< code-toggle copy="false" file="config" >}}
+staticDir = ["static1", "static2"]
+[languages]
+[languages.no]
+staticDir = ["staticDir_override", "static_no"]
+baseURL = "https://example.no"
+languageName = "Norsk"
+weight = 1
+title = "På norsk"
+
+[languages.en]
+staticDir2 = "static_en"
+baseURL = "https://example.com"
+languageName = "English"
+weight = 2
+title = "In English"
+{{</ code-toggle >}}
+
+In the above, with no theme used:
+
+* The English site will get its static files as a union of "static1", "static2" and "static_en". On file duplicates, the right-most version will win.
+* The Norwegian site will get its static files as a union of "staticDir_override" and "static_no".
+
+**Note:** The `2` `static2` (can be a number between 0 and 10) is added to tell Hugo that you want to **add** this directory to the global set of static directories. Using `staticDir` on the language level would replace the global value.
+
+
+**Note:** The example above is a [multihost setup](/content-management/multilingual/#configure-multilingual-multihost). In a regular setup, all the static directories will be available to all sites.
diff --git a/docs/content/en/content-management/summaries.md b/docs/content/en/content-management/summaries.md
new file mode 100644
index 000000000..1c341400e
--- /dev/null
+++ b/docs/content/en/content-management/summaries.md
@@ -0,0 +1,81 @@
+---
+title: Content Summaries
+linktitle: Summaries
+description: Hugo generates summaries of your content.
+date: 2017-01-10
+publishdate: 2017-01-10
+lastmod: 2017-01-10
+categories: [content management]
+keywords: [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 generates summaries of content to use as a short version in summary views.
+
+## Summary Splitting Options
+
+* Hugo-defined Summary Split
+* User-defined Summary Split
+
+It is natural to accompany the summary with links to the original content, and a common design pattern is to see this link in the form of a "Read More ..." button. See 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 put into one paragraph.
+
+{{% note %}}
+The Hugo-defined summaries are set to use word count calculated by splitting the text by one or more consecutive white space characters. 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>&#60;&#33;&#45;&#45;more&#45;&#45;&#62;</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>&#60;&#33;&#45;&#45;more&#45;&#45;&#62;</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>&#60;&#33;&#45;&#45;more&#45;&#45;&#62;</code> exactly; i.e., all lowercase and with no whitespace.
+{{% /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" >}}
+{{ 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/ \ No newline at end of file
diff --git a/docs/content/en/content-management/syntax-highlighting.md b/docs/content/en/content-management/syntax-highlighting.md
new file mode 100644
index 000000000..b2d7a4552
--- /dev/null
+++ b/docs/content/en/content-management/syntax-highlighting.md
@@ -0,0 +1,193 @@
+---
+title: Syntax Highlighting
+description: Hugo comes with really fast syntax highlighting from Chroma.
+date: 2017-02-01
+publishdate: 2017-02-01
+keywords: [highlighting,pygments,chroma,code blocks,syntax]
+categories: [content management]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 300
+weight: 20
+sections_weight: 20
+draft: false
+aliases: [/extras/highlighting/,/extras/highlight/,/tools/syntax-highlighting/]
+toc: true
+---
+
+From Hugo 0.28, the default syntax hightlighter in Hugo is [Chroma](https://github.com/alecthomas/chroma); it is built in Go and is really, really fast -- and for the most important parts compatible with Pygments.
+
+If you want to continue to use Pygments (see below), set `pygmentsUseClasses=true` in your site config.
+
+The example below shows a simple code snippet from the Hugo source highlighted with the `highlight` shortcode. Note that the gohugo.io site is generated with `pygmentsUseClasses=true` (see [Generate Syntax Highlighter CSS](#generate-syntax-highlighter-css)).
+
+* `linenos=inline` or `linenos=table` (`table` will give copy-and-paste friendly code blocks) turns on line numbers.
+* `hl_lines` lists a set of line numbers or line number ranges to be highlighted. Note that the hyphen range syntax is only supported for Chroma.
+* `linenostart=199` starts the line number count from 199.
+
+With that, this:
+
+```
+{{</* highlight go "linenos=table,hl_lines=8 15-17,linenostart=199" */>}}
+// ... code
+{{</* / highlight */>}}
+```
+
+Gives this:
+
+{{< highlight go "linenos=table,hl_lines=8 15-17,linenostart=199" >}}
+// GetTitleFunc returns a func that can be used to transform a string to
+// title case.
+//
+// The supported styles are
+//
+// - "Go" (strings.Title)
+// - "AP" (see https://www.apstylebook.com/)
+// - "Chicago" (see http://www.chicagomanualofstyle.org/home.html)
+//
+// If an unknown or empty style is provided, AP style is what you get.
+func GetTitleFunc(style string) func(s string) string {
+ switch strings.ToLower(style) {
+ case "go":
+ return strings.Title
+ case "chicago":
+ tc := transform.NewTitleConverter(transform.ChicagoStyle)
+ return tc.Title
+ default:
+ tc := transform.NewTitleConverter(transform.APStyle)
+ return tc.Title
+ }
+}
+{{< / highlight >}}
+
+
+## Configure Syntax Highlighter
+To make the transition from Pygments to Chroma seamless, they share a common set of configuration options:
+
+pygmentsOptions
+: A comma separated list of options. See below for a full list.
+
+pygmentsCodefences
+: Set to true to enable syntax highlighting in code fences with a language tag in markdown (see below for an example).
+
+pygmentsStyle
+: The style of code highlighting. See https://help.farbox.com/pygments.html for a gallery. Note that this option is not relevant when `pygmentsUseClasses` is set.
+
+pygmentsUseClasses
+: Set to `true` to use CSS classes to format your highlighted code. See [Generate Syntax Highlighter CSS](#generate-syntax-highlighter-css).
+
+pygmentsCodefencesGuessSyntax
+: Set to `true` to try to do syntax highlighting on code fenced blocks in markdown without a language tag.
+
+pygmentsUseClassic
+: Set to true to use Pygments instead of the much faster Chroma.
+
+### Options
+
+`pygmentsOptions` can be set either in site config or overridden per code block in the Highlight shortcode or template func.
+
+noclasses
+: Use inline style.
+
+linenos
+: For Chroma, any value in this setting will print line numbers. Pygments has some more fine grained control.
+
+linenostart
+: Start the line numbers from this value (default is 1).
+
+
+hl_lines
+: Highlight a space separated list of line numbers. For Chroma, you can provide a list of ranges, i.e. "3-8 10-20".
+
+
+The full set of supported options for Pygments is: `encoding`, `outencoding`, `nowrap`, `full`, `title`, `style`, `noclasses`, `classprefix`, `cssclass`, `cssstyles`, `prestyles`, `linenos`, `hl_lines`, `linenostart`, `linenostep`, `linenospecial`, `nobackground`, `lineseparator`, `lineanchors`, `linespans`, `anchorlinenos`, `startinline`. See the [Pygments HTML Formatter Documentation](http://pygments.org/docs/formatters/#HtmlFormatter) for details.
+
+
+## Generate Syntax Highlighter CSS
+
+If you run with `pygmentsUseClasses=true` in your site config, you need a style sheet.
+
+You can generate one with Hugo:
+
+```bash
+hugo gen chromastyles --style=monokai > syntax.css
+```
+
+Run `hugo gen chromastyles -h` for more options. See https://help.farbox.com/pygments.html for a gallery of available styles.
+
+
+## Highlight Shortcode
+
+Highlighting is carried out via the [built-in shortcode](/content-management/shortcodes/) `highlight`. `highlight` takes exactly one required parameter for the programming language to be highlighted and requires a closing shortcode. Note that `highlight` is *not* used for client-side javascript highlighting.
+
+### Example `highlight` Shortcode
+
+{{< code file="example-highlight-shortcode-input.md" >}}
+{{</* highlight html */>}}
+<section id="main">
+ <div>
+ <h1 id="title">{{ .Title }}</h1>
+ {{ range .Data.Pages }}
+ {{ .Render "summary"}}
+ {{ end }}
+ </div>
+</section>
+{{</* /highlight */>}}
+{{< /code >}}
+
+
+
+## Highlight Template Func
+
+See [Highlight](/functions/highlight/).
+
+## Highlight in Code Fences
+
+It is also possible to add syntax highlighting with GitHub flavored code fences. To enable this, set the `pygmentsCodeFences` to `true` in Hugo's [configuration file](/getting-started/configuration/);
+
+````
+```go-html-template
+<section id="main">
+ <div>
+ <h1 id="title">{{ .Title }}</h1>
+ {{ range .Data.Pages }}
+ {{ .Render "summary"}}
+ {{ end }}
+ </div>
+</section>
+```
+````
+
+## List of Chroma Highlighting Languages
+
+The full list of Chroma lexers and their aliases (which is the identifier used in the `hightlight` template func or when doing highlighting in code fences):
+
+{{< chroma-lexers >}}
+
+## Highlight with Pygments Classic
+
+If you for some reason don't want to use the built-in Chroma highlighter, you can set `pygmentsUseClassic=true` in your config and add Pygments to your path.
+
+{{% note "Disclaimers on Pygments" %}}
+* 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`.
+* The languages available for highlighting depend on your Pygments installation.
+{{% /note %}}
+
+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 will not be able to find and use it.
+
+On Debian and Ubuntu systems, you may also install Pygments by running `sudo apt-get install python3-pygments`.
+
+
+
+[Prism]: http://prismjs.com
+[prismdownload]: http://prismjs.com/download.html
+[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/
diff --git a/docs/content/en/content-management/taxonomies.md b/docs/content/en/content-management/taxonomies.md
new file mode 100644
index 000000000..287c6f899
--- /dev/null
+++ b/docs/content/en/content-management/taxonomies.md
@@ -0,0 +1,193 @@
+---
+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
+keywords: [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 of logical relationships between content.
+
+### Definitions
+
+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
+
+{{< youtube pCPCQgqC8RA >}}
+
+## 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 Sixth Sense <- Value
+ Unbreakable <- Value
+ Moonrise Kingdom <- Value
+ Samuel L. Jackson <- Term
+ Unbreakable <- Value
+ The Avengers <- Value
+ xXx <- Value
+```
+
+From the perspective of the content, the relationships would appear differently, although the data and labels used are the same:
+
+```
+Unbreakable <- Value
+ Actors <- Taxonomy
+ Bruce Willis <- Term
+ Samuel L. Jackson <- Term
+ Director <- Taxonomy
+ M. Night Shyamalan <- Term
+ ...
+Moonrise Kingdom <- Value
+ Actors <- Taxonomy
+ Bruce Willis <- Term
+ Bill Murray <- Term
+ Director <- Taxonomy
+ Wes Anderson <- Term
+ ...
+```
+
+## Hugo Taxonomy Defaults
+
+Hugo natively supports taxonomies.
+
+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 any taxonomies, set `disableKinds` in your site's configuration to the following:
+
+```
+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 configuration and used in your content front matter will create the following pages:
+
+* A single page at `example.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][]
+
+## Configure 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: Taxonomy Configuration
+
+{{< code-toggle copy="false" >}}
+[taxonomies]
+ tag = "tags"
+ category = "categories"
+ series = "series"
+{{</ code-toggle >}}
+
+### Preserve Taxonomy Values
+
+By default, taxonomy names are normalized.
+
+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.
+
+Much like regular pages, taxonomy list [permalinks](/content-management/urls/) are configurable, but taxonomy term page permalinks are not.
+{{% /note %}}
+
+## Add 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: Front Matter with Taxonomies
+
+{{< code-toggle copy="false">}}
+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/gohugoio/hugo"
+{{</ code-toggle >}}
+
+## Order 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: Taxonomic `weight`
+
+{{< code-toggle copy="false" >}}
+title = "foo"
+tags = [ "a", "b", "c" ]
+tags_weight = 22
+categories = ["d"]
+categories_weight = 44
+{{</ code-toggle >}}
+
+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 %}}
+
+## Add custom metadata to a Taxonomy Term
+
+If you need to add custom metadata to your taxonomy terms, you will need to create a page for that term at `/content/<TAXONOMY>/<TERM>/_index.md` and add your metadata in it's front matter. Continuing with our 'Actors' example, let's say you want to add a wikipedia page link to each actor. Your terms pages would be something like this:
+
+{{< code file="/content/actors/bruce-willis/_index.md" >}}
+ ---
+ title: "Bruce Willis"
+ wikipedia: "https://en.wikipedia.org/wiki/Bruce_Willis"
+ ---
+{{< /code >}}
+
+You can later use your custom metadata as shown in the [Taxonomy Terms Templates documentation](/templates/taxonomy-templates/#displaying-custom-metadata-in-taxonomy-terms-templates).
+
+[`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/
diff --git a/docs/content/en/content-management/toc.md b/docs/content/en/content-management/toc.md
new file mode 100644
index 000000000..681416a72
--- /dev/null
+++ b/docs/content/en/content-management/toc.md
@@ -0,0 +1,95 @@
+---
+title: Table of Contents
+linktitle:
+description: Hugo can automatically parse Markdown content and create a Table of Contents you can use in your templates.
+date: 2017-02-01
+publishdate: 2017-02-01
+lastmod: 2017-02-01
+categories: [content management]
+keywords: [table of contents, toc]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 130
+weight: 130 #rem
+draft: false
+aliases: [/extras/toc/,/content-management/toc/]
+toc: true
+---
+
+{{% 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/gohugoio/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:
+
+```
+<!-- 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.'
+
+{{% note "Table of contents not available for MMark" %}}
+Hugo documents created in the [MMark](/content-management/formats/#mmark) Markdown dialect do not currently display TOCs. TOCs are, however, compatible with all other supported Markdown formats.
+{{% /note %}}
+
+## 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" >}}
+{{ 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" >}}
+{{ 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/ \ No newline at end of file
diff --git a/docs/content/en/content-management/types.md b/docs/content/en/content-management/types.md
new file mode 100644
index 000000000..dc412af19
--- /dev/null
+++ b/docs/content/en/content-management/types.md
@@ -0,0 +1,99 @@
+---
+title: Content Types
+linktitle: Types
+description: Hugo supports sites with multiple content types and assumes your site will be organized into sections, where each section represents the corresponding type.
+date: 2017-02-01
+publishdate: 2017-02-01
+lastmod: 2017-02-01
+categories: [content management]
+keywords: [lists,sections,content types,types,organization]
+menu:
+ docs:
+ parent: "content-management"
+ weight: 60
+weight: 60 #rem
+draft: false
+aliases: [/content/types]
+toc: true
+---
+
+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.
+
+## Assign a Content Type
+
+Hugo assumes that your site will be organized into [sections][] and each section represents 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`".
+
+## Create New Content of a Specific Type
+
+You can manually add files to your content directories, but Hugo can create and populate a new content file with preconfigured front matter via [archetypes][].
+
+## Define a Content Type
+
+Creating a new content type is easy. You simply define the templates and archetype unique to your new content type, or Hugo will use defaults.
+
+
+{{% 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" >}}
++++
+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/gohugoio/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/
diff --git a/docs/content/en/content-management/urls.md b/docs/content/en/content-management/urls.md
new file mode 100644
index 000000000..d33725b72
--- /dev/null
+++ b/docs/content/en/content-management/urls.md
@@ -0,0 +1,275 @@
+---
+title: URL Management
+linktitle: URL Management
+description: Hugo supports 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
+keywords: [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., `public` 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.
+
+### Permalinks Configuration Example
+
+{{< code-toggle file="config" copy="false" >}}
+permalinks:
+ post: /:year/:month/:title/
+{{< /code-toggle >}}
+
+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 `https://example.com/2017/02/sample-entry/`.
+
+You can also configure permalinks of taxonomies with the same syntax, by using the plural form of the taxonomy instead of the section. You will probably only want to use the configuration values `:slug` or `:title`.
+
+### 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
+
+`:sections`
+: the content's sections hierarchy
+
+`: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" >}}
++++
+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" >}}
+---
+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 `example.com/posts/my-original-url/` will be immediately redirected to `example.com/posts/my-awesome-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`:
+
+```
+---
+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:
+
+```
+---
+title: My New post
+aliases: [/posts/my-old-url/]
+---
+```
+
+Assuming a `baseURL` of `example.com`, the contents of the auto-generated alias `.html` found at `https://example.com/posts/my-old-url/` will contain the following:
+
+```
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>https://example.com/posts/my-intended-url</title>
+ <link rel="canonical" href="https://example.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=https://example.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://example.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 that they should not crawl and index your new alias page.
+
+### Customize
+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:
+
+```
+content/posts/_index.md
+=> example.com/posts/index.html
+content/posts/post-1.md
+=> example.com/posts/post-1/
+```
+
+## Ugly URLs
+
+If you would like to have what are often referred to as "ugly URLs" (e.g., example.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.
+
+```
+.
+└── content
+ └── about
+ | └── _index.md // <- https://example.com/about/
+ ├── post
+ | ├── firstpost.md // <- https://example.com/post/firstpost/
+ | ├── happy
+ | | └── ness.md // <- https://example.com/post/happy/ness/
+ | └── secondpost.md // <- https://example.com/post/secondpost/
+ └── quote
+ ├── first.md // <- https://example.com/quote/first/
+ └── second.md // <- https://example.com/quote/second/
+```
+
+Here's the same organization run with `hugo --uglyURLs`:
+
+```
+.
+└── content
+ └── about
+ | └── _index.md // <- https://example.com/about.html
+ ├── post
+ | ├── firstpost.md // <- https://example.com/post/firstpost.html
+ | ├── happy
+ | | └── ness.md // <- https://example.com/post/happy/ness.html
+ | └── secondpost.md // <- https://example.com/post/secondpost.html
+ └── quote
+ ├── first.md // <- https://example.com/quote/first.html
+ └── second.md // <- https://example.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://example.com/`, the relative URL `/css/foo.css` would be turned into the absolute URL `https://example.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.
+
+```
+hugo config | grep -i canon
+```
+
+Or, if you are on Windows and do not have `grep` installed:
+
+```
+hugo config | FINDSTR /I canon
+```
+
+## Override 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/