Merge commit '9b0050e9aabe4be65c78ccf292a348f309d50ccd' as 'docs'

```
git subtree add --prefix=docs/ https://github.com/gohugoio/hugoDocs.git master --squash
```

Closes #11925

docs/content/en/showcase/1password-support/bio.md

@@ -0,0 +1,4 @@
+
+**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.

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.

docs/content/en/showcase/alora-labs/bio.md

@@ -0,0 +1,3 @@
+**Alora Labs** is a product development consultancy headquartered in Toronto, Canada.
+
+We help companies build software and IoT products and were recently recognized as one of the [**top IoT development firms**](https://aloralabs.com/insights/alora-labs-receives-clutch-2021-top-iot-agency-award) in Toronto.

docs/content/en/showcase/alora-labs/index.md

@@ -0,0 +1,18 @@
+---
+title: Alora Labs
+date: 2021-05-27
+description: "Showcase: \"Making performant websites accessible for everyone.\""
+siteURL: https://aloralabs.com/
+siteSource: https://github.com/aloralabs/homepage
+aliases: [/showcase/aloralabs/]
+---
+
+At Alora Labs we always have an eye open for new tools and technology that we can utilize to the benefit of our customers or internal projects like our website.
+
+The previous iteration of our site was built with Jekyll, which served us well at first. However as time went on, we became frustrated with the number of dependencies we had to rely on, that would often break at the most inconvenient times.
+
+Hugo was a breath of fresh air in this regard, a single binary that works equally well on Windows as it did on macOS or Linux. We no longer need additional tools for image optimization, Sass compilation or JavaScript bundling. Everything just works, and with a substantial performance boost too.
+
+Hugo has become a favorite tool in the tool belt and the foundation for many client projects. We couldn't be happier with the switch and we are optimistic about recommending Hugo for many years to come.
+
+Thank you to the vibrant community and talented development team for all the hard work in making Hugo a success. As excellent as Hugo is now, we cannot wait to see what the release notes have in store for us next.

docs/content/en/showcase/ampio-help/bio.md

@@ -0,0 +1,11 @@
+
+__We are Ampio.__ We design and manufacture a building automation system that provides control, comfort, safety and reliability. Visit [our page](http://ampio.com/) to learn more about our solution!
+
+__Ampio Knowledge Base__ is a service built and maintained with Hugo. It is a self-service support platform for our customers and certified installers. It also contains a complete portfolio of our modules---building blocks of the Ampio building automation system.
+
+The site is built by:
+
+* [@mgetka](https://github.com/mgetka), developer
+* [@SteynAnna](https://github.com/SteynAnna), maintainer
+
+and other members of the Ampio team responsible for content creation.

docs/content/en/showcase/ampio-help/index.md

@@ -0,0 +1,77 @@
+---
+title: Ampio Knowledge Base
+date: 2022-10-30
+
+description: "Knowledge base for the Ampio building automation system."
+siteURL: https://help.ampio.com/
+---
+
+As a company that specializes in highly customizable smart solutions for various industries, Ampio has accumulated a vast amount of knowledge throughout the years. We were on the lookout for a user-friendly platform to impart this knowledge to our clients and installers. Delivering a service that caters to both audiences, scattered around the globe with vastly divergent needs and expectations, was a challenge.
+
+On the one hand, we needed something that would let us educate a client with no technical knowledge about our system in a visually appealing way.
+
+On the other hand, our installers required technical drawings, offline manuals, and a deep dive into highly specialized subjects.
+
+Over and above that, we could not overlook the fact that our internal team of editors and maintainers of the Knowledge Base included non-programmers who had to be able to create content and navigate the architecture of the site just as well as those adept at coding.
+
+We started our journey with the following requirements:
+
+ - Ease of contribution
+ - Efficient search capabilities
+ - The possibility of deployment to simple shared hosting
+ - Proper support for multilingualism
+
+## Dark ages of WordPress
+
+With the above-mentioned in mind, we built our first revision of the service in WordPress with a commercial knowledge base plugin. The initial requirements seemed not to be exorbitant, and yet we were surprised to see that only a few of the available solutions covered them. Especially, the case of multilingualism appeared to be particularly neglected across the available products.
+
+The WordPress-based products made big promises: pay some bucks, bootstrap the service in minutes, and forget about all the development troubles. And although those promises could possibly be deliverable on WordPress' end, it was definitely not true for anything more than the most generic deployments. In our case, we were dealing with more and more trade-offs. Plus, the solution was just slow on the simple shared hosting environment that we dedicated to the job.
+
+## Turning point
+
+The turning point was the introduction of a new key requirement---each document was to be downloadable in the PDF format. Such functionality was not available in the plugins we owned, nor did it look like any of the other existing WordPress plugins could fulfill our needs to a satisfactory degree. Nobody in our team was brave enough to add such a functionality to the current stack, so we decided to start from scratch.
+
+On top of that new development, we had to remember another one of our key requirements, namely, that mostly non-programmers were to be responsible for the service maintenance and content creation. Initially, we were leaning towards headless CMS-based solutions, but finally we made a bold move and decided to create a Git-managed Jamstack service and see what happens.
+
+## Hugo to the rescue
+
+Hugo was our first choice of SSG. The multilingualism support was the primary feature that convinced us. Later on, going through the documentation, we continued to discover new exciting features that we didn't even know we needed when we started.
+
+The rich functionalities of WordPress WYSIWYG editors soon turned out to be a curse. It became burdensome to maintain formatting consistency across documents prepared by multiple contributors. When we considered Markdown, we knew that it would give us a lot less flexibility. In our case, it proved to be a blessing in disguise---the constraints imposed by the notation ensured that each document was prepared in the same way. And in the cases where Markdown was not enough, Hugo shortcodes gave us all that we needed to get the results we anticipated.
+
+In terms of PDF generation, we utilized [custom output formats](/templates/output-formats/) to produce intermediary document representations, which are consumed by our custom tool transforming them to TeX documents, which are finally used to produce PDF files.
+
+Custom output formats were also used to create search indexes. The search functionality is built on the brilliant [TNTSearch](https://github.com/teamtnt/tntsearch) library. The search queries and results are handled by PHP snippets embedded into static documents handled by Hugo.
+
+We even implemented a simple REST API generated by Hugo! We have yet to find something that cannot be achieved with this stack, while in WordPress-based solutions we were struggling with things as simple as defining custom document ordering in one of the categories list views.
+
+When talking about Hugo, we cannot forget about the speed. At the beginning we were not considering it a killer feature, but as our document base grew bigger, we appreciated it more and more. Dry-runs are not so common---most of the time we are working on one of the documents with cache already built during one of the previous Hugo runs. In such a scenario, Hugo rebuilds the site in about a second and we consider it a very good result.
+
+```text
+                   | EN  | PL
+-------------------+-----+------
+  Pages            | 483 | 486
+  Paginator pages  |  56 |  55
+  Non-page files   | 745 | 749
+  Static files     | 917 | 917
+  Processed images | 487 | 490
+  Aliases          |  80 |  79
+  Sitemaps         |   2 |   1
+  Cleaned          |   0 |   0
+
+Total in 1096 ms
+```
+
+## Adaptation among the contributors
+
+Very quickly it became apparent that our initial concerns about the adaptation of the workflow among contributors were grossly exaggerated. Markdown is fairly straightforward and did not cause any trouble for the contributors.
+
+We recommended that our colleagues use Visual Studio Code as a tool for content creation. The project’s repository tracks project-scoped configuration of the editor, which includes a set of _tasks_ allowing to run a live server from the GUI level. This is very useful for those who are easily frightened when faced with the mighty terminal.
+
+The basic skills of the Git workflow were also easily acquired. At the end of the day, builds and deployments are fully managed by CI/CD processes, so the administration of the service drills down to reviewing and accepting merge requests in the Git frontend. As a side effect, we receive a full and clear history of contributions, which is well appreciated by our quality assurance auditors.
+
+We could even say that our experiment spread the love for Git among non-programmers in our organization!
+
+## Summary
+
+Hugo is the best! Definitely give it a try if you are ever faced with a challenge similar to ours. And do not give it a second thought if your service contributors are not too technically inclined---it might still turn out great!

docs/content/en/showcase/bypasscensorship/bio.md

@@ -0,0 +1,6 @@
+Bypass Censorship find and promote tools that provide Internet access to everyone.
+
+The site is built by:
+
+* [Leyla Avsar](https://www.leylaavsar.com/) (designer)
+* [Fredrik Jonsson](https://xdeb.net/) (dev)

docs/content/en/showcase/bypasscensorship/index.md

@@ -0,0 +1,24 @@
+---
+title: Bypass Censorship
+date: 2019-06-16
+description: "Showcase: Bypass Censorship find and promote tools that provide Internet access to everyone."
+siteURL: https://www.bypasscensorship.org/
+byline: "[Fredrik Jonsson](https://xdeb.net/), Web developer & Linux sysadmin"
+
+---
+
+The British Broadcasting Corporation (BBC) (UK), Deutsche Welle (DW) (Germany), France Médias Monde (FMM) (France), the U.S. Agency for Global Media (USAGM) (US) and the Open Technology Fund (OTF) (US) co-sponsor the Bypass Censorship website.
+
+Websites of international news agencies are often blocked in many countries. In order to connect people to these sites, Bypass Censorship feature and recommend tools in the following languages: English, French, Spanish, Arabic, Farsi, Chinese, and Russian.
+
+One of the tools is the Bypass Censorship Extension for Firefox and Chrome. The extension help direct people to mirrors of partners sites if they are being censored.
+
+The first version of the site was built in Drupal 8 but it was relaunched as a static site built with Hugo in 2019.
+
+Security, page load time and easy of hosting is the main reasons for switching to a static site. As the lead developer I had good experience with Hugo and was interested in exploring the multilingual features.
+
+It's a simply site, basically one page in seven languages. I had no problems getting Hugo to output what I wanted. Found the multilingual support straight forward and easy to work with.
+
+Thanks to the design by [Leyla Avsar](https://www.leylaavsar.com/) the site also looks good. I used the [Hugo Zen theme](https://github.com/frjo/hugo-theme-zen) with a few custom templates and the needed CSS.
+
+The editors can maintain content via [Forestry.io CMS](https://forestry.io/) or directly via Git. Forestry does unfortunately not have multilingual support. All the language versions are in one pile making it harder to find the right file to edit, but it works.

docs/content/en/showcase/digitalgov/bio.md

@@ -0,0 +1,2 @@
+
+**Digital.gov** helps people in the U.S. government deliver better, more accessible digital services through publishing essential guidance, resources, tools, and online events that make it easier for people to design, build, and deliver essential services for the public.

docs/content/en/showcase/digitalgov/index.md

@@ -0,0 +1,64 @@
+---
+title: Digital.gov
+date: 2020-05-01
+description: "Showcase: \"Guidance on building better digital services in government.\""
+siteURL: https://digital.gov/
+siteSource: https://github.com/gsa/digitalgov.gov
+---
+
+For over a decade, Digital.gov has provided guidance, training, and community support to the people who are responsible for delivering digital services in the U.S. government. Essentially, it is a place where people can find examples of problems being solved in government, and get links to the tools and resources they need.
+
+Through collaboration in our communities of practice, Digital.gov is a window into the people who work in technology in government and the challenges they face making digital services stronger and more effective. [Read more about our site »](https://digital.gov/2019/12/19/a-new-digitalgov/)
+
+Digital.gov is built using the [U.S. Web Design System](https://designsystem.digital.gov/) (USWDS) and have followed the [design principles](https://designsystem.digital.gov/maturity-model/) in building out our new site:
+
+- **Start with real user needs**  — We used human-centered design methods to inform our product decisions (like qualitative user research), and gathered feedback from real users. We also continually test our assumptions with small experiments.
+- **Earn trust**  —We recognize that trust has to be earned every time. We are including all  [required links and content](https://digital.gov/resources/required-web-content-and-links/)  on our site, clearly identifying as a government site, building with modern best practices, and using HTTPS.
+- **Embrace accessibility**  —  [Accessibility](https://digital.gov/resources/intro-accessibility/)  affects everybody, and we built it into every decision. We’re continually working to conform to Section 508 requirements, use user experience best practices, and support a wide range of devices.
+- **Promote continuity**  — We started from shared solutions like USWDS and  [Federalist](https://federalist.18f.gov/). We designed our site to clearly identify as a government site by including USWDS’s .gov banner, common colors and patterns, and built with modern best practices.
+- **Listen**  — We actively collect user feedback and web metrics. We use the  [Digital Analytics Program](https://digital.gov/services/dap/)  (DAP) and analyze the data to discover actionable insights. We make small, incremental changes to continuously improve our website by listening to readers and learning from what we hear.
+
+_More on the [USWDS maturity model »](https://designsystem.digital.gov/maturity-model/)_
+
+## Open tools
+
+We didn’t start from scratch. We built and designed the Digital.gov using many of the open-source tools and services that we develop for government here in the  [Technology Transformation Services](https://www.gsa.gov/tts/) (TTS).
+
+Using services that make it possible to design, build, and iterate quickly are essential to modern web design and development, which is why [Federalist](https://federalist.18f.gov/) and the [U.S. Web Design System](https://designsystem.digital.gov/) are such a great combination.
+
+**Why Hugo?** Well, with around `~3,000` files _(and growing)_ and `~9,000` built pages, we needed a site generator that could handle that volume with lightning fast speed.
+
+Hugo was the clear option. The [Federalist](https://federalist.18f.gov/) team quickly added it to their available site generators, and we were off.
+
+At the moment, it takes around `32 seconds` to build close to `~10,000` pages!
+
+Take a look:
+
+```text
+
+                   |  EN
+-------------------+-------
+  Pages            | 7973
+  Paginator pages  |  600
+  Non-page files   |  108
+  Static files     |  851
+  Processed images |    0
+  Aliases          | 1381
+  Sitemaps         |    1
+  Cleaned          |    0
+
+Built in 32.427 seconds
+```
+
+In addition to Hugo, we are proudly using a number of other tools and services, all built by government are free to use:
+
+- [Federalist](https://federalist.18f.gov/)
+- [Search.gov](https://www.search.gov/)  — A free, hosted search platform for federal websites.
+- [Cloud.gov](https://www.cloud.gov/)  — helps teams build, run, and authorize cloud-ready or legacy government systems quickly and cheaply.
+- [Federal CrowdSource Mobile Testing Program](https://digital.gov/services/service_mobile-testing-program/)  — Free mobile compatibility testing by feds, for feds.
+- [Digital Analytics Program](https://digital.gov/services/dap/)  (DAP) — A free analytics tool for measuring digital services in the federal government
+- [Section508.gov](https://www.section508.gov/)  and  [PlainLanguage.gov](https://www.plainlanguage.gov/)  resources
+- [API.data.gov](https://api.data.gov/)  — a free API management service for federal agencies
+- [U.S. Digital Registry](https://digital.gov/services/u-s-digital-registry/)  — A resource for confirming the official status of government social media accounts, mobile apps, and mobile websites.
+
+**Questions or feedback?** [Submit an issue](https://github.com/GSA/digitalgov.gov/issues) or send us an email to [digitalgov@gsa.gov](mailto:digitalgov@gsa.gov) :heart:

docs/content/en/showcase/fireship/bio.md

@@ -0,0 +1,6 @@
+
+**Fireship.io** is an ecosystem of detailed and practical resources for developers who want to build and ship high-quality apps.
+
+The site is built by:
+
+* [Jeff Delaney](https://fireship.io/contributors/jeff-delaney/)

docs/content/en/showcase/fireship/index.md

@@ -0,0 +1,17 @@
+---
+title: fireship.io
+date: 2019-02-02
+description: "Showcase: \"Hugo helps us create complex technical content that integrates engaging web components\""
+siteURL: https://fireship.io
+siteSource: https://github.com/fireship-io/fireship.io
+byline: "[Jeff Delaney](https://github.com/codediodeio), Fireship.io Creator"
+---
+
+After careful consideration of JavaScript/JSX-based static site generators, it became clear that Hugo was the only tool capable of handling our project's complex demands. Not only do we have multiple content formats and taxonomies, but we often need to customize the experience at a more granular level. The problems Hugo has solved for us include:
+
+- **Render speed.** We know from past experience that JavaScript-based static site generators become very slow when you have thousands of pages and images.
+- **Feature-rich.** Our site has a long list of specialized needs and Hugo somehow manages to cover every single use case.
+- **Composability.** Hugo's partial and shortcode systems empower us to write DRY and maintainable templates.
+- **Simplicity.** Hugo is easy to learn (even without Go experience) and doesn't burden us with brittle dependencies.
+
+The site is able to achieve Lighthouse performance scores of 95+, despite the fact that it is a fully interactive PWA that ships Angular and Firebase in the JS bundle. This is made possible by (1) prerendering content with Hugo and (2) lazily embedding native web components directly in the HTML and Markdown. We provide a [detailed explanation](https://youtu.be/gun8OiGtlNc) of the architecture on YouTube and can't imagine development without Hugo.

docs/content/en/showcase/forestry/bio.md

@@ -0,0 +1,4 @@
+
+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.

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:
+
+```text
+                   | 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](/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.

docs/content/en/showcase/godot-tutorials/bio.md

@@ -0,0 +1,7 @@
+[Godot Tutorials](https://godottutorials.com) aims to teach beginners how to get up and running with basic game programming and game development skills.
+
+The website is built with the **Hugo Framework** alongside aws+cloudfront+lambda.
+
+The site is built by:
+
+- [Godot Tutorials](https://godottutorials.com)

docs/content/en/showcase/godot-tutorials/index.md

@@ -0,0 +1,24 @@
+---
+
+title: Godot Tutorials
+date: 2021-01-07
+
+description: "Teaching game development skills with love."
+
+# The URL to the site on the internet.
+siteURL: https://godottutorials.com
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Godot Tutorials](https://godottutorials.com), Web Developer & Game Programmer"
+
+---
+
+[Godot Tutorials](https://godottutorials.com) started as a way to teach beginners game programming and game development.
+As I created videos, I ran into a problem; if I made a mistake with a YouTube video, it was difficult to correct errors.
+
+I discovered that blogging episodes and having articles that teach on top of my videos is a fantastic solution to my problem.
+
+As I researched blogging platforms, I came across two solutions; however, I chose [Hugo](https://gohugo.io) because it's built with Markdown in mind and simplified my workflow.
+
+In a sense, with [Hugo](https://gohugo.io) programmed the right way, I can focus **more time on planning, creating, and editing**
+my videos and **less time maintaining and fixing** my website.

docs/content/en/showcase/hapticmedia/bio.md

@@ -0,0 +1 @@
+**Hapticmedia** provides interactive 3D configurators for eCommerce.

docs/content/en/showcase/hapticmedia/index.md

@@ -0,0 +1,31 @@
+---
+title: Hapticmedia Blog
+date: 2019-10-01
+description: "Showcase: \"A simple, but powerful, multilingual blog.\""
+siteURL: https://hapticmedia.fr/blog/en/
+byline: "[Cyril Bonnet](https://github.com/monsieurnebo), Web Developer"
+---
+
+Our goal was to create a simple, effective and multilingual blog on [3D technology](https://hapticmedia.fr/blog/en/3d-technology/) that could be managed by a non-technical profile.
+
+## Why Hugo?
+
+Hugo addresses all these needs, coupled with [Forestry.io](https://forestry.io/) for its administration via a "turnkey" interface. We have attached particular importance to SEO, and therefore to the creation of an advanced taxonomy system. Thus, each author and tag has a dedicated page, listing the related posts.
+
+## What we liked
+
+- The **multilingual** content support, especially simple to setup.
+- The **multiple environments** support (develop, staging, test, production, ...).
+- Although a hard start with the Go language, the power of the **Hugo's templating**.
+- The **partial layouts**, including the `internals` (e.g. social meta tags).
+- The **build time**, unbeatable ⚡️⚡️⚡️.
+
+## Tools & workflow
+
+- We used the same design as **[our website](https://hapticmedia.fr/en/)**, recreated as a Hugo HTML template.
+- **[Hugo](https://gohugo.io)** for the static website generator.
+- **[CircleCI](https://circleci.com)** for continuous integration & deployment.
+- **[AWS](https://aws.amazon.com/)** for web hosting.
+- **[Forestry.io](https://forestry.io)** for the content management.
+
+**All of these tools allow our editor to manage the blog's content without having to worry about its technical aspect, which is managed by the developers.**

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](https://www.tomango.co.uk)

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 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 using dynamic systems 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/)_

docs/content/en/showcase/keycdn/bio.md

@@ -0,0 +1 @@
+[KeyCDN](https://www.keycdn.com) is a high performance content delivery network (CDN) offering many powerful features, including image processing that can transform and optimize images in real time. Our network offers global coverage to speed up content delivery and is capable of delivering entire static websites, like those built with Hugo, at the edge.

docs/content/en/showcase/keycdn/index.md

@@ -0,0 +1,30 @@
+---
+
+title: KeyCDN
+date: 2020-04-10
+description: "Showcase: \"Hugo has become an integral part of our stack.\""
+siteURL: https://www.keycdn.com
+
+---
+
+At KeyCDN one of our primary focuses is on performance. With speed being ingrained in our DNA we knew from the start that we must use a fast static website generator that could meet our requirements. When evaluating the right solution, Hugo met our requirements and we looked no further as it was the fastest and most flexible.
+
+## Why we chose Hugo
+
+Before our migration to Hugo our website was powered by a PHP-based website that had about 50 pages and a WordPress website that had over 500 posts between our blog and knowledge base. This became harder to maintain as time continued. We felt like we were losing the speed and flexibility that we require. To overcome this we knew we needed to convert our website to be static. This would allow our website to be faster and more secure as it could be delivered by all of our edge locations.
+
+It wasn’t an easy task at the beginning, however, after evaluating Hugo and benchmarking it we knew we had found the ideal solution. Hugo was by far the fastest setup and offered an intuitive way to build our entire website exactly as needed. The Go-based templates, shortcodes, and configuration options made it easy to build a complex website.
+
+In the fall of 2018 we started the migration and within a couple short months we had built a custom static website with Hugo and migrated all content from our old systems. The simplicity and vast amount of functionality that Hugo offers made this process fast and left our entire team, including all of our writers and developers, happy with the migration. Since migrating to Hugo we haven’t looked back. Hugo has become an integral part of our stack. We’re grateful to all those who have contributed to make Hugo what it is today.
+
+## Technical overview
+
+Below is an overview of what we used with Hugo to build our website:
+
+* [KeyCDN](https://www.keycdn.com) uses a custom theme and is our primary hub for all style sheets and JavaScript. Our other websites, like [KeyCDN Tools](https://tools.keycdn.com), only import the required style sheets and JavaScript.
+* We use [Gulp](https://gulpjs.com) in our build process for many tasks, such as combining, versioning, and compressing our style sheets as well as our JavaScript.
+* Our search is powered by a custom solution that we’ve built. It allows our pages, blog, and knowledge base to be searched. It uses [Axios](https://github.com/axios/axios) to send a `POST` request containing the search query. An index file in JSON generated by Hugo is searched and the results are then returned.
+* Our commenting system is also powered by a custom solution that we’ve built. It uses Axios to send a `GET` request containing the slug to pull the comment thread and a `POST` request containing the name, email address, and comment when submitting a comment.
+* Our contact form is a simple HTML form, which uses Axios as well.
+* Our writers use shortcodes to enhance the capability of markdown.
+* Our entire website is delivered through KeyCDN using a Pull Zone, which means all of our edge locations are delivering our website.

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://www.abetterinternet.org/).

docs/content/en/showcase/letsencrypt/index.md

@@ -0,0 +1,20 @@
+---
+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 user="letsencrypt" id="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 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.

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.

docs/content/en/showcase/linode/index.md

@@ -0,0 +1,15 @@
+---
+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.

docs/content/en/showcase/overmindstudios/bio.md

@@ -0,0 +1,7 @@
+
+**Overmind Studios** is a visual effects studio headquartered in Southern Germany.
+
+The site is built by:
+
+* [Tobias Kummer](https://www.overmind-studios.de/about/)
+

docs/content/en/showcase/overmindstudios/index.md

@@ -0,0 +1,13 @@
+---
+title: Overmind Studios
+description: "A fresh start to make things easier in the future."
+siteURL: https://www.overmind-studios.de/
+byline: "[tobkum](https://github.com/tobkum), Co-Founder Overmind Studios"
+---
+After many years of running our site on WordPress, we decided to switch to Hugo.
+
+WordPress is a great CMS for many people, but it has some downsides, especially for those who need a fast, secure, and customizable site. Plugins can become outdated, customization can be difficult, and bloat can slow down page loading times.
+
+Hugo is a static site generator that addresses many of these problems. It is fast to build and iterate, does not require PHP, is highly customizable, and is easy to learn and use. It is also secure, as it does not have a backend or MySQL database that can be hacked.
+
+We are very happy with our switch to Hugo. It is easy to update our site with new projects, and our Lighthouse score and loading times are both excellent. We now have more time to be creative instead of troubleshooting WordPress quirks and updates.

docs/content/en/showcase/pharmaseal/bio.md

@@ -0,0 +1,7 @@
+PHARMASEAL began in 2016 with the purpose of disrupting the Clinical Trials Management market through continuous validation and integration
+
+We've been using **Hugo + Webpack + Netlify** to provide a scalable, modular design for the website, complete with Forestry building blocks to quickly be able to generate engagement pages.
+
+The site is built by:
+
+- [Roboto Studio](https://roboto.studio)

docs/content/en/showcase/pharmaseal/index.md

@@ -0,0 +1,35 @@
+---
+
+title: PHARMASEAL
+date: 2019-04-29
+
+description: "Pharmaseal website developed using Hugo, Forestry, hosted and deployed by Netlify."
+
+# The URL to the site on the internet.
+siteURL: https://pharmaseal.co/
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Roboto Studio](https://roboto.studio), Jonathan Alford"
+
+---
+
+We wanted to shake the status quo with PHARMASEAL, opting for a fast and scalable website built with Hugo instead of slower monolithic systems the competitors were using.
+
+We had two goals:
+
+**Make it fast**
+
+We wanted to optimize the site as much as possible, so we opted for using Cloudinary, enabling us to take advantage of on-the-fly image manipulation, and thanks to the sheer speed of static sites, we achieved a perfect optimization score with Google audits.
+
+Because we're hosting the site through Netlify and our target audience is in America, we are taking advantage of Netlify edge (Their alternative to a CDN). We're talking blazing fast.
+
+**Make it easy**
+
+We're big fans of simplicity, and that's what we delivered with the Forestry building blocks. Every element on the site is built with building blocks in mind, allowing PHARMASEAL to generate multiple pages in the blink of an eye.
+
+PHARMASEAL have found Forestry CMS combined with HUGO to be so effective at producing fast, purpose driven pages, that we have worked with them to add even more blocks in a scalable, modular fashion.
+
+**TLDR:** We're blown away with HUGO, the sheer speed, scalability and deployment possibilities with Netlify is the 💣

docs/content/en/showcase/quiply-employee-communications-app/bio.md

@@ -0,0 +1,4 @@
+**Quiply** is an employee communications app enabling mobile collaboration across an entire organization.
+Our customers get their own branded app enabling them to communicate fast and effectively with all employees, also non-desk and shift workers.
+
+As the Quiply app's build process is based on **Gulp**, we have started to build our company and product website using **Gulp + Hugo** which is super-fast and gives us exactly the flexibility we need.

docs/content/en/showcase/quiply-employee-communications-app/index.md

@@ -0,0 +1,29 @@
+---
+
+# A suitable title for this article.
+title: Quiply Employee Communications App
+
+# Set this to the current date.
+date: 2018-02-13
+
+description: "\"It became immediately clear that we'd use Hugo going forward as it compiles super-fast, is intuitive to use and offers all the features we need.\""
+
+# The URL to the site on the internet.
+siteURL: https://www.quiply.com
+
+# Link to the site's Hugo source code if public and you can/want to share.
+# Remove or leave blank if not needed/wanted.
+# siteSource: https://github.com/gohugoio/hugoDocs
+
+# Add credit to the article author. Leave blank or remove if not needed/wanted.
+byline: "[Sebastian Schirmer](mailto:sebastian.schirmer@quiply.com), Quiply Co-Founder"
+
+---
+
+With the launch of our Employee Communications app Quiply we created a very simple and static one-page website to showcase our product.
+
+As our customer base and demand for marketing and communication started to grow, we needed a solution to easily grow and extend the contents of our web presence. As we do not have the need to serve dynamic content, we decided to use a static site generator. Amongst a couple of others, we tried Hugo and it became immediately clear that we'd use Hugo going forward as it compiles super-fast, is intuitive to use and offers all the features we need.
+
+Our website which we launched a couple of weeks ago is still growing and new content is being added constantly. By using Hugo, this can be easily done by content authors writing markdown files without always having to touch HTML or CSS code. It is available in German only for the time being, an English version is in the works.
+
+Huge thanks to everyone involved in making Hugo a success.

docs/content/en/showcase/template/bio.md

@@ -0,0 +1,7 @@
+
+Add some **general info** about the site here.
+
+The site is built by:
+
+* [Person 1](https://example.org)
+* [Person 1](https://example.org)

docs/content/en/showcase/template/index.md

@@ -0,0 +1,18 @@
+---
+title: Hugo Showcase Template
+date: 2018-02-07
+description: "A short description of this page."
+siteURL: https://gohugo.io/
+siteSource: https://github.com/gohugoio/hugoDocs
+byline: "[bep](https://github.com/bep), Hugo Lead"
+---
+Have a **notable Hugo site[^1]**? We would love to feature it in this **Showcase Section**
+
+Please:
+
+1. Fork https://github.com/gohugoio/hugoDocs.
+2. Run `hugo new content showcase/your-site`. This will use the archetype bundle in the [docs repo](https://github.com/gohugoio/hugoDocs/tree/master/archetypes).
+3. Follow the instructions in the newly created page bundle.
+4. Create a new pull request in https://github.com/gohugoio/hugoDocs/pulls.
+
+[^1]: We want this to show Hugo in its best light, so this is not for the average Hugo blog. In most cases the answer to "Is my site [notable](https://www.dictionary.com/browse/notable)?" will be obvious, but if in doubt, create an [issue](https://github.com/gohugoio/hugoDocs/issues) with a link and some words, and we can discuss it. But if you have a site with an interesting Hugo story or a company site where the company itself is notable, you are most welcome.

docs/content/en/showcase/tomango/bio.md

@@ -0,0 +1,6 @@
+
+We help ambitious businesses grow by getting more of the customers they want.
+
+Our new site runs quickly, anywhere in the world, regardless of internet connectivity.
+
+The site was built by [Tomango](https://www.tomango.co.uk)

docs/content/en/showcase/tomango/index.md

@@ -0,0 +1,29 @@
+---
+
+title: Tomango
+
+date: 2018-05-04
+
+description: "Showcase: \"Tomango site relaunch: Building our JAMstack site\""
+
+siteURL: https://www.tomango.co.uk
+
+siteSource: https://github.com/trys/tomango-2018
+
+byline: "[Trys Mudford](https://www.trysmudford.com), Lead Developer, Tomango"
+
+---
+
+Hugo is our static site generator (SSG) of choice. It's **really quick**. After using it on a number of [client projects](/showcase/hartwell-insurance/), it became clear that our new site _had_ to be built with Hugo.
+
+The big benefit of an SSG is how it moves all the heavy lifting to the build time.
+
+For example in WordPress, all the category pages are created at runtime, generating a lot of database queries. In Hugo, the paginated category pages are created at build time - so all the computational complexity is done once, and doesn't impact the user at all.
+
+Similarly, instead of running a live, or even a heavily cached Instagram feed that checked for new photos on page load, we used IFTTT to flip the feature to work performantly. I've [written about it](https://www.trysmudford.com/blog/making-the-static-dynamic-instagram-importer/) in detail on my blog but in essence: IFTTT sends a webhook to a Netlify Cloud Function every time a photo is uploaded. The function scrapes the photo and commits it to our GitHub repo which triggers a Hugo build on Netlify, deploying the site immediately!
+
+Shortcodes allow copy editors to continue using WordPress-esque features, Markdown keeps our developers happy, and our users don't have any of the database overheads. It's win-win!
+
+---
+
+This is an extract from our [technical launch post](https://www.tomango.co.uk/thinks/tomango-progressive-web-app/).