Merge commit '83bef6955e014d40c0f00db9cebe09113154e999'

36 files changed, 450 insertions, 0 deletions

diff --git a/docs/content/en/showcase/1password-support/bio.md b/docs/content/en/showcase/1password-support/bio.md
new file mode 100644
index 000000000..9187908d9
--- /dev/null
+++ b/docs/content/en/showcase/1password-support/bio.md
@@ -0,0 +1,5 @@
+
+**1Password** is a password manager that keeps you safe online. It protects your secure information behind the one password only you know.
+
+
+The [1Password Support](https://support.1password.com/) website was built from scratch with **Hugo** and enhanced with **React** and **Elasticsearch** to give us the best of both worlds: The simplicity and performance of a static site, with the richness of a hosted web app.
diff --git a/docs/content/en/showcase/1password-support/featured.png b/docs/content/en/showcase/1password-support/featured.png
new file mode 100644
index 000000000..8e46495e6
--- /dev/null
+++ b/docs/content/en/showcase/1password-support/featured.png
diff --git a/docs/content/en/showcase/1password-support/index.md b/docs/content/en/showcase/1password-support/index.md
new file mode 100644
index 000000000..55038bc7e
--- /dev/null
+++ b/docs/content/en/showcase/1password-support/index.md
@@ -0,0 +1,39 @@
+---
+
+title: 1Password Support
+date: 2018-02-22
+description: "Showcase: \"Compiles 400 pages in five languages in the blink of an eye.\""
+siteURL: https://support.1password.com/
+byline: "[Mitch Cohen](https://github.com/mitchchn), Documentation Team Lead"
+aliases: [/showcase/1password/]
+
+---
+
+At 1Password, we used to go through a different documentation platform every month: blog engines, ebooks, wikis, site generators written in Ruby and JavaScript. Each was inadequate in its own special way. Then we found **Hugo**. We made one last switch, and we're glad we did.
+
+### Not all static site generators are created equal
+
+Finding a tool that will make your customers, writers, designers, _and_ DevOps team happy is no easy task, but we managed it with Hugo:
+
+**Hugo is static**. We're a security company, so we swear by static sites and use them wherever possible. We feel much safer pointing customers at HTML files than at a complicated server which needs to be hardened.
+
+**Hugo is Go**. We love the Go programming language at 1Password, and we were delighted to learn that Hugo used the same Go template syntax that our designers and front-end developers had already mastered.
+ 
+**Hugo is FAST**. Our previous static site generator took nearly a minute to compile our (then much smaller) site. Developers might be used to this, but it wasn't cutting it for writers who wanted to see live previews of their work. Hugo did the same job in milliseconds, and to this day compiles 400 pages in five languages in the blink of an eye.
+
+**Hugo is flexible**. Thanks to Hugo's content and layout system, we were able to preserve our existing file and folder structure and port our entire production site in a few days. We could then create new content types that weren't possible before, like these snazzy [showcases](https://support.1password.com/explore/extension/).
+
+**Hugo is great for writers**. Our documentation team was already comfortable with Markdown and Git and could start creating content for Hugo with zero downtime. Once we added shortcodes, our writers were able to dress up articles with features like  [platform boxes](https://support.1password.com/get-the-apps/) with just a bit of new syntax.
+
+**Hugo has an amazing developer community**. Hugo updates are frequent and filled to the brim with features and fixes. As we developed the multilingual version of our site, we submitted PRs for features we needed and were helped through the process by [@bep](https://github.com/bep) and others.
+
+**Hugo is simple to deploy**. Hugo has just the right amount of configuration options to fit into our build system without being too complicated.
+
+### Tech specs
+
+* [1Password Support](https://support.1password.com) uses Hugo with a custom theme. It shares styles and some template code with [1Password.com](https://1password.com), which we also moved to Hugo in 2016.
+* Code and articles live in a private GitHub repository, which is deployed to a static content server using Git hooks.
+* Writers build and preview the site on their computers and contribute content using pull requests.
+ * We use Hugo's [multilingual support](/content-management/multilingual/) to build the site in English, Spanish, French, Italian, German, and Russian. With the help of Hugo, 1Password Support became our very first site in multiple languages.
+* Our [contact form](https://support.1password.com/contact) is a single-page React app. We were able to integrate it with Hugo seamlessly thanks to its support for static files.
+* The one part of the support site which is not static is our search engine, which we developed with Elasticsearch and host on AWS.
diff --git a/docs/content/en/showcase/flesland-flis/bio.md b/docs/content/en/showcase/flesland-flis/bio.md
new file mode 100644
index 000000000..c1a4e8187
--- /dev/null
+++ b/docs/content/en/showcase/flesland-flis/bio.md
@@ -0,0 +1,8 @@
+
+A business page for Flesland Flis AS. A Norwegian Tiler located in Bergen.
+
+The page is designed and developed by Sindre Gusdal:
+
+* [Absoluttweb AS](http://www.absoluttweb.no)
+* [Sindre Gusdal](https://www.linkedin.com/in/sindregusdal/)
+
diff --git a/docs/content/en/showcase/flesland-flis/featured.png b/docs/content/en/showcase/flesland-flis/featured.png
new file mode 100644
index 000000000..a6dae684e
--- /dev/null
+++ b/docs/content/en/showcase/flesland-flis/featured.png
diff --git a/docs/content/en/showcase/flesland-flis/index.md b/docs/content/en/showcase/flesland-flis/index.md
new file mode 100644
index 000000000..5e18f040c
--- /dev/null
+++ b/docs/content/en/showcase/flesland-flis/index.md
@@ -0,0 +1,24 @@
+---
+
+title: Flesland Flis AS
+date: 2018-04-24
+description: "showcase: Business Page for a tile shop in Bergen, Norway"
+siteURL: https://www.fleslandflis.no
+byline: "[Sindre Gusdal](http://www.absoluttweb.no), Absoluttweb AS"
+
+---
+
+For **Flesland Flis** I use a combination of **Hugo, Forestry.io and Netlify**. Static Site Generators and Hugo has been on my radar for a long time, and with all the nice features released in Hugo the last years, it's now my preferred solution for new clients. Also a huge thanks to the guys at [Forestry.io](https://forestry.io), for making such a smooth CMS for Hugo.
+
+The #1 reason why I love Hugo is the logic between content and layout, and of course the speed. Compared to solutions like Jekyll, Hugo is just better at all the stuff I value the most - speed, flexibility, theming and more.
+
+### Thanks, Hugo!
+
+Today I use Hugo in a combination with GULP and Foundation 6 + my own Hugo starter theme. This works great for me, and gives me all the flexibility I need. Then I can include FancyBox, Responsive Text and other Node Modules when needed.
+
+In the past I had to do a lot of changes to layout, content and css, if the client f.ex needed an extra PDF or an image-gallery to a certain page. Just small details not fitting in the template, would be a hassle. So updating existing webpages was boring and time consuming.
+
+Today I just copy-paste a new layout file, adds some frontmatter, Pushes to GIT and that special page is done.
+
+**Gotta love it:)**
+
diff --git a/docs/content/en/showcase/forestry/bio.md b/docs/content/en/showcase/forestry/bio.md
new file mode 100644
index 000000000..767365cc0
--- /dev/null
+++ b/docs/content/en/showcase/forestry/bio.md
@@ -0,0 +1,5 @@
+
+Forestry.io is a Git-backed CMS (content management system) for websites and web products built using static site generators such as Hugo. 
+
+Forestry bridges the gap between developers and their teams, by making development fun and easy, while providing powerful content management for their teams.
+
diff --git a/docs/content/en/showcase/forestry/featured.png b/docs/content/en/showcase/forestry/featured.png
new file mode 100644
index 000000000..1ee315e78
--- /dev/null
+++ b/docs/content/en/showcase/forestry/featured.png
diff --git a/docs/content/en/showcase/forestry/index.md b/docs/content/en/showcase/forestry/index.md
new file mode 100644
index 000000000..1a9c0faaa
--- /dev/null
+++ b/docs/content/en/showcase/forestry/index.md
@@ -0,0 +1,48 @@
+---
+title: Forestry.io
+date: 2018-03-16
+description: "Showcase: \"Seeing Hugo in action is a whole different world of awesome.\""
+siteURL: https://forestry.io/
+siteSource: https://github.com/forestryio/forestry.io
+---
+
+It was clear from the get-go that we had to go with a static site generator. Static sites are secure, performant, and give you 100% flexibility. At [Forestry.io](https://forestry.io/) we provide Content Management Solutions for websites built with static site generators, so we might be a little biased. The only question: Which static site generator was the right choice for us?
+
+### Why Hugo?
+
+In our early research we looked at Ionic’s [site](https://github.com/ionic-team/ionic) to get some inspiration. They used Jekyll to build their website. While Jekyll is a great generator, the build times for larger sites can be painfully slow. With more than 150 pages plus many custom configurations and add-ons, our website doesn’t fall into the low-volume category anymore. Our developers want a smooth experience when working on the website and our content editors need the ability to preview content quickly. In short, we need our builds to be lightning fast.
+
+We knew Hugo was fast but we did [some additional benchmarking](https://forestry.io/blog/hugo-vs-jekyll-benchmark/) before making our decision. Seeing Hugo in action is a whole different world of awesome. Hugo takes less than one second to build our 150-page site! Take a look:
+
+```bash
+                   | EN   
++------------------+-----+
+  Pages            | 141  
+  Paginator pages  |   4  
+  Non-page files   |   0  
+  Static files     | 537  
+  Processed images |   0  
+  Aliases          |  60  
+  Sitemaps         |   1  
+  Cleaned          |   0  
+
+Total in 739 ms
+```
+
+In fact, we liked Hugo so much that our wizard Chris made his workflow public and we started the open-source project [Create-Static-Site](https://github.com/forestryio/create-static-site). It's [a simple way to spin up sites](https://forestry.io/blog/up-and-running-with-hugo/) and set up a modern web development workflow with one line of code. Essentially it adds build configurations as a dependency for JS, CSS and Image Processing.
+
+Lastly, we want to take the opportunity to give some love to other amazing tools we used building our website.
+
+### What tools did we use?
+
+* Our Norwegian designer Nichlas is in love with [**Sketch**](https://www.sketchapp.com/). From what we hear it’s a designer’s dream come true.
+* Some say our main graphic is [mesmerizing](https://twitter.com/hmncllctv/status/968907474664284160). Nichlas created it using [**3DS Max**](https://www.autodesk.com/products/3ds-max/overview).
+* [**Hugo**](https://gohugo.io/) -- of course.
+* Chris can’t think of modern web development without [**Gulp**](https://gulpjs.com/) & [**Webpack**](https://webpack.js.org/). We used them to add additional build steps such as Browsersync, CSS, JS and SVG optimization.
+* Speaking about adding steps to our build, our lives would be much harder without [**CircleCI**](https://circleci.com/) for continuous deployment and automated testing purposes.
+* We can’t stop raving about [**Algolia**](https://www.algolia.com/). Chris loves it and even wrote a tutorial on [how to implement Algolia](https://forestry.io/blog/search-with-algolia-in-hugo/) into static sites using Hugo’s [Custom Outputs](https://gohugo.io/templates/output-formats/).
+*  [**Cloudinary**](https://cloudinary.com/) is probably one of the easiest ways to get responsive images into your website.
+* We might be a little biased on this one - We think [**Forestry.io**](https://forestry.io/) is a great way to add a content management system with a clean UI on top of your site without interrupting your experience as a developer.
+* For hosting purposes we use the almighty [**AWS**](https://aws.amazon.com/).
+* [**Formspree.io**](https://formspree.io/) is managing our support and enterprise requests.
+* We also use browser cookies and JS to customize our user’s experience and give it a more dynamic feel.
\ No newline at end of file
diff --git a/docs/content/en/showcase/hartwell-insurance/bio.md b/docs/content/en/showcase/hartwell-insurance/bio.md
new file mode 100644
index 000000000..8bfdad49d
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/bio.md
@@ -0,0 +1,6 @@
+
+Hartwell Insurance is an insurance company set up solely to service the Broker community.
+
+By combining **Hugo**, **Service Worker** and **Netlify**, we were able to achieve incredible global site performance.
+
+The site was built by [Tomango](http://www.tomango.co.uk)
diff --git a/docs/content/en/showcase/hartwell-insurance/featured.png b/docs/content/en/showcase/hartwell-insurance/featured.png
new file mode 100644
index 000000000..ced251f98
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/featured.png
diff --git a/docs/content/en/showcase/hartwell-insurance/hartwell-columns.png b/docs/content/en/showcase/hartwell-insurance/hartwell-columns.png
new file mode 100644
index 000000000..eb669b5a3
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/hartwell-columns.png
diff --git a/docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.png b/docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.png
new file mode 100644
index 000000000..672a8c1c8
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/hartwell-lighthouse.png
diff --git a/docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.png b/docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.png
new file mode 100644
index 000000000..8dc035f3e
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/hartwell-webpagetest.png
diff --git a/docs/content/en/showcase/hartwell-insurance/index.md b/docs/content/en/showcase/hartwell-insurance/index.md
new file mode 100644
index 000000000..3e9c224c8
--- /dev/null
+++ b/docs/content/en/showcase/hartwell-insurance/index.md
@@ -0,0 +1,69 @@
+---
+
+title: Hartwell Insurance
+
+date: 2018-02-09
+
+description: "Showcase: \"Hugo + Netlify + PWA makes for a rapid website.\""
+
+siteURL: https://www.hartwell-insurance.com/
+
+byline: "[Trys Mudford](http://www.trysmudford.com), Lead Developer, Tomango"
+
+---
+
+We’ve just launched a shiny new website for [Hartwell Insurance](https://www.hartwell-insurance.com/) – I’m really proud of it. It was tackled in a different way to most previous Tomango site builds, using some fancy new tools and some vintage web standards.
+
+It’s a multi-page, single-page (!) website written in Hugo, a static site generator built with performance as a first-class feature. _I’ve outlined a load of benefits to Hugo & static sites [here](https://why-static.netlify.com/), in case you’re interested._
+
+> **In essence, a static site generator pre-renders the whole site into HTML files and serves them like it’s 1995.**
+
+There’s no Apache or Node backend that does compilation at runtime, it’s all done at the build step. This means the server; Netlify in this case, only has to do one thing – serve files. Unsurprisingly, serving simple files is VERY quick.
+
+The starter point was the [Victor Hugo](https://github.com/netlify/victor-hugo) repository that Netlify have created. It let me dive in with Hugo, PostCSS, BrowserSync and ES6 without setting up any tooling myself – always a win!
+
+I then took all the content from the design file and moved it into Markdown, putting shortcodes in where necessary. This site did need a number of custom shortcodes for the presentational elements like the expanding circles and full width backgrounds. But mostly it was just clean, semantic HTML with some CSS and JS enhancement thrown in.
+
+For example, this two column layout shown below. I used CSS Columns with a  `break-after: always;` on the `<h1>`. No multi-wrapper or difficult-to-clear shortcodes, just clean HTML.
+
+![The multi-column setup on Hartwell Insurance](hartwell-columns.png)
+
+For the ripple effects on the section headings, I used JS to prepend a `<canvas>` element then animated it with `RequestAnimationFrame`. It adds a nice bit of movement on the page.
+
+On the [Hartwell Profitmaker](https://www.hartwell-insurance.com/profitmaker/) section, I toyed with the idea of using Vue.js for the calculator, but after giving it some thought, I decided to code in Vanilla. The result, all of the site JS comes in at 3.2KB!
+
+The plan was to host with Netlify and therefore get access to Netlify Forms. It meant spending 0 minutes on getting a backend set up – I could focus fully on the frontend.
+
+Cache invalidation isn’t normally something I spend all that much time thinking about when building a site. But as this site was going to be a Progressive Web App, invalidating files would be important to ensure the site didn’t appear broken when we made changes. As I was using Victor-Hugo, I wasn’t really sure how to best tackle this and sadly spent far too many hours wrangling with Webpack and Gulp files to try and get hashed file names working nicely.
+
+Then; while I was waiting for a haircut, I read a [Netlify blog post](https://www.netlify.com/blog/2017/02/23/better-living-through-caching/) on how they do cache invalidation with HTTP2 and it promptly blew my mind.
+
+When you request an asset, they send an ETag in the headers which is a hash of the file. There’s also a header to tell the browser not to trust it’s own cache (which sounds a little bit bonkers).
+
+So when you request the page, it opens a persistent HTTP2 connection up (so no new connections for file requests). When it gets to requesting that asset, the browser sends the ETag back to Netlify and they either return nothing if the ETag matches, or the new file with the new ETag. No `app.klfjlkdsfjdslkfjdslkfdsj.js` or `app.js?v=20180112`. Just a clean `app.js` with instant cache invalidation. Amazing.
+
+Finally, the [Service Worker](https://www.hartwell-insurance.com/sw.js) could be added. This turned out to be straightforward as the Netlify cache invalidation system solved most of the pain points. I went for a network-first, cache-fallback setup for both assets and HTML. This does mean flaky speeds are reliant on the page connection time, but given we’re on HTTP2, I’m hoping the persistent connection and tiny ETag size will keep it quick. For online connections, every request is up to date and instantly live after any update. Offline connections fall back to every assets’ last cached state. It seems to work really nicely, and there’s no need for an update prompt if assets have changed.
+
+---
+
+## The results
+
+The WebPageTest results are looking good. The speed index is 456, 10x smaller than the average Alexa top 300,000 score.
+
+![WebPageTest results](hartwell-webpagetest.png)
+
+[TestMySite.io](https://testmysite.io/5a7e1bb2df99531a23c9ad2f/hartwell-insurance.com) is return ~2ms time to first byte from the CDN edge nodes. Lighthouse audits are also very promising. There’s still some improvement to be gained lazy-loading the images and inlining the CSS. I’m less excited about the [second suggestion](http://www.trysmudford.com/css-in-2017/), but I’ll certainly look at some lazy-loading, especially as I’m already using `IntersectionObserver` for some animations.
+
+![Lighthouse results](hartwell-lighthouse.png)
+
+The most encouraging result is how quick the site is around the world. Most Tomango clients (and their customers) are pretty local and almost exclusively UK-based. We have a dedicated server in Surrey that serves our market pretty well. It did take me by surprise just how much slower a connection from the USA, Australia and Japan to our server was. They’re waiting ~500ms just for the first byte, let alone downloading each asset.
+
+[Hartwell Insurance](https://www.hartwell-insurance.com/) are a US company so by putting them on our server, we’d be instantly hampering their local response times by literally seconds. This was one of the main reasons for going with Netlify. They provide global CDN hosting that’s quick from anywhere in the world.
+
+---
+
+This project was such a blast to develop, it’s a real pleasure to put new technologies to good use in production, and to see real performance and usability benefits from them. Even using classic web methods of serving folders with files is fun when you’ve been databasing for a while – there’s something really ‘pure’ about it.
+
+---
+
+_This was originally posted on [my website](http://www.trysmudford.com/perfomance-wins-with-hugo-and-netlify/)_
diff --git a/docs/content/en/showcase/letsencrypt/bio.md b/docs/content/en/showcase/letsencrypt/bio.md
new file mode 100644
index 000000000..24d7b96ee
--- /dev/null
+++ b/docs/content/en/showcase/letsencrypt/bio.md
@@ -0,0 +1,3 @@
+
+
+Let's Encrypt is a free, automated, and open certificate authority (CA), run for the public's benefit. It is a service provided by the [Internet Security Research Group (ISRG)](https://letsencrypt.org/isrg/).
diff --git a/docs/content/en/showcase/letsencrypt/featured.png b/docs/content/en/showcase/letsencrypt/featured.png
new file mode 100644
index 000000000..9535d91bd
--- /dev/null
+++ b/docs/content/en/showcase/letsencrypt/featured.png
diff --git a/docs/content/en/showcase/letsencrypt/index.md b/docs/content/en/showcase/letsencrypt/index.md
new file mode 100644
index 000000000..8487a3c77
--- /dev/null
+++ b/docs/content/en/showcase/letsencrypt/index.md
@@ -0,0 +1,21 @@
+---
+title: "Let’s Encrypt"
+date: 2018-03-13
+description: "Showcase: Lessons learned from taking letsencrypt.org to Hugo."
+siteURL: https://letsencrypt.org/
+siteSource: https://github.com/letsencrypt/website
+byline: "[bep](https://github.com/bep), Hugo Lead"
+---
+
+The **Let’s Encrypt website** has a common set of elements: A landing page and some other static info-pages, a document section, a blog, and a documentation section. Having it moved to Hugo was mostly motivated by a _simpler administration and Hugo's [multilingual support](/content-management/multilingual/)_. They already serve HTTPS to more than 60 million domains, and having the documentation available in more languages will increase that reach.[^1]
+
+{{< tweet 971755920639307777 >}}
+
+I helped them port the site from Jekyll to Hugo. There are usually very few surprises doing this. I know Hugo very well, but working on sites with a history usually comes up with something new.
+
+That site is bookmarked in many browsers, so preserving the URLs was a must. Hugo's URL handling is very flexible, but there was one challenge. The website has a mix of standard and what we in Hugo call _ugly URLs_ (`https://letsencrypt.org/2017/12/07/looking-forward-to-2018.html`). In Hugo this is handled automatically, and you can turn it on globally or per language. But before Hugo `0.33` you could not configure it for parts of your site. You could set it manually for the relevant pages in front matter -- which is how it was done in Jekyll -- but that would be hard to manage, especially when you start to introduce translations. So, in [Hugo 0.33](https://gohugo.io/news/0.33-relnotes/) I added support for _ugly URLs_ per section and also `url` set in front matter for list pages (`https://letsencrypt.org/blog/`).
+
+The lessons learned from this also lead to [disableLanguages](/content-management/multilingual/#disable-a-language) in Hugo `0.34` (a way to turn off languages during translation). And I also registered [this issue](https://github.com/gohugoio/hugo/issues/4463). Once fixed it will make it easier to handle partially translated sites.
+
+
+[^1]: The work on getting the content translated is in progress.
diff --git a/docs/content/en/showcase/linode/bio.md b/docs/content/en/showcase/linode/bio.md
new file mode 100644
index 000000000..42fa92229
--- /dev/null
+++ b/docs/content/en/showcase/linode/bio.md
@@ -0,0 +1,4 @@
+
+**Linode** is a cloud hosting provider that offers high performance SSD Linux servers for your infrastructure needs.
+
+**Hugo** offers the documentation team incredible performance as we scale and continue providing quality Linux tutorials.
diff --git a/docs/content/en/showcase/linode/featured.png b/docs/content/en/showcase/linode/featured.png
new file mode 100644
index 000000000..5d4c3e36b
--- /dev/null
+++ b/docs/content/en/showcase/linode/featured.png
diff --git a/docs/content/en/showcase/linode/index.md b/docs/content/en/showcase/linode/index.md
new file mode 100644
index 000000000..b0590a8cf
--- /dev/null
+++ b/docs/content/en/showcase/linode/index.md
@@ -0,0 +1,21 @@
+---
+
+title: Linode Docs
+
+date: 2018-02-12
+
+description: "Showcase: \"Hugo allows us to build thousands of pages in seconds.\""
+
+siteURL: https://linode.com/docs/
+
+siteSource: https://github.com/linode/docs
+
+---
+
+The documentation team at Linode has been writing guides since 2009, with the goal of helping new and experienced Linux users find the best tools and get the most out of their systems.
+
+As our library grew into thousands of guides, we needed a fast static site generator with intuitive templating and the flexibility to extend Markdown without constantly writing HTML and CSS.
+
+Hugo solved a lot of our growing pains with features like shortcodes, customizable URLs, LiveReload, and more. We have already brought our site build time down from minutes to just a few seconds, and we are excited to see what future developments in Hugo will bring.
+
+Thank you to all the [Hugo contributors](https://github.com/gohugoio/hugo/graphs/contributors) and  especially [@bep](https://github.com/bep) for helping us with the adoption of Hugo.
diff --git a/docs/content/en/