From f0179670ed6460204c4dd0dc08715f475fd16367 Mon Sep 17 00:00:00 2001 From: Zachary Betz Date: Tue, 12 Feb 2019 16:25:13 -0600 Subject: [PATCH] Change example site. Make layouts blog friendly --- exampleSite/config.toml | 21 +- exampleSite/content/_index.md | 14 +- exampleSite/content/about.md | 16 + exampleSite/content/patterns/coding/_index.md | 3 - .../content/patterns/coding/code-blocks.md | 116 -- .../content/patterns/coding/color-palettes.md | 17 - .../content/patterns/coding/command-line.md | 23 - .../content/patterns/coding/demo-embedding.md | 53 - .../content/patterns/coding/file-trees.md | 53 - exampleSite/content/patterns/coding/tested.md | 29 - .../patterns/coding/writing-inline-demos.md | 108 -- exampleSite/content/patterns/installation.md | 54 - exampleSite/content/patterns/media/_index.md | 4 - .../patterns/media/including-images.md | 50 - .../patterns/media/including-videos.md | 9 - exampleSite/content/patterns/printing.md | 14 - exampleSite/content/patterns/serving.md | 34 - exampleSite/content/patterns/setup.md | 73 -- exampleSite/content/patterns/updating.md | 38 - .../content/patterns/writing/_index.md | 4 - .../patterns/writing/expandable-sections.md | 48 - .../patterns/writing/markdown-and-metadata.md | 52 - .../patterns/writing/notes-and-warnings.md | 37 - .../patterns/writing/project-structure.md | 52 - .../content/patterns/writing/references.md | 63 - .../content/patterns/writing/snippets.md | 19 - .../patterns/writing/tables-of-contents.md | 34 - exampleSite/content/post/_index.md | 3 + .../content/post/creating-a-new-theme.md | 1143 +++++++++++++++++ exampleSite/content/post/goisforlovers.md | 332 +++++ exampleSite/content/post/hugoisforlovers.md | 78 ++ .../content/post/migrate-from-jekyll.md | 159 +++ .../content/post/nasa-images/earth.jpg | Bin 0 -> 518573 bytes exampleSite/content/post/nasa-images/index.md | 25 + exampleSite/content/post/nasa-images/moon.jpg | Bin 0 -> 381038 bytes exampleSite/content/post/nasa-images/sun.jpg | Bin 0 -> 3118921 bytes .../content/post/quotes-by-carl-jung.md | 49 + ...351ea21ee7_518573_500x0_resize_q90_box.jpg | Bin 0 -> 70288 bytes ...51ea21ee7_518573_700x0_resize_q100_box.jpg | 0 ...351ea21ee7_518573_700x0_resize_q90_box.jpg | Bin 0 -> 132017 bytes ...351ea21ee7_518573_700x0_resize_q99_box.jpg | Bin 0 -> 293021 bytes ...351ea21ee7_381038_500x0_resize_q90_box.jpg | Bin 0 -> 54653 bytes ...51ea21ee7_381038_700x0_resize_q100_box.jpg | Bin 0 -> 273363 bytes ...351ea21ee7_381038_700x0_resize_q90_box.jpg | Bin 0 -> 103471 bytes ...351ea21ee7_381038_700x0_resize_q99_box.jpg | Bin 0 -> 246685 bytes ...3778c1446_3118921_500x0_resize_q90_box.jpg | Bin 0 -> 99424 bytes ...778c1446_3118921_700x0_resize_q100_box.jpg | Bin 0 -> 500184 bytes ...3778c1446_3118921_700x0_resize_q90_box.jpg | Bin 0 -> 189530 bytes ...3778c1446_3118921_700x0_resize_q99_box.jpg | Bin 0 -> 447793 bytes layouts/_default/baseof.html | 8 +- layouts/_default/terms.html | 26 + layouts/post/li.html | 10 - layouts/post/single.html | 6 +- layouts/shortcodes/blockquote.html | 10 + layouts/shortcodes/figure.html | 26 +- layouts/taxonomy/tag.html | 18 - static/css/styles.css | 10 + 57 files changed, 1901 insertions(+), 1040 deletions(-) create mode 100644 exampleSite/content/about.md delete mode 100644 exampleSite/content/patterns/coding/_index.md delete mode 100644 exampleSite/content/patterns/coding/code-blocks.md delete mode 100644 exampleSite/content/patterns/coding/color-palettes.md delete mode 100644 exampleSite/content/patterns/coding/command-line.md delete mode 100644 exampleSite/content/patterns/coding/demo-embedding.md delete mode 100644 exampleSite/content/patterns/coding/file-trees.md delete mode 100644 exampleSite/content/patterns/coding/tested.md delete mode 100644 exampleSite/content/patterns/coding/writing-inline-demos.md delete mode 100644 exampleSite/content/patterns/installation.md delete mode 100644 exampleSite/content/patterns/media/_index.md delete mode 100644 exampleSite/content/patterns/media/including-images.md delete mode 100644 exampleSite/content/patterns/media/including-videos.md delete mode 100644 exampleSite/content/patterns/printing.md delete mode 100644 exampleSite/content/patterns/serving.md delete mode 100644 exampleSite/content/patterns/setup.md delete mode 100644 exampleSite/content/patterns/updating.md delete mode 100644 exampleSite/content/patterns/writing/_index.md delete mode 100644 exampleSite/content/patterns/writing/expandable-sections.md delete mode 100644 exampleSite/content/patterns/writing/markdown-and-metadata.md delete mode 100644 exampleSite/content/patterns/writing/notes-and-warnings.md delete mode 100644 exampleSite/content/patterns/writing/project-structure.md delete mode 100644 exampleSite/content/patterns/writing/references.md delete mode 100644 exampleSite/content/patterns/writing/snippets.md delete mode 100644 exampleSite/content/patterns/writing/tables-of-contents.md create mode 100644 exampleSite/content/post/_index.md create mode 100644 exampleSite/content/post/creating-a-new-theme.md create mode 100644 exampleSite/content/post/goisforlovers.md create mode 100644 exampleSite/content/post/hugoisforlovers.md create mode 100644 exampleSite/content/post/migrate-from-jekyll.md create mode 100644 exampleSite/content/post/nasa-images/earth.jpg create mode 100644 exampleSite/content/post/nasa-images/index.md create mode 100644 exampleSite/content/post/nasa-images/moon.jpg create mode 100644 exampleSite/content/post/nasa-images/sun.jpg create mode 100644 exampleSite/content/post/quotes-by-carl-jung.md create mode 100644 exampleSite/resources/_gen/images/nasa-images/earth_huaae7be4ba70df7325b57cd351ea21ee7_518573_500x0_resize_q90_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/earth_huaae7be4ba70df7325b57cd351ea21ee7_518573_700x0_resize_q100_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/earth_huaae7be4ba70df7325b57cd351ea21ee7_518573_700x0_resize_q90_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/earth_huaae7be4ba70df7325b57cd351ea21ee7_518573_700x0_resize_q99_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/moon_huaae7be4ba70df7325b57cd351ea21ee7_381038_500x0_resize_q90_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/moon_huaae7be4ba70df7325b57cd351ea21ee7_381038_700x0_resize_q100_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/moon_huaae7be4ba70df7325b57cd351ea21ee7_381038_700x0_resize_q90_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/moon_huaae7be4ba70df7325b57cd351ea21ee7_381038_700x0_resize_q99_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/sun_huc3d26fbb16c0f70400041133778c1446_3118921_500x0_resize_q90_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/sun_huc3d26fbb16c0f70400041133778c1446_3118921_700x0_resize_q100_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/sun_huc3d26fbb16c0f70400041133778c1446_3118921_700x0_resize_q90_box.jpg create mode 100644 exampleSite/resources/_gen/images/nasa-images/sun_huc3d26fbb16c0f70400041133778c1446_3118921_700x0_resize_q99_box.jpg create mode 100644 layouts/_default/terms.html delete mode 100644 layouts/post/li.html create mode 100644 layouts/shortcodes/blockquote.html delete mode 100644 layouts/taxonomy/tag.html diff --git a/exampleSite/config.toml b/exampleSite/config.toml index ef2d95e..7a052ff 100644 --- a/exampleSite/config.toml +++ b/exampleSite/config.toml @@ -6,8 +6,8 @@ googleAnalytics = "UA-123456789-1" # Uncomment below to enable syntax highlighting # For more styles see https://xyproto.github.io/splash/docs/all.html -# pygmentsCodefences = true -# pygmentsStyle = "algol" +pygmentsCodefences = true +pygmentsStyle = "algol" [taxonomies] tag = "tags" @@ -15,6 +15,16 @@ googleAnalytics = "UA-123456789-1" [permalinks] post = "/:filename/" +[imaging] + quality = 99 + +[params] + # description = "An accessibility-friendly Hugo theme, ported from the [original Cupper](https://github.com/ThePacielloGroup/cupper) project." + footer = "Made with [Hugo](https://gohugo.io/). Themed by [Cupper](https://github.com/zwbetz-gh/cupper-hugo-theme). Deployed to [Netlify](https://www.netlify.com/)." + # For more date formats see https://gohugo.io/functions/format/ + dateFormat = "Jan 2, 2006" + codePenUser = "TODO" + [menu] [[menu.nav]] name = "Home" @@ -36,10 +46,3 @@ googleAnalytics = "UA-123456789-1" name = "RSS" url = "/index.xml" weight = 5 - -[params] - # description = "An accessibility-friendly Hugo theme, ported from the [original Cupper](https://github.com/ThePacielloGroup/cupper) project." - footer = "Made with [Hugo](https://gohugo.io/). Themed by [Cupper](https://github.com/zwbetz-gh/cupper-hugo-theme). Deployed to [Netlify](https://www.netlify.com/)." - # For more date formats see https://gohugo.io/functions/format/ - dateFormat = "Jan 2, 2006" - codePenUser = "TODO" \ No newline at end of file diff --git a/exampleSite/content/_index.md b/exampleSite/content/_index.md index 242d37d..e8ab6b6 100644 --- a/exampleSite/content/_index.md +++ b/exampleSite/content/_index.md @@ -1,12 +1,14 @@ -+++ -date = "2017-06-26T18:27:58+01:00" -title = "Home" -+++ +--- +date: "2017-06-26T18:27:58+01:00" +title: "Home" +--- Welcome to **Cupper**: An accessibility-friendly Hugo theme, ported from the [original Cupper](https://github.com/ThePacielloGroup/cupper) project. Here are some of its features: {{% ticks %}} -* Responsive * Screen reader and keyboard accessible -* TODO +* Responsive +* Shortcodes for figures, notes, and warnings, just to name a few +* Toggleable dark theme +* Toggleable table of contents {{% /ticks %}} diff --git a/exampleSite/content/about.md b/exampleSite/content/about.md new file mode 100644 index 0000000..641354f --- /dev/null +++ b/exampleSite/content/about.md @@ -0,0 +1,16 @@ +--- +date: "2014-04-09" +title: "About" +--- + +Hugo is the **world’s fastest framework for building websites**. It is written in Go. + +It makes use of a variety of open source projects including: + +* https://github.com/russross/blackfriday +* https://github.com/alecthomas/chroma +* https://github.com/muesli/smartcrop +* https://github.com/spf13/cobra +* https://github.com/spf13/viper + +Learn more and contribute on [GitHub](https://github.com/gohugoio). diff --git a/exampleSite/content/patterns/coding/_index.md b/exampleSite/content/patterns/coding/_index.md deleted file mode 100644 index 1fac364..0000000 --- a/exampleSite/content/patterns/coding/_index.md +++ /dev/null @@ -1,3 +0,0 @@ -+++ -title = "Coding" -+++ diff --git a/exampleSite/content/patterns/coding/code-blocks.md b/exampleSite/content/patterns/coding/code-blocks.md deleted file mode 100644 index 5c51333..0000000 --- a/exampleSite/content/patterns/coding/code-blocks.md +++ /dev/null @@ -1,116 +0,0 @@ -+++ -title = "Code blocks" -weight = 1 -+++ - -Markdown already supports code samples both inline (using single backticks like \`some code here\`) and in blocks. **Cupper** will syntax highlight HTML, CSS, and JavaScript if you provide the correct language in the formulation of the block. - -So, this… - -{{}} -```html -<button aria-pressed="false">toggle me</button> -``` -{{}} - -… will result in this: - -```html - -``` - -Note that the syntax highlighting uses a greyscale theme. **Cupper** is careful not to use color as part of its own design, because these colors may clash with those of the design being illustrated and discussed. - -{{% note %}} -To preserve the wrapping inside code blocks, horizontal scrolling is implemented. To make sure scrolling is keyboard accessible, code blocks are focusable. An `aria-label` is provided to identify the code block to screen reader users. -{{% /note %}} - -## Annotated code - -**Cupper** offers the ability to highlight and annotate specific parts of your code examples using the `code` shortcode. Take an accessible dialog. You may wish to point out key attributes that make that dialog support assistive technologies: - -{{}} -
- -

Confirmation

-

Press Okay to confirm or Cancel

- - -
-{{}} - -You mark out the highlighted areas using triple square brackets like so: - -{{}} -{{<code>}} -<div [[[role="dialog"]]] [[[aria-labelledby="dialog-heading"]]]> - <button [[[aria-label="close"]]]>x</button> - <h2 [[[id="dialog-heading"]]]>Confirmation</h2> - <p>Press Okay to confirm or Cancel</p> - <button>Okay</button> - <button>Cancel</button> -</div> -{{</code>}} -{{}} - -Better still, if you include `numbered="true"`, each highlight is enumerated so you can reference it directly in the ensuing text. If you follow the shortcode directly with an ordered list, the styles match: - -{{}} -
- -

Confirmation

-

Press Okay to confirm or Cancel

- - -
-{{}} - -1. The dialog is only announced as a dialog if it takes the `dialog` ARIA role -2. The `aria-labelledby` relationship attribute makes the element carrying the `id` it points to its label -3. The close button uses `aria-label` to provide the text label "close", overriding the text content -4. The heading is used as the dialog's label. The `aria-labelledby` attribute points to its `id` - -You just include `numbered="true"` on the opening shortcode tag: - -{{}} -{{<code numbered="true">}} -<div [[[role="dialog"]]] [[[aria-labelledby="dialog-heading"]]]> - <button [[[aria-label="close"]]]>x</button> - <h2 [[[id="dialog-heading"]]]>Confirmation</h2> - <p>Press Okay to confirm or Cancel</p> - <button>Okay</button> - <button>Cancel</button> -</div> -{{</code>}} - -1. The dialog is only announced as a dialog if it takes the `dialog` ARIA role -2. The `aria-labelledby` relationship attribute makes the element carrying the `id` it points to its label -3. The close button uses `aria-label` to provide the text label "close", overriding the text content -4. The heading is used as the dialog's label. The `aria-labelledby` attribute points to its `id` -{{}} - -### JavaScript example - -{{}} -/* Enable scrolling by keyboard of code samples */ -(function () { - var codeBlocks = document.querySelectorAll('pre, .code-annotated'); - - Array.prototype.forEach.call(codeBlocks, function (block) { - if (block.querySelector('code')) { - block.setAttribute([[['role', 'region']]]); - block.setAttribute([[['aria-label', 'code sample']]]); - if (block.scrollWidth > block.clientWidth) { - block.setAttribute('tabindex', '0'); - } - } - }); -}()); -{{}} - -1. The `region` role announces the block as a region -2. The `aria-label` describes the kind of content to be expected in the region - -{{% note %}} -As you may have noticed, using specified highlights with the `code` shortcode sacrifices syntax highlighting. If you want syntax highlighting you must use the markdown triple back-tick syntax and annotation is not available. -{{% /note %}} diff --git a/exampleSite/content/patterns/coding/color-palettes.md b/exampleSite/content/patterns/coding/color-palettes.md deleted file mode 100644 index 3e3b9df..0000000 --- a/exampleSite/content/patterns/coding/color-palettes.md +++ /dev/null @@ -1,17 +0,0 @@ -+++ -title = "Color palettes" -+++ - -There's no reason why your **Cupper**-powered pattern library has to be all about functionality. You can include style guide-like information such as color palettes too. The `colors` shortcode makes it easy to exhibit colors and their values together. Just supply a comma-separated list of CSS color values. - -{{}} -{{% colors "#111111, #cccccc, #ffffff" %}} -{{}} - -The result is a one row strip showing each color supplied in order. The colors for **Cupper** are greyscale: - -{{% colors "#111111, #cccccc, #ffffff" %}} - -{{% note %}} -If you're wondering whether you need to put a space after the commas in the shortcode, don't worry: `"#254f7b, #579a6d, #666666"` and `"#254f7b,#579a6d,#666666"` are both accepted. Any CSS color value is acceptable, not just hex colors. -{{% /note %}} diff --git a/exampleSite/content/patterns/coding/command-line.md b/exampleSite/content/patterns/coding/command-line.md deleted file mode 100644 index 7a52e87..0000000 --- a/exampleSite/content/patterns/coding/command-line.md +++ /dev/null @@ -1,23 +0,0 @@ -+++ -title = "Command line" -+++ - -Your pattern documentation may need to include commands for installing packages or using CLIs. **Cupper** offers the `cmd` shortcode for making code blocks look like terminal commands. - -Here's how you write it: - -{{}} -{{<cmd>}} -npm run start -{{</cmd>}} -{{}} - -And here's how it looks: - -{{}} -npm run start -{{}} - -{{% warning %}} -The `cmd` shortcode currently only supports single commands. If you want to show multiple, successive commands use separate `cmd` blocks. -{{% /warning %}} diff --git a/exampleSite/content/patterns/coding/demo-embedding.md b/exampleSite/content/patterns/coding/demo-embedding.md deleted file mode 100644 index 85983ef..0000000 --- a/exampleSite/content/patterns/coding/demo-embedding.md +++ /dev/null @@ -1,53 +0,0 @@ -+++ -title = "Demo embedding" -weight = 2 -+++ - -Sometimes just pictures of the pattern you're documenting aren't enough. Interactive patterns benefit from live demos, so that readers can test their functionality. - -## CodePen - -**Cupper** offers a couple of ways to do this. The first is by embedding CodePen demos into the content. The `codePen` shortcode takes just one argument: the codePen's `ID`. - -{{}} -{{% codePen VpVNKW %}} -{{}} - -This will embed the identified codePen into the content wherever you placed the shortcode, with the result view showing by default: - -{{% codePen VpVNKW %}} - -{{% warning %}} -The compiled site will output an error if your `config.toml` does not include your CodePen username (in the `codePenUser` parameter). This is needed to construct the embed URL. -{{% /warning %}} - -## jsBin - -You can embed JS Bins just like CodePens, supplying a single `id` parameter. - -{{}} -{{% jsBin juwowaq %}} -{{}} - -However, you can also have finer control over which panes are displayed. Use two parameters: one for the `id` and another, `show`, listing the panes you want to include. - -{{}} -{{% jsBin id="juwowaq" show="css,output" %}} -{{}} - -The options for the `show` parameter are: - -* html -* css -* js -* console -* output - -(Note that, under some circumstances, the `html` pane is added whether you select it or not.) - -{{% jsBin id="juwowaq" show="css,output" %}} - - -## Inline demos - -**Cupper** also supports the ability to write inline demos directly in markdown files. See {{% pattern "Writing inline demos" %}}. diff --git a/exampleSite/content/patterns/coding/file-trees.md b/exampleSite/content/patterns/coding/file-trees.md deleted file mode 100644 index 7edc494..0000000 --- a/exampleSite/content/patterns/coding/file-trees.md +++ /dev/null @@ -1,53 +0,0 @@ -+++ -title = "File trees" -+++ - -Representing folder/file structures is simple and accessible in **Cupper**. Which is just as well, because some components may need to conform to a certain folder structure. - -The file tree is described using a markdown nested list structure: - -{{}} -{{% fileTree %}} -* Level 1 folder - * Level 2 file - * Level 2 folder - * Level 3 file - * Level 3 folder - * Level 4 file - * Level 3 folder - * Level 4 file - * Level 4 file - * Level 3 file - * Level 2 folder - * Level 3 file - * Level 3 file - * Level 3 file - * Level 2 file -* Level 1 file -{{% /fileTree %}} -{{}} - -This is drawn in the following fashion, but preserves the underlying nested list structure for assistive technologies such as screen readers: - -{{% fileTree %}} -* Level 1 folder - * Level 2 file - * Level 2 folder - * Level 3 file - * Level 3 folder - * Level 4 file - * Level 3 folder - * Level 4 file - * Level 4 file - * Level 3 file - * Level 2 folder - * Level 3 file - * Level 3 file - * Level 3 file - * Level 2 file -* Level 1 file -{{% /fileTree %}} - -{{% warning %}} -The only reliable way to nest unordered lists in markdown is to indent the nested item by exactly four spaces. Using tabs or less than four spaces are unreliable methods. -{{% /warning %}} diff --git a/exampleSite/content/patterns/coding/tested.md b/exampleSite/content/patterns/coding/tested.md deleted file mode 100644 index a378b8d..0000000 --- a/exampleSite/content/patterns/coding/tested.md +++ /dev/null @@ -1,29 +0,0 @@ -+++ -title = "Tested using..." -+++ - -When you're an inclusive designer, it's pertinent to do some testing. Following specs is one thing, but you need to verify that your component works okay for users. - -**Cupper** provided a `tested` shortcode that lets you show which browsers and assistive technologies you've tried your design out in. Here's an example. Note the commas and "+" signs. - -{{}} -{{% tested using="Firefox + JAWS, Chrome, Safari iOS + Voiceover, Edge" %}} -{{}} - -This outputs: - -{{% tested using="Firefox + JAWS, Chrome, Safari iOS + Voiceover, Edge" %}} - -The value for the `using` attribute follows a specific format: each testing setup is separated by a comma (with a space if you like, but it's not mandatory). If you want to add an assistive technology (or any other "add on") this needs to follow a "+". This additional part can be anything, like "A VR headset I borrowed", but there are only a few browser terms available. These are case sensitive, so you need to write them as below: - -* Firefox -* Chrome -* Safari -* IE -* Edge -* Opera -* Chrome Android -* Firefox Android -* Safari iOS - -Obviously, this is not a comprehensive list and more may be added over time. But it covers most of the main browsers for pairing with other software — at least for testing purposes. diff --git a/exampleSite/content/patterns/coding/writing-inline-demos.md b/exampleSite/content/patterns/coding/writing-inline-demos.md deleted file mode 100644 index a271987..0000000 --- a/exampleSite/content/patterns/coding/writing-inline-demos.md +++ /dev/null @@ -1,108 +0,0 @@ -+++ -title = "Writing inline demos" -weight = 3 -+++ - -There are some issues with {{% pattern "Demo embedding" %}}, like the embeds not working offline. They also come with their own branding, which will clash with the pattern you're trying to illustrate. - -**Cupper** offers another option: a special `demo` shortcode that allows you to write HTML, CSS, and JavaScript directly into the markdown file. The outputted demo is encapsulated using Shadow DOM, so you don't have to worry about broken styles and global JS. - -Here's the example code for an inline demo of a toggle button: - -{{}} -{{<demo>}} -<button aria-pressed="false">Toggle Me</button> -<style> -button { - background: DarkCyan; - color: white; - border: 0; - font-size: 1.5rem; - padding: 0.5em 1em; - border-right: 5px solid #000; - border-bottom: 5px solid #000; -} - -[aria-pressed="true"] { - border: 0; - border-top: 5px solid #000; - border-left: 5px solid #000; -} -</style> -<script> -var toggle = demo.querySelector('[aria-pressed]'); - -toggle.addEventListener('click', (e) => { - let pressed = e.target.getAttribute('aria-pressed') === 'true'; - e.target.setAttribute('aria-pressed', !pressed); -}); -</script> -{{</demo>}} -{{}} - -Note the `demo.querySelector` on line `21`. **Cupper** automatically provides `demo`, representing the root node of the demo. It's like the `document` keyword but for a demo's subtree. - -Here's a live demo _of_ the demo: - -{{}} - - - -{{}} - -## Styling the container - -Sometimes your component will be expected to appear in a context where the parent element has a background color and possibly other styles. You can add style to your demo block's container element using the `style` attribute. It works just like standard inline styling. - -{{}} -{{<demo style="background-color: pink; padding: 1rem;">}} -<!-- demo code here --> -{{</demo>}} -{{}} - -## "Launch" - -The "Launch" button takes the demo code and pushes it to a new browser tab. This serves two purposes: - -* It provides a fallback for browsers that do not support Shadow DOM encapsulation (a warning message will replace the inline demo). -* It creates an isolated test case for the demo, allowing you to run browser extensions and bookmarklets on the the demo code and _just_ the demo code. - -{{% note %}} -The "Launch" button is positioned over the styleable demo container. Bear this is mind when styling the container (see the previous section). -{{% /note %}} - -## Captioned demos - -It's possible to give your demo a caption using an accessible `
` and `
` structure. All _you_ need to do is supply a `caption` attribute. For example: - -{{}} -{{<demo caption="A basic button element">}} -<!-- demo code here --> -{{</demo>}} -{{}} - -Along with the standard `figure` shortcodes (described in {{% pattern "Including images" %}}), demo figures are numbered automatically according to their order in the page. You can use markdown syntax in the caption text value. diff --git a/exampleSite/content/patterns/installation.md b/exampleSite/content/patterns/installation.md deleted file mode 100644 index e918544..0000000 --- a/exampleSite/content/patterns/installation.md +++ /dev/null @@ -1,54 +0,0 @@ -+++ -title = "Installation" -weight = 1 -+++ - -**Cupper** is built using the static site engine, [Hugo](https://gohugo.io/), and NPM. The codebase is available to download on Github. Let's get everything installed step-by-step. - -## Install Hugo - -First you need to install Hugo globally. - -### OSX users - -If you are a Mac user and have [Homebrew](https://brew.sh/) on your system, installing Hugo is simple: - -{{}}brew install hugo{{}} - -Alternatively, you can manually [install Hugo from a package](https://github.com/gohugoio/hugo/releases). You can verify the installation was successful by typing: - -{{}}hugo version{{}} - -### Windows users - -Installing on Windows is a little more involved than on OSX. The authors of Hugo provide [a guide](https://gohugo.io/tutorials/installing-on-windows/) with instructions for technical and less technical users. - -It's also best you install a Windows Subsystem for running Linux, and therefore [bash](https://en.wikipedia.org/wiki/Bash_(Unix_shell)) (**Cupper** incorporates some bash commands in its scripts). [Microsoft offer a complete guide](https://msdn.microsoft.com/en-gb/commandline/wsl/install_guide). - -## Install Node & NPM - -It is likely you already have Node and NPM installed on your system. If so, you can skip this step. Otherwise, [refer to NPM's own guide](https://docs.npmjs.com/getting-started/installing-node), which includes a video tutorial. - -## Get the files - -**Cupper** is hosted on Github. To start using it, you'll need to get the files from there. If you are comfortable with the command line, just fork the [github.com/ThePacielloGroup/cupper](https://github.com/ThePacielloGroup/cupper) repository, then do a `git clone` to your local system. Replace `[your username]` in the following: - -{{}}git clone https://github.com/[your username]/cupper.git{{}} - -If the command line is not your thing, use Github's web interface to fork [github.com/ThePacielloGroup/cupper](https://github.com/ThePacielloGroup/cupper) and choose **Open in Desktop** from **Clone or download** (see figure 1, below). - -{{% figure caption="The Github web interface" %}} -![The open in desktop option, revealed when clicking clone or download](/images/open_in_desktop.png) -{{% /figure %}} - -{{% note %}} -If you do not have a version of the Github desktop client installed, follow the prompts after clicking **Open in Desktop**. -{{% /note %}} - -While you're in the Github interface, you might as well set up the publishing source for the live site. Choose the Master branch/docs option under **Settings → Github Pages → Source**. See {{% pattern "Serving" %}} for more details. - -Once you have your local copy of the files, move to the root of that folder and in your terminal run an npm installation: - -{{}}npm install{{}} - -Now it's time to consult the {{% pattern "Setup" %}} pattern. diff --git a/exampleSite/content/patterns/media/_index.md b/exampleSite/content/patterns/media/_index.md deleted file mode 100644 index c586e20..0000000 --- a/exampleSite/content/patterns/media/_index.md +++ /dev/null @@ -1,4 +0,0 @@ -+++ -title = "Media" -weight = 2 -+++ diff --git a/exampleSite/content/patterns/media/including-images.md b/exampleSite/content/patterns/media/including-images.md deleted file mode 100644 index a0477e0..0000000 --- a/exampleSite/content/patterns/media/including-images.md +++ /dev/null @@ -1,50 +0,0 @@ -+++ -title = "Including images" -+++ - -From time to time, you'll be wanting to include images illustrating the documented pattern in hand. Images live in the static folder, which is a sibling of the `/content` folder you'll be mostly working in. - -{{% fileTree %}} -* content -* static - * images - * logo.png - * menu-button.gif -{{% /fileTree %}} - -{{% note %}} -When you first make a copy of **Cupper**, **Cupper's** own logo will be included. You should replace this with your own company or project logo. -{{% /note %}} - -The path to the `/images` folder should begin with a forward slash, so include that when referencing images in your markdown. - -``` -![Global Megacorp Ltd](/images/logo.png) -``` - -## Figures - -Sometimes you will want to include a caption with your illustration. This is what the `
` and `
` elements are for. However, **Cupper** doesn't ask you to code all that manually. A special shortcode is provided, which takes a `caption` parameter. Note that the image markdown is provided between the opening and closing shortcode tags, and that you can use markdown syntax in the `caption` value. - -{{}} -{{% figure caption="A design system that uses a bad code example as a **single source of truth** only serves to proliferate bad code." %}} -![Diagram of a design pattern represented by a turd emoji begetting three bad implementations](/images/bad_design_system.png) -{{% /figure %}} -{{}} - -This will output the following. Note the automatically incremented **Figure** number. - -{{% figure caption="A design system that uses a bad code example as a **single source of truth** only serves to proliferate bad code." %}} -![Diagram of a design pattern represented by a turd emoji begetting three bad implementations](/images/bad_design_system.png) -{{% /figure %}} - -The generated markup includes special provisions for assistive technology support: - -```html -
-

Diagram of a design pattern represented by a turd emoji begetting three bad implementations

-
- A design system that uses a bad code example as a single source of truth only serves to proliferate bad code. -
-
-``` diff --git a/exampleSite/content/patterns/media/including-videos.md b/exampleSite/content/patterns/media/including-videos.md deleted file mode 100644 index 3eb37c0..0000000 --- a/exampleSite/content/patterns/media/including-videos.md +++ /dev/null @@ -1,9 +0,0 @@ -+++ -title = "Including videos" -+++ - -**Cupper** has a lot of its own shortcodes, but you can still use Hugo's [built in shortcodes](https://gohugo.io/extras/shortcodes#built-in-shortcodes). These include a simple shortcode for including YouTube videos in your content. The shortcode takes just one parameter — the video's `id`. - -{{}} -{{<youtube w7Ft2ymGmfc>}} -{{}} diff --git a/exampleSite/content/patterns/printing.md b/exampleSite/content/patterns/printing.md deleted file mode 100644 index aee1061..0000000 --- a/exampleSite/content/patterns/printing.md +++ /dev/null @@ -1,14 +0,0 @@ -+++ -title = "Printing" -weight = 4 -+++ - -**Cupper**'s output site includes a one-page {{% pattern "Print version" %}} of the generated library, available at `/print-version`. So, if your library base URL is `https://yourName.github.io/your-library`, you can print the whole library — to PDF if wanted — from the following address: - -``` -https://yourName.github.io/your-library/print-version -``` - -{{% note %}} -Print styles are also provided for individual pattern pages so, if you wanted to print off a single pattern document, you can! -{{% /note %}} diff --git a/exampleSite/content/patterns/serving.md b/exampleSite/content/patterns/serving.md deleted file mode 100644 index 62d6bf6..0000000 --- a/exampleSite/content/patterns/serving.md +++ /dev/null @@ -1,34 +0,0 @@ -+++ -title = "Serving" -weight = 3 -+++ - -## Serving locally - -While you're creating content for your project, you'll probably want to see what the finished product looks like. Fortunately, **Cupper** is easy to serve locally using the `serve` command: - -{{}}npm run serve{{}} - -This will serve your working project from `localhost:1313`. Whenever you make changes to your files, the site will automatically rebuild. No need to refresh the web page! - -## Publishing on Github Pages - -**Cupper** creates a `/docs` folder containing the latest version of your site whenever you do an `npm run build` or a `git commit`. So long as you forked the **Cupper** repository when making your own version (see {{% pattern "Setup" %}}), whenever you push to master, you will also be updating the site found at your Github Pages URL. - -This URL will be in the following format: - -``` -[your user name].github.io/[your library repo name] -``` - -You'll also need to add this value to your `config.toml` file as the `baseURL`. For **Cupper**'s own documentation it looks like the following. Just overwrite it. - -``` -baseURL = "https://thepaciellogroup.github.io/cupper/" -``` - -### Set the publishing source - -You will find the `docs` folder is not automatically setup as the publishing source, even when forking the repo. In which case, you must set it under **Settings → Github Pages → Source** in the web interface. - -![The publishing source dropdown menu on Github](/images/serve_from_docs.png) diff --git a/exampleSite/content/patterns/setup.md b/exampleSite/content/patterns/setup.md deleted file mode 100644 index 6323911..0000000 --- a/exampleSite/content/patterns/setup.md +++ /dev/null @@ -1,73 +0,0 @@ -+++ -title = "Setup" -weight = 2 -+++ - -By now, you should have followed the {{% pattern "Installation" %}} instructions. You should have Hugo and Node installed, and a local copy of a forked version of **Cupper**. You should also have run `npm install` in the root of that codebase. - -## "Cleaning" the content folder - -Before you can start writing documentation, there are a few things still to do in order to get set up. At the moment, your version of **Cupper** is a facsimile of the original, containing all the content you're reading right now. We want to delete that content and replace it with some starter content. There's a simple `clean` command for this. - -{{% warning %}} -If you are contributing to an existing **Cupper** library, do not run the following command. It will delete all of the patterns in that library. The `clean` command is just for libraries that you are starting from scratch. -{{% /warning %}} - -{{}} - npm run clean -{{}} - -This will leave your `content` folder with just an `_index.md` file and a `patterns` folder containing a single demonstration pattern file. Individual content pages in **Cupper** are referred to as "patterns" — think pattern libraries). Find out more about these in {{% pattern "Project structure" %}}. - -## The config file - -You'll also want to name your project and configure one or two other things in the `config.toml` file that's found at the root of your project. Here's how that file looks: - -{{}} -languageCode = "en-us" -title = "Cupper" -baseURL = "https://thepaciellogroup.github.io/cupper/" -theme = "cupper" - -[params] - description = "Documentation for the **Cupper** documentation builder. This documentation is constructed using the builder itself." - codePenUser = "Heydon" -{{}} - -* **title** — This is the project's name, like "Megacorp 5000 Pattern Library" or "Assplosion.js Documentation". For **Cupper's** own version of **Cupper**, the `title` is simply _Cupper_ :-) -* **baseURL** — This is the root of the live site. Typically you will publish the site to Github Pages, so this should be the base URL for your Github Pages site. -* **theme** — This is the theme the library is using. Don't change this from "cupper". -* **description** — This is a short description of your documentation project and comes under the logo. You can include markdown syntax here, like _**Cupper**_ in the above example for making the name of the library bold. -* **codePenUser** — If you want to embed codePens in your pattern files, you need to supply a codePen username here. - -## The Web App Manifest - -**Cupper** projects work as progressive web applications, meaning users can save them to their home screen and read them offline. The web app manifest, found at the root of the `static` folder, defines names and icons for the app. You'll probably want to open `/static/manifest.json` and personalize the `name` and `short_name` values. - -``` -{ - "name": "Cupper Documentation Builder", - "short_name": "Cupper Docs", - "icons": [ - {... -``` - -{{% figure caption="Cupper's Docs, with `short_name` displayed, available from the homescreen of a Samsung/Android phone." %}} -![Teacup Cupper app icon with Cupper Docs written underneath](/images/samsung_homescreen.jpg) -{{% /figure %}} - -{{% note %}} -The `short_name` value refers to the text that appears under the icon on your homescreen. As the name suggests, it should be as short as possible to fit well (12 characters or fewer is ideal). -{{% /note %}} - -## Including a logo - -In the `images/static` folder, you'll find a `logo.svg` file. Replace this file with your own company or project logo, under the same file name. Currently, only SVG is supported this easily because SVG is the superior format for logos. However, if you must use a different format, you can open up the `themes/cupper/layouts/_default/baseof.html` file and edit the image reference: - -```html - -``` - -Now that your logo is in place, everything should be ready. Where next? You can learn about {{% pattern "Project structure" %}} to help you get writing, or find out how to serve the site locally and on Github Pages in {{% pattern "Serving" %}}. diff --git a/exampleSite/content/patterns/updating.md b/exampleSite/content/patterns/updating.md deleted file mode 100644 index deaad1b..0000000 --- a/exampleSite/content/patterns/updating.md +++ /dev/null @@ -1,38 +0,0 @@ -+++ -title = "Updating Cupper" -weight = 5 -+++ - -The core of **Cupper's** functionality is in its Hugo theme, also called **Cupper**. This is found in the theme folder. - -{{% fileTree %}} -* content -* docs -* lib -* snippets -* static -* themes - * cupper -{{% /fileTree %}} - -Do not "hack the core". If you have any issues with **Cupper**, please report them to [the **Cupper** Github repository](https://github.com/ThePacielloGroup/cupper/issues) and they will be dealt with ASAP. - -Cupper is undergoing constant development, so keep an eye out for new releases. To update to a new version of **Cupper**, simply run the `update` command from inside your local project folder. - -{{}} -npm run update -{{}} - -This will save a timestamped backup of the current version, and download the latest version. Your theme folder will now look something like the following. - -{{% fileTree %}} -* themes - * cupper - * cupper-old-1503389765972 -{{% /fileTree %}} - -If you experience breaking changes and are having trouble fixing them, you can rename the old folder and revert to using it. In the meantime, you can [submit an issue](https://github.com/ThePacielloGroup/cupper/issues) with the "help" tag describing your problem. - -{{% warning %}} -The described update process relies on SVN because Github does not support downloading individual repository folders. If you have a Mac, SVN should be installed already. If not, or if you are on Windows, you can either install SVN or download the latest [**Cupper** theme folder](https://github.com/ThePacielloGroup/cupper/tree/master/themes/cupper) manually, using the Github web interface. -{{% /warning %}} diff --git a/exampleSite/content/patterns/writing/_index.md b/exampleSite/content/patterns/writing/_index.md deleted file mode 100644 index c536213..0000000 --- a/exampleSite/content/patterns/writing/_index.md +++ /dev/null @@ -1,4 +0,0 @@ -+++ -title = "Writing" -weight = 1 -+++ diff --git a/exampleSite/content/patterns/writing/expandable-sections.md b/exampleSite/content/patterns/writing/expandable-sections.md deleted file mode 100644 index bf07239..0000000 --- a/exampleSite/content/patterns/writing/expandable-sections.md +++ /dev/null @@ -1,48 +0,0 @@ -+++ -title = "Expandable sections" -weight = 6 -+++ - -In some cases, where there is a lot of content, it's helpful to collapse certain sections. That way, readers get an overview of what's in the content and can choose where to focus in. **Cupper** provides a shortcode method for creating expandable sections which generates accessible markup using `aria-expanded`. - -The `expandable` shortcode takes three parameters: - -* **label** — This is the label for the the section heading. -* **level** — This is the heading level (e.g. `level="2"` for an `

`) that will contain the label. If you omit a level parameter, no heading is used; it's just a button. -* **open** — Include this and give it a value of "true" or "yes" to make the section expanded on page load. - -Here's what the code might look like for a simple expandable section containing markdown: - -{{}} -{{% expandable label="A section of dummy text" level="2" %}} -Here is some markdown including [a link](https://twitter.com/heydonworks). Donec erat est, feugiat a est sed, aliquet pharetra ipsum. Vivamus in arcu leo. Praesent feugiat, purus a molestie ultrices, libero massa iaculis ante, sit amet accumsan leo eros vel ligula. -{{% /expandable %}} -{{}} - -Let's look at what that outputs: - -{{% expandable label="A section of dummy text" level="2" %}} -Here is some markdown including [a link](https://twitter.com/heydonworks). Donec erat est, feugiat a est sed, aliquet pharetra ipsum. Vivamus in arcu leo. Praesent feugiat, purus a molestie ultrices, libero massa iaculis ante, sit amet accumsan leo eros vel ligula. -{{% /expandable %}} - -Successive collapsible sections fit snugly together. The second of the following two has `open="true"`. - -{{% expandable label="A section of dummy text" level="2" %}} -Mauris eget elit ut neque venenatis placerat id nec libero. Nunc accumsan cursus elit nec iaculis. Proin id rutrum magna, a aliquet sem. Sed et tortor id sem eleifend porta vitae eget elit. Cras sodales porta malesuada. Suspendisse at odio ac tortor. -{{% /expandable %}} - -{{% expandable label="Another dummy section" level="2" open="true" %}} -Ut vulputate enim ut lorem iaculis, vel faucibus metus iaculis. Aliquam erat volutpat. Aliquam luctus orci vel consectetur dignissim. Nullam et efficitur lorem, et ornare est. Sed tristique porttitor justo, quis malesuada velit. Nullam et elit finibus, sollicitudin velit placerat, ultricies dui. -{{% /expandable %}} - -Unfortunately, it is not currently possible to include shortcodes inside other shortcodes, using the "`%`" notation (which is designated for markdown content). If you use the angle brackets notation (illustrated below) it is possible, but markdown will no longer be permitted. You will have to code HTML inside such a section manually. - -{{}} -{{<expandable label="A section of dummy text" level="2">}} -<p>Here is a pattern reference shortcode: {{% pattern "Writing inline demos" %}}.</p> -{{</expandable>}} -{{}} - -{{% note %}} -When you go to print a pattern from your library, some print styles take care of collapsible sections, making them appear expanded and like any other section. -{{% /note %}} diff --git a/exampleSite/content/patterns/writing/markdown-and-metadata.md b/exampleSite/content/patterns/writing/markdown-and-metadata.md deleted file mode 100644 index f7b4f5e..0000000 --- a/exampleSite/content/patterns/writing/markdown-and-metadata.md +++ /dev/null @@ -1,52 +0,0 @@ -+++ -title = "Markdown & metadata" -weight = 3 -tags = ['metadata', 'markdown'] -+++ - -In **Cupper** everything is documented using markdown, as a "pattern". To create a new pattern file, just add a file with the `.md` extension to the `content/patterns` folder. It's recommended you use "kebab case" to name the file (words separated by hyphens). For example, a pattern with the title "Menu button" should probably have the filename `menu-button`. Then you get a nice clean URL: `username.github.io/your-library/patterns/menu-button`. - -If you're not familiar with writing markdown, there are a number of tutorials available. One of the best is [Mastering Markdown](https://guides.github.com/features/mastering-markdown/) offered by Github. There's also a [nice cheatsheet here](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet). - -## The metadata - -Like many static site generators, Hugo lets you add metadata to its markdown files. Hugo's brand of metadata is called TOML (although YAML is also accepted). The only thing you _have_ to put in the TOML is a `title` — like this: - -``` -+++ -title = "Menu button" -+++ -``` - -{{% note %}} -The title automatically becomes the page's main `

` heading. The highest heading level you should use in the body of your markdown file is therefore `

`. -{{% /note %}} - -### Tags - -If you like, you can also tag the pattern so that it turns up in lists of similar content. You add tags in an array format. Note that all the TOML data is found at the top of the markdown file, between the `+++` lines. - -``` -+++ -title = "Menu button" -tags = ["interactive", "popup", "javascript"] -+++ -``` - -This will create links to pages listing content tagged with the same terms using the URL schema `/tag/[tag name]`. Some example tags links are provided for this page, which you can see listed under the main heading. - -### Weight - -By default, patterns are listed alphabetically in the navigation. However, sometimes you might like to change the order around. This is possible by adding a `weight` parameter. To make my menu button pattern appear at the top of its subsection, I would give it a `weight` of `1`: - -``` -+++ -title = "Menu button" -tags = ["interactive", "popup", "javascript"] -weight = 1 -+++ -``` - -{{% warning %}} -The `weight` parameter should be an integer, not a string, so don't use scare quotes around the value! -{{% /warning %}} diff --git a/exampleSite/content/patterns/writing/notes-and-warnings.md b/exampleSite/content/patterns/writing/notes-and-warnings.md deleted file mode 100644 index 7de2bdd..0000000 --- a/exampleSite/content/patterns/writing/notes-and-warnings.md +++ /dev/null @@ -1,37 +0,0 @@ -+++ -title = "Notes & warnings" -+++ - -**Cupper** acknowledges that simple markdown is limiting when it comes to writing compelling documentation, so it provides a number of "shortcodes". Shortcodes offer a simple syntax for including rich content. For example, **Cupper** provides shortcodes for including notes and warnings. - -## Notes - -You may wish to pick out some content in your pattern's documentation as a note — an aside to the main thrust of the pattern's description. This is possible using the following syntax: - -{{}} -{{% note %}} -This is a note! It's something the reader may like to know about but is supplementary to the main content. Use notes when something may be interesting but not critical. -{{% /note %}} -{{}} - -Notes render like this: - -{{% note %}} -This is a note! It's something the reader may like to know about but is supplementary to the main content. Use notes when something may be interesting but not critical. -{{% /note %}} - -## Warnings - -Warnings are like notes, but with more urgency. - -{{}} -{{% warning %}} -This is a warning! It's about something the reader should be careful to do or to avoid doing. Use warnings when something could go wrong. -{{% /warning %}} -{{}} - -Warnings render like this: - -{{% warning %}} -This is a warning! It's about something the reader should be careful to do or to avoid doing. Use warnings when something could go wrong. -{{% /warning %}} diff --git a/exampleSite/content/patterns/writing/project-structure.md b/exampleSite/content/patterns/writing/project-structure.md deleted file mode 100644 index 204fe6a..0000000 --- a/exampleSite/content/patterns/writing/project-structure.md +++ /dev/null @@ -1,52 +0,0 @@ -+++ -title = "Project structure" -weight = 1 -+++ - -Before you can set about making documentation, you need to know where everything goes. The simplest folder structure looks like this: - -{{% fileTree %}} -* content - * \_index.md - * print-version.md - * patterns - * name-of-my-pattern.md - * name-of-my-other-pattern.md -{{% /fileTree %}} - -* **/content** - This is where all of your content lives. You won't need to visit any other folders very frequently. -* **_index.md** — This is the content file for your home page. -* **print-version.md** — This is a placeholder for the single-page / print-friendly version of you library. Leave this file as it is. -* **/patterns** — This is the folder where individual content files are kept. **Cupper** refers to each individual documentation file/page as a "pattern". - -## Subsections - -You may have noticed that this site's navigation is divided partly into subsections, with labels like "Writing". **Cupper** (or, rather, Hugo) allows you to create such subsections by simply nesting folders under the `/patterns` folder. In the following example, I have a subsection about different types of "popup" pattern. - -{{% fileTree %}} -* content - * \_index.md - * patterns - * name-of-my-pattern.md - * name-of-my-other-pattern.md - * popups - * \_index.md - * popup-menu.md - * tooltips.md -{{% /fileTree %}} - -Subfolders like `/popups` must each have an `_index.md` file. This file doesn't need any content except the TOML metadata defining the title (name) of that subsection: - -``` -+++ -title = "Popup windows" -+++ -``` - -This title is what labels the subsection in the navigation, *not* the folder name (`/popups`, in this case). For each subfolder you create, you must also create one of these `_index.md` files. The `/patterns` folder itself does not need one, however. - -{{% note %}} -**Cupper** does not currently support _sub_-subsections. You can only create child folders under `/patterns`. -{{% /note %}} - -Now that you know where to put everything, it's time to talk about how to actually write individual patterns. Don't worry, it's pretty straightforward. Turn to {{% pattern "Markdown & metadata" %}}. diff --git a/exampleSite/content/patterns/writing/references.md b/exampleSite/content/patterns/writing/references.md deleted file mode 100644 index a0ae77b..0000000 --- a/exampleSite/content/patterns/writing/references.md +++ /dev/null @@ -1,63 +0,0 @@ -+++ -title = "References" -+++ - -## Cross-references - -**Cupper** identifies the main content files in your documentation as _patterns_, and they're kept in the **content/ patterns** folder. It's easy to cross-reference patterns using the `pattern` shortcode. For example, I can reference the {{% pattern "Notes & warnings" %}} pattern. Here's what the markdown looks like, including the shortcode: - -{{}} -I can reference the {{% pattern "Notes & warnings" %}} pattern here. -{{}} - -This saves you having to worry about pathing and decorates the generated link with a bookmark icon, identifying the link as a pattern reference visually. - -{{% note %}} -The title argument you supply to the shortcode must be exactly the same as the referenced pattern's `title` metadata value and is case sensitive. -{{% /note %}} - -## WCAG References - -[WCAG 2.0](https://www.w3.org/TR/WCAG/) is the _de facto_ standard for accessible interfaces. When writing about inclusive interfaces, sometimes you'll want to refer to WCAG to highlight which success criteria the pattern meets. - -Instead of having to copy and paste content and links to WCAG, **Cupper** provides a shortcode mechanism that lets you simply list the success criteria by number: - -{{}} -{{% wcag include="1.2.1, 1.3.1, 4.1.2" %}} -{{}} - -This generates a list of references that includes the names of each criterion and links to them directly. Like this: - -{{% wcag include="2.1.1, 4.1.2" %}} - -{{% note %}} -You don't have to leave spaces after the comma separators. They are optional. -{{% /note %}} - -### Full descriptions - -Sometimes, you'll want to include the full descriptions of the success criteria inline. This is possible by setting `descriptions` to `true`: - -{{}} -{{% wcag include="1.3.1, 4.1.2" descriptions="true" %}} -{{}} - -Here's the more verbose output: - -{{% wcag include="2.1.1, 4.1.2" descriptions="true" %}} - -{{% note %}} -Both omitting the `descriptions` attribute and including it with a "false" value will omit descriptions. If it is included it _must_ have a value. A boolean attribute will break the output. -{{% /note %}} - -## Inclusive Design Principle references - -Some inclusive design concepts are not reducible to success or fail criteria. This is why The Paciello Group wrote the [Inclusive Design Principles](http://inclusivedesignprinciples.org/). These can be listed by name. - -{{}} -{{% principles include="Add value, Be consistent" descriptions="true" %}} -{{}} - -Here's the output with `descriptions="true"`: - -{{% principles include="Add value,Be consistent" descriptions="true" %}} diff --git a/exampleSite/content/patterns/writing/snippets.md b/exampleSite/content/patterns/writing/snippets.md deleted file mode 100644 index c14c3d8..0000000 --- a/exampleSite/content/patterns/writing/snippets.md +++ /dev/null @@ -1,19 +0,0 @@ -+++ -title = "Snippets" -+++ - -A lot of the time, your larger documentation patterns will share some common techniques and utilities. For this reason, **Cupper** lets you save snippets of markdown in a **snippets** folder, alongside the main content folder. - -The example `visually-hidden.md` snippet describes the CSS needed to create content that is visually hidden but still available to screen readers. Since this is a technique/utility you are likely to use often, it's nice to be able to just drop a snippet into your markdown content. The `snippet` shortcode lets you do exactly that: - -{{}} -{{% snippet file="visually-hidden.md" %}} -{{}} - -{{% note %}} -To make your snippets truly reusable, try to write them in such a way that they make sense independent of surrounding text, a little bit like this note does. -{{% /note %}} - -## Visually hidden snippet - -{{/% snippet file="visually-hidden.md" %/}} diff --git a/exampleSite/content/patterns/writing/tables-of-contents.md b/exampleSite/content/patterns/writing/tables-of-contents.md deleted file mode 100644 index a3e33ce..0000000 --- a/exampleSite/content/patterns/writing/tables-of-contents.md +++ /dev/null @@ -1,34 +0,0 @@ -+++ -title = "Tables of contents" -+++ - -Pattern pages in **Cupper** that have two or more subheadings (`

`s) automatically get a **table of contents**: a list of links to the main subsections for the page. This feature is made accessible as a navigation region with the "Table of contents" label and uses an ordered list. The table of contents markup for the {{% pattern "Setup" %}} page looks something like this: - -```html - -``` - -Tables of content are a neat way to break down the content of the page and give users a navigable overview. However, they may not be to your taste. Never fear, you can turn tables of content off by adding `toc = false` to the TOML metadata for your pattern: - -``` -+++ -title = "My page with a few headings" -toc = false -+++ -``` diff --git a/exampleSite/content/post/_index.md b/exampleSite/content/post/_index.md new file mode 100644 index 0000000..6f1bd49 --- /dev/null +++ b/exampleSite/content/post/_index.md @@ -0,0 +1,3 @@ +--- +title: Blog +--- \ No newline at end of file diff --git a/exampleSite/content/post/creating-a-new-theme.md b/exampleSite/content/post/creating-a-new-theme.md new file mode 100644 index 0000000..66bb85a --- /dev/null +++ b/exampleSite/content/post/creating-a-new-theme.md @@ -0,0 +1,1143 @@ +--- +date: "2014-09-28" +tags: ["hugo", "theme", "command-line"] +title: "Creating a New Theme" +--- + + +## Introduction + +This tutorial will show you how to create a simple theme in Hugo. I assume that you are familiar with HTML, the bash command line, and that you are comfortable using Markdown to format content. I'll explain how Hugo uses templates and how you can organize your templates to create a theme. I won't cover using CSS to style your theme. + +We'll start with creating a new site with a very basic template. Then we'll add in a few pages and posts. With small variations on that, you will be able to create many different types of web sites. + +In this tutorial, commands that you enter will start with the "$" prompt. The output will follow. Lines that start with "#" are comments that I've added to explain a point. When I show updates to a file, the ":wq" on the last line means to save the file. + +Here's an example: + +``` +## this is a comment +$ echo this is a command +this is a command + +## edit the file +$ vi foo.md ++++ +date = "2014-09-28" +title = "creating a new theme" ++++ + +bah and humbug +:wq + +## show it +$ cat foo.md ++++ +date = "2014-09-28" +title = "creating a new theme" ++++ + +bah and humbug +$ +``` + + +## Some Definitions + +There are a few concepts that you need to understand before creating a theme. + +### Skins + +Skins are the files responsible for the look and feel of your site. It’s the CSS that controls colors and fonts, it’s the Javascript that determines actions and reactions. It’s also the rules that Hugo uses to transform your content into the HTML that the site will serve to visitors. + +You have two ways to create a skin. The simplest way is to create it in the ```layouts/``` directory. If you do, then you don’t have to worry about configuring Hugo to recognize it. The first place that Hugo will look for rules and files is in the ```layouts/``` directory so it will always find the skin. + +Your second choice is to create it in a sub-directory of the ```themes/``` directory. If you do, then you must always tell Hugo where to search for the skin. It’s extra work, though, so why bother with it? + +The difference between creating a skin in ```layouts/``` and creating it in ```themes/``` is very subtle. A skin in ```layouts/``` can’t be customized without updating the templates and static files that it is built from. A skin created in ```themes/```, on the other hand, can be and that makes it easier for other people to use it. + +The rest of this tutorial will call a skin created in the ```themes/``` directory a theme. + +Note that you can use this tutorial to create a skin in the ```layouts/``` directory if you wish to. The main difference will be that you won’t need to update the site’s configuration file to use a theme. + +### The Home Page + +The home page, or landing page, is the first page that many visitors to a site see. It is the index.html file in the root directory of the web site. Since Hugo writes files to the public/ directory, our home page is public/index.html. + +### Site Configuration File + +When Hugo runs, it looks for a configuration file that contains settings that override default values for the entire site. The file can use TOML, YAML, or JSON. I prefer to use TOML for my configuration files. If you prefer to use JSON or YAML, you’ll need to translate my examples. You’ll also need to change the name of the file since Hugo uses the extension to determine how to process it. + +Hugo translates Markdown files into HTML. By default, Hugo expects to find Markdown files in your ```content/``` directory and template files in your ```themes/``` directory. It will create HTML files in your ```public/``` directory. You can change this by specifying alternate locations in the configuration file. + +### Content + +Content is stored in text files that contain two sections. The first section is the “front matter,” which is the meta-information on the content. The second section contains Markdown that will be converted to HTML. + +#### Front Matter + +The front matter is information about the content. Like the configuration file, it can be written in TOML, YAML, or JSON. Unlike the configuration file, Hugo doesn’t use the file’s extension to know the format. It looks for markers to signal the type. TOML is surrounded by “`+++`”, YAML by “`---`”, and JSON is enclosed in curly braces. I prefer to use TOML, so you’ll need to translate my examples if you prefer YAML or JSON. + +The information in the front matter is passed into the template before the content is rendered into HTML. + +#### Markdown + +Content is written in Markdown which makes it easier to create the content. Hugo runs the content through a Markdown engine to create the HTML which will be written to the output file. + +### Template Files + +Hugo uses template files to render content into HTML. Template files are a bridge between the content and presentation. Rules in the template define what content is published, where it's published to, and how it will rendered to the HTML file. The template guides the presentation by specifying the style to use. + +There are three types of templates: single, list, and partial. Each type takes a bit of content as input and transforms it based on the commands in the template. + +Hugo uses its knowledge of the content to find the template file used to render the content. If it can’t find a template that is an exact match for the content, it will shift up a level and search from there. It will continue to do so until it finds a matching template or runs out of templates to try. If it can’t find a template, it will use the default template for the site. + +Please note that you can use the front matter to influence Hugo’s choice of templates. + +#### Single Template + +A single template is used to render a single piece of content. For example, an article or post would be a single piece of content and use a single template. + +#### List Template + +A list template renders a group of related content. That could be a summary of recent postings or all articles in a category. List templates can contain multiple groups. + +The homepage template is a special type of list template. Hugo assumes that the home page of your site will act as the portal for the rest of the content in the site. + +#### Partial Template + +A partial template is a template that can be included in other templates. Partial templates must be called using the “partial” template command. They are very handy for rolling up common behavior. For example, your site may have a banner that all pages use. Instead of copying the text of the banner into every single and list template, you could create a partial with the banner in it. That way if you decide to change the banner, you only have to change the partial template. + +## Create a New Site + +Let's use Hugo to create a new web site. I'm a Mac user, so I'll create mine in my home directory, in the Sites folder. If you're using Linux, you might have to create the folder first. + +The "new site" command will create a skeleton of a site. It will give you the basic directory structure and a useable configuration file. + +``` +$ hugo new site ~/Sites/zafta +$ cd ~/Sites/zafta +$ ls -l +total 8 +drwxr-xr-x 7 quoha staff 238 Sep 29 16:49 . +drwxr-xr-x 3 quoha staff 102 Sep 29 16:49 .. +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes +-rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static +$ +``` + +Take a look in the content/ directory to confirm that it is empty. + +The other directories (archetypes/, layouts/, and static/) are used when customizing a theme. That's a topic for a different tutorial, so please ignore them for now. + +### Generate the HTML For the New Site + +Running the `hugo` command with no options will read all the available content and generate the HTML files. It will also copy all static files (that's everything that's not content). Since we have an empty site, it won't do much, but it will do it very quickly. + +``` +$ hugo --verbose +INFO: 2014/09/29 Using config file: config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +WARN: 2014/09/29 Unable to locate layout: [404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +$ +``` + +The "`--verbose`" flag gives extra information that will be helpful when we build the template. Every line of the output that starts with "INFO:" or "WARN:" is present because we used that flag. The lines that start with "WARN:" are warning messages. We'll go over them later. + +We can verify that the command worked by looking at the directory again. + +``` +$ ls -l +total 8 +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes +-rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts +drwxr-xr-x 4 quoha staff 136 Sep 29 17:02 public +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static +$ +``` + +See that new public/ directory? Hugo placed all generated content there. When you're ready to publish your web site, that's the place to start. For now, though, let's just confirm that we have what we'd expect from a site with no content. + +``` +$ ls -l public +total 16 +-rw-r--r-- 1 quoha staff 416 Sep 29 17:02 index.xml +-rw-r--r-- 1 quoha staff 262 Sep 29 17:02 sitemap.xml +$ +``` + +Hugo created two XML files, which is standard, but there are no HTML files. + + + +### Test the New Site + +Verify that you can run the built-in web server. It will dramatically shorten your development cycle if you do. Start it by running the "server" command. If it is successful, you will see output similar to the following: + +``` +$ hugo server --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +WARN: 2014/09/29 Unable to locate layout: [404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +Serving pages from /Users/quoha/Sites/zafta/public +Web Server is available at http://localhost:1313 +Press Ctrl+C to stop +``` + +Connect to the listed URL (it's on the line that starts with "Web Server"). If everything is working correctly, you should get a page that shows the following: + +``` +index.xml +sitemap.xml +``` + +That's a listing of your public/ directory. Hugo didn't create a home page because our site has no content. When there's no index.html file in a directory, the server lists the files in the directory, which is what you should see in your browser. + +Let’s go back and look at those warnings again. + +``` +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +WARN: 2014/09/29 Unable to locate layout: [404.html] +``` + +That second warning is easier to explain. We haven’t created a template to be used to generate “page not found errors.” The 404 message is a topic for a separate tutorial. + +Now for the first warning. It is for the home page. You can tell because the first layout that it looked for was “index.html.” That’s only used by the home page. + +I like that the verbose flag causes Hugo to list the files that it's searching for. For the home page, they are index.html, _default/list.html, and _default/single.html. There are some rules that we'll cover later that explain the names and paths. For now, just remember that Hugo couldn't find a template for the home page and it told you so. + +At this point, you've got a working installation and site that we can build upon. All that’s left is to add some content and a theme to display it. + +## Create a New Theme + +Hugo doesn't ship with a default theme. There are a few available (I counted a dozen when I first installed Hugo) and Hugo comes with a command to create new themes. + +We're going to create a new theme called "zafta." Since the goal of this tutorial is to show you how to fill out the files to pull in your content, the theme will not contain any CSS. In other words, ugly but functional. + +All themes have opinions on content and layout. For example, Zafta uses "post" over "blog". Strong opinions make for simpler templates but differing opinions make it tougher to use themes. When you build a theme, consider using the terms that other themes do. + + +### Create a Skeleton + +Use the hugo "new" command to create the skeleton of a theme. This creates the directory structure and places empty files for you to fill out. + +``` +$ hugo new theme zafta + +$ ls -l +total 8 +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes +-rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts +drwxr-xr-x 4 quoha staff 136 Sep 29 17:02 public +drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static +drwxr-xr-x 3 quoha staff 102 Sep 29 17:31 themes + +$ find themes -type f | xargs ls -l +-rw-r--r-- 1 quoha staff 1081 Sep 29 17:31 themes/zafta/LICENSE.md +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/archetypes/default.md +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/single.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/footer.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/header.html +-rw-r--r-- 1 quoha staff 93 Sep 29 17:31 themes/zafta/theme.toml +$ +``` + +The skeleton includes templates (the files ending in .html), license file, a description of your theme (the theme.toml file), and an empty archetype. + +Please take a minute to fill out the theme.toml and LICENSE.md files. They're optional, but if you're going to be distributing your theme, it tells the world who to praise (or blame). It's also nice to declare the license so that people will know how they can use the theme. + +``` +$ vi themes/zafta/theme.toml +author = "michael d henderson" +description = "a minimal working template" +license = "MIT" +name = "zafta" +source_repo = "" +tags = ["tags", "categories"] +:wq + +## also edit themes/zafta/LICENSE.md and change +## the bit that says "YOUR_NAME_HERE" +``` + +Note that the the skeleton's template files are empty. Don't worry, we'll be changing that shortly. + +``` +$ find themes/zafta -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/single.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/footer.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/header.html +$ +``` + + + +### Update the Configuration File to Use the Theme + +Now that we've got a theme to work with, it's a good idea to add the theme name to the configuration file. This is optional, because you can always add "-t zafta" on all your commands. I like to put it the configuration file because I like shorter command lines. If you don't put it in the configuration file or specify it on the command line, you won't use the template that you're expecting to. + +Edit the file to add the theme, add a title for the site, and specify that all of our content will use the TOML format. + +``` +$ vi config.toml +theme = "zafta" +baseurl = "" +languageCode = "en-us" +title = "zafta - totally refreshing" +MetaDataFormat = "toml" +:wq + +$ +``` + +### Generate the Site + +Now that we have an empty theme, let's generate the site again. + +``` +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +$ +``` + +Did you notice that the output is different? The warning message for the home page has disappeared and we have an additional information line saying that Hugo is syncing from the theme's directory. + +Let's check the public/ directory to see what Hugo's created. + +``` +$ ls -l public +total 16 +drwxr-xr-x 2 quoha staff 68 Sep 29 17:56 css +-rw-r--r-- 1 quoha staff 0 Sep 29 17:56 index.html +-rw-r--r-- 1 quoha staff 407 Sep 29 17:56 index.xml +drwxr-xr-x 2 quoha staff 68 Sep 29 17:56 js +-rw-r--r-- 1 quoha staff 243 Sep 29 17:56 sitemap.xml +$ +``` + +Notice four things: + +1. Hugo created a home page. This is the file public/index.html. +2. Hugo created a css/ directory. +3. Hugo created a js/ directory. +4. Hugo claimed that it created 0 pages. It created a file and copied over static files, but didn't create any pages. That's because it considers a "page" to be a file created directly from a content file. It doesn't count things like the index.html files that it creates automatically. + +#### The Home Page + +Hugo supports many different types of templates. The home page is special because it gets its own type of template and its own template file. The file, layouts/index.html, is used to generate the HTML for the home page. The Hugo documentation says that this is the only required template, but that depends. Hugo's warning message shows that it looks for three different templates: + +``` +WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] +``` + +If it can't find any of these, it completely skips creating the home page. We noticed that when we built the site without having a theme installed. + +When Hugo created our theme, it created an empty home page template. Now, when we build the site, Hugo finds the template and uses it to generate the HTML for the home page. Since the template file is empty, the HTML file is empty, too. If the template had any rules in it, then Hugo would have used them to generate the home page. + +``` +$ find . -name index.html | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 20:21 ./public/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 ./themes/zafta/layouts/index.html +$ +``` + +#### The Magic of Static + +Hugo does two things when generating the site. It uses templates to transform content into HTML and it copies static files into the site. Unlike content, static files are not transformed. They are copied exactly as they are. + +Hugo assumes that your site will use both CSS and JavaScript, so it creates directories in your theme to hold them. Remember opinions? Well, Hugo's opinion is that you'll store your CSS in a directory named css/ and your JavaScript in a directory named js/. If you don't like that, you can change the directory names in your theme directory or even delete them completely. Hugo's nice enough to offer its opinion, then behave nicely if you disagree. + +``` +$ find themes/zafta -type d | xargs ls -ld +drwxr-xr-x 7 quoha staff 238 Sep 29 17:38 themes/zafta +drwxr-xr-x 3 quoha staff 102 Sep 29 17:31 themes/zafta/archetypes +drwxr-xr-x 5 quoha staff 170 Sep 29 17:31 themes/zafta/layouts +drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/layouts/_default +drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/layouts/partials +drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/static +drwxr-xr-x 2 quoha staff 68 Sep 29 17:31 themes/zafta/static/css +drwxr-xr-x 2 quoha staff 68 Sep 29 17:31 themes/zafta/static/js +$ +``` + +## The Theme Development Cycle + +When you're working on a theme, you will make changes in the theme's directory, rebuild the site, and check your changes in the browser. Hugo makes this very easy: + +1. Purge the public/ directory. +2. Run the built in web server in watch mode. +3. Open your site in a browser. +4. Update the theme. +5. Glance at your browser window to see changes. +6. Return to step 4. + +I’ll throw in one more opinion: never work on a theme on a live site. Always work on a copy of your site. Make changes to your theme, test them, then copy them up to your site. For added safety, use a tool like Git to keep a revision history of your content and your theme. Believe me when I say that it is too easy to lose both your mind and your changes. + +Check the main Hugo site for information on using Git with Hugo. + +### Purge the public/ Directory + +When generating the site, Hugo will create new files and update existing ones in the ```public/``` directory. It will not delete files that are no longer used. For example, files that were created in the wrong directory or with the wrong title will remain. If you leave them, you might get confused by them later. I recommend cleaning out your site prior to generating it. + +Note: If you're building on an SSD, you should ignore this. Churning on a SSD can be costly. + +### Hugo's Watch Option + +Hugo's "`--watch`" option will monitor the content/ and your theme directories for changes and rebuild the site automatically. + +### Live Reload + +Hugo's built in web server supports live reload. As pages are saved on the server, the browser is told to refresh the page. Usually, this happens faster than you can say, "Wow, that's totally amazing." + +### Development Commands + +Use the following commands as the basis for your workflow. + +``` +## purge old files. hugo will recreate the public directory. +## +$ rm -rf public +## +## run hugo in watch mode +## +$ hugo server --watch --verbose +``` + +Here's sample output showing Hugo detecting a change to the template for the home page. Once generated, the web browser automatically reloaded the page. I've said this before, it's amazing. + + +``` +$ rm -rf public +$ hugo server --watch --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms +Watching for changes in /Users/quoha/Sites/zafta/content +Serving pages from /Users/quoha/Sites/zafta/public +Web Server is available at http://localhost:1313 +Press Ctrl+C to stop +INFO: 2014/09/29 File System Event: ["/Users/quoha/Sites/zafta/themes/zafta/layouts/index.html": MODIFY|ATTRIB] +Change detected, rebuilding site + +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 1 ms +``` + +## Update the Home Page Template + +The home page is one of a few special pages that Hugo creates automatically. As mentioned earlier, it looks for one of three files in the theme's layout/ directory: + +1. index.html +2. _default/list.html +3. _default/single.html + +We could update one of the default templates, but a good design decision is to update the most specific template available. That's not a hard and fast rule (in fact, we'll break it a few times in this tutorial), but it is a good generalization. + +### Make a Static Home Page + +Right now, that page is empty because we don't have any content and we don't have any logic in the template. Let's change that by adding some text to the template. + +``` +$ vi themes/zafta/layouts/index.html + + + +

hugo says hello!

+ + +:wq + +$ +``` + +Build the web site and then verify the results. + +``` +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +0 pages created +0 tags created +0 categories created +in 2 ms + +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 78 Sep 29 21:26 public/index.html + +$ cat public/index.html + + + +

hugo says hello!

+ +``` + +#### Live Reload + +Note: If you're running the server with the `--watch` option, you'll see different content in the file: + +``` +$ cat public/index.html + + + +

hugo says hello!

+ + +``` + +When you use `--watch`, the Live Reload script is added by Hugo. Look for live reload in the documentation to see what it does and how to disable it. + +### Build a "Dynamic" Home Page + +"Dynamic home page?" Hugo's a static web site generator, so this seems an odd thing to say. I mean let's have the home page automatically reflect the content in the site every time Hugo builds it. We'll use iteration in the template to do that. + +#### Create New Posts + +Now that we have the home page generating static content, let's add some content to the site. We'll display these posts as a list on the home page and on their own page, too. + +Hugo has a command to generate a skeleton post, just like it does for sites and themes. + +``` +$ hugo --verbose new post/first.md +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 attempting to create post/first.md of post +INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/default.md +ERROR: 2014/09/29 Unable to Cast to map[string]interface{} + +$ +``` + +That wasn't very nice, was it? + +The "new" command uses an archetype to create the post file. Hugo created an empty default archetype file, but that causes an error when there's a theme. For me, the workaround was to create an archetypes file specifically for the post type. + +``` +$ vi themes/zafta/archetypes/post.md ++++ +Description = "" +Tags = [] +Categories = [] ++++ +:wq + +$ find themes/zafta/archetypes -type f | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 21:53 themes/zafta/archetypes/default.md +-rw-r--r-- 1 quoha staff 51 Sep 29 21:54 themes/zafta/archetypes/post.md + +$ hugo --verbose new post/first.md +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 attempting to create post/first.md of post +INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/post.md +INFO: 2014/09/29 creating /Users/quoha/Sites/zafta/content/post/first.md +/Users/quoha/Sites/zafta/content/post/first.md created + +$ hugo --verbose new post/second.md +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 attempting to create post/second.md of post +INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/post.md +INFO: 2014/09/29 creating /Users/quoha/Sites/zafta/content/post/second.md +/Users/quoha/Sites/zafta/content/post/second.md created + +$ ls -l content/post +total 16 +-rw-r--r-- 1 quoha staff 104 Sep 29 21:54 first.md +-rw-r--r-- 1 quoha staff 105 Sep 29 21:57 second.md + +$ cat content/post/first.md ++++ +Categories = [] +Description = "" +Tags = [] +date = "2014-09-29T21:54:53-05:00" +title = "first" + ++++ +my first post + +$ cat content/post/second.md ++++ +Categories = [] +Description = "" +Tags = [] +date = "2014-09-29T21:57:09-05:00" +title = "second" + ++++ +my second post + +$ +``` + +Build the web site and then verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"category":"categories", "tag":"tags"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms +$ +``` + +The output says that it created 2 pages. Those are our new posts: + +``` +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 78 Sep 29 22:13 public/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/second/index.html +$ +``` + +The new files are empty because because the templates used to generate the content are empty. The homepage doesn't show the new content, either. We have to update the templates to add the posts. + +### List and Single Templates + +In Hugo, we have three major kinds of templates. There's the home page template that we updated previously. It is used only by the home page. We also have "single" templates which are used to generate output for a single content file. We also have "list" templates that are used to group multiple pieces of content before generating output. + +Generally speaking, list templates are named "list.html" and single templates are named "single.html." + +There are three other types of templates: partials, content views, and terms. We will not go into much detail on these. + +### Add Content to the Homepage + +The home page will contain a list of posts. Let's update its template to add the posts that we just created. The logic in the template will run every time we build the site. + +``` +$ vi themes/zafta/layouts/index.html + + + + {{ range first 10 .Data.Pages }} +

{{ .Title }}

+ {{ end }} + + +:wq + +$ +``` + +Hugo uses the Go template engine. That engine scans the template files for commands which are enclosed between "{{" and "}}". In our template, the commands are: + +1. range +2. .Title +3. end + +The "range" command is an iterator. We're going to use it to go through the first ten pages. Every HTML file that Hugo creates is treated as a page, so looping through the list of pages will look at every file that will be created. + +The ".Title" command prints the value of the "title" variable. Hugo pulls it from the front matter in the Markdown file. + +The "end" command signals the end of the range iterator. The engine loops back to the top of the iteration when it finds "end." Everything between the "range" and "end" is evaluated every time the engine goes through the iteration. In this file, that would cause the title from the first ten pages to be output as heading level one. + +It's helpful to remember that some variables, like .Data, are created before any output files. Hugo loads every content file into the variable and then gives the template a chance to process before creating the HTML files. + +Build the web site and then verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 94 Sep 29 22:23 public/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/second/index.html +$ cat public/index.html + + + + +

second

+ +

first

+ + + +$ +``` + +Congratulations, the home page shows the title of the two posts. The posts themselves are still empty, but let's take a moment to appreciate what we've done. Your template now generates output dynamically. Believe it or not, by inserting the range command inside of those curly braces, you've learned everything you need to know to build a theme. All that's really left is understanding which template will be used to generate each content file and becoming familiar with the commands for the template engine. + +And, if that were entirely true, this tutorial would be much shorter. There are a few things to know that will make creating a new template much easier. Don't worry, though, that's all to come. + +### Add Content to the Posts + +We're working with posts, which are in the content/post/ directory. That means that their section is "post" (and if we don't do something weird, their type is also "post"). + +Hugo uses the section and type to find the template file for every piece of content. Hugo will first look for a template file that matches the section or type name. If it can't find one, then it will look in the _default/ directory. There are some twists that we'll cover when we get to categories and tags, but for now we can assume that Hugo will try post/single.html, then _default/single.html. + +Now that we know the search rule, let's see what we actually have available: + +``` +$ find themes/zafta -name single.html | xargs ls -l +-rw-r--r-- 1 quoha staff 132 Sep 29 17:31 themes/zafta/layouts/_default/single.html +``` + +We could create a new template, post/single.html, or change the default. Since we don't know of any other content types, let's start with updating the default. + +Remember, any content that we haven't created a template for will end up using this template. That can be good or bad. Bad because I know that we're going to be adding different types of content and we're going to end up undoing some of the changes we've made. It's good because we'll be able to see immediate results. It's also good to start here because we can start to build the basic layout for the site. As we add more content types, we'll refactor this file and move logic around. Hugo makes that fairly painless, so we'll accept the cost and proceed. + +Please see the Hugo documentation on template rendering for all the details on determining which template to use. And, as the docs mention, if you're building a single page application (SPA) web site, you can delete all of the other templates and work with just the default single page. That's a refreshing amount of joy right there. + +#### Update the Template File + +``` +$ vi themes/zafta/layouts/_default/single.html + + + + {{ .Title }} + + +

{{ .Title }}

+ {{ .Content }} + + +:wq + +$ +``` + +Build the web site and verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms + +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 94 Sep 29 22:40 public/index.html +-rw-r--r-- 1 quoha staff 125 Sep 29 22:40 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:40 public/post/index.html +-rw-r--r-- 1 quoha staff 128 Sep 29 22:40 public/post/second/index.html + +$ cat public/post/first/index.html + + + + first + + +

first

+

my first post

+ + + + +$ cat public/post/second/index.html + + + + second + + +

second

+

my second post

+ + + +$ +``` + +Notice that the posts now have content. You can go to localhost:1313/post/first to verify. + +### Linking to Content + +The posts are on the home page. Let's add a link from there to the post. Since this is the home page, we'll update its template. + +``` +$ vi themes/zafta/layouts/index.html + + + + {{ range first 10 .Data.Pages }} +

{{ .Title }}

+ {{ end }} + + +``` + +Build the web site and verify the results. + +``` +$ rm -rf public +$ hugo --verbose +INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ +INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} +WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] +0 draft content +0 future content +2 pages created +0 tags created +0 categories created +in 4 ms + +$ find public -type f -name '*.html' | xargs ls -l +-rw-r--r-- 1 quoha staff 149 Sep 29 22:44 public/index.html +-rw-r--r-- 1 quoha staff 125 Sep 29 22:44 public/post/first/index.html +-rw-r--r-- 1 quoha staff 0 Sep 29 22:44 public/post/index.html +-rw-r--r-- 1 quoha staff 128 Sep 29 22:44 public/post/second/index.html + +$ cat public/index.html + + + + +

second

+ +

first

+ + + + +$ +``` + +### Create a Post Listing + +We have the posts displaying on the home page and on their own page. We also have a file public/post/index.html that is empty. Let's make it show a list of all posts (not just the first ten). + +We need to decide which template to update. This will be a listing, so it should be a list template. Let's take a quick look and see which list templates are available. + +``` +$ find themes/zafta -name list.html | xargs ls -l +-rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html +``` + +As with the single post, we have to decide to update _default/list.html or create post/list.html. We still don't have multiple content types, so let's stay consistent and update the default list template. + +## Creating Top Level Pages + +Let's add an "about" page and display it at the top level (as opposed to a sub-level like we did with posts). + +The default in Hugo is to use the directory structure of the content/ directory to guide the location of the generated html in the public/ directory. Let's verify that by creating an "about" page at the top level: + +``` +$ vi content/about.md ++++ +title = "about" +description = "about this site" +date = "2014-09-27" +slug = "about time" ++++ + +## about us + +i'm speechless +:wq +``` + +Generate the web site and verify the results. + +``` +$ find public -name '*.html' | xargs ls -l +-rw-rw-r-- 1 mdhender staff 334 Sep 27 15:08 public/about-time/index.html +-rw-rw-r-- 1 mdhender staff 527 Sep 27 15:08 public/index.html +-rw-rw-r-- 1 mdhender staff 358 Sep 27 15:08 public/post/first-post/index.html +-rw-rw-r-- 1 mdhender staff 0 Sep 27 15:08 public/post/index.html +-rw-rw-r-- 1 mdhender staff 342 Sep 27 15:08 public/post/second-post/index.html +``` + +Notice that the page wasn't created at the top level. It was created in a sub-directory named 'about-time/'. That name came from our slug. Hugo will use the slug to name the generated content. It's a reasonable default, by the way, but we can learn a few things by fighting it for this file. + +One other thing. Take a look at the home page. + +``` +$ cat public/index.html + + + +

creating a new theme

+

about

+

second

+

first

+ + +``` + +Notice that the "about" link is listed with the posts? That's not desirable, so let's change that first. + +``` +$ vi themes/zafta/layouts/index.html + + + +

posts

+ {{ range first 10 .Data.Pages }} + {{ if eq .Type "post"}} +

{{ .Title }}

+ {{ end }} + {{ end }} + +

pages

+ {{ range .Data.Pages }} + {{ if eq .Type "page" }} +

{{ .Title }}

+ {{ end }} + {{ end }} + + +:wq +``` + +Generate the web site and verify the results. The home page has two sections, posts and pages, and each section has the right set of headings and links in it. + +But, that about page still renders to about-time/index.html. + +``` +$ find public -name '*.html' | xargs ls -l +-rw-rw-r-- 1 mdhender staff 334 Sep 27 15:33 public/about-time/index.html +-rw-rw-r-- 1 mdhender staff 645 Sep 27 15:33 public/index.html +-rw-rw-r-- 1 mdhender staff 358 Sep 27 15:33 public/post/first-post/index.html +-rw-rw-r-- 1 mdhender staff 0 Sep 27 15:33 public/post/index.html +-rw-rw-r-- 1 mdhender staff 342 Sep 27 15:33 public/post/second-post/index.html +``` + +Knowing that hugo is using the slug to generate the file name, the simplest solution is to change the slug. Let's do it the hard way and change the permalink in the configuration file. + +``` +$ vi config.toml +[permalinks] + page = "/:title/" + about = "/:filename/" +``` + +Generate the web site and verify that this didn't work. Hugo lets "slug" or "URL" override the permalinks setting in the configuration file. Go ahead and comment out the slug in content/about.md, then generate the web site to get it to be created in the right place. + +## Sharing Templates + +If you've been following along, you probably noticed that posts have titles in the browser and the home page doesn't. That's because we didn't put the title in the home page's template (layouts/index.html). That's an easy thing to do, but let's look at a different option. + +We can put the common bits into a shared template that's stored in the themes/zafta/layouts/partials/ directory. + +### Create the Header and Footer Partials + +In Hugo, a partial is a sugar-coated template. Normally a template reference has a path specified. Partials are different. Hugo searches for them along a TODO defined search path. This makes it easier for end-users to override the theme's presentation. + +``` +$ vi themes/zafta/layouts/partials/header.html + + + + {{ .Title }} + + +:wq + +$ vi themes/zafta/layouts/partials/footer.html + + +:wq +``` + +### Update the Home Page Template to Use the Partials + +The most noticeable difference between a template call and a partials call is the lack of path: + +``` +{{ template "theme/partials/header.html" . }} +``` +versus +``` +{{ partial "header.html" . }} +``` +Both pass in the context. + +Let's change the home page template to use these new partials. + +``` +$ vi themes/zafta/layouts/index.html +{{ partial "header.html" . }} + +

posts

+ {{ range first 10 .Data.Pages }} + {{ if eq .Type "post"}} +

{{ .Title }}

+ {{ end }} + {{ end }} + +

pages

+ {{ range .Data.Pages }} + {{ if or (eq .Type "page") (eq .Type "about") }} +

{{ .Type }} - {{ .Title }} - {{ .RelPermalink }}

+ {{ end }} + {{ end }} + +{{ partial "footer.html" . }} +:wq +``` + +Generate the web site and verify the results. The title on the home page is now "your title here", which comes from the "title" variable in the config.toml file. + +### Update the Default Single Template to Use the Partials + +``` +$ vi themes/zafta/layouts/_default/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq +``` + +Generate the web site and verify the results. The title on the posts and the about page should both reflect the value in the markdown file. + +## Add “Date Published” to Posts + +It's common to have posts display the date that they were written or published, so let's add that. The front matter of our posts has a variable named "date." It's usually the date the content was created, but let's pretend that's the value we want to display. + +### Add “Date Published” to the Template + +We'll start by updating the template used to render the posts. The template code will look like: + +``` +{{ .Date.Format "Mon, Jan 2, 2006" }} +``` + +Posts use the default single template, so we'll change that file. + +``` +$ vi themes/zafta/layouts/_default/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+

{{ .Date.Format "Mon, Jan 2, 2006" }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq +``` + +Generate the web site and verify the results. The posts now have the date displayed in them. There's a problem, though. The "about" page also has the date displayed. + +As usual, there are a couple of ways to make the date display only on posts. We could do an "if" statement like we did on the home page. Another way would be to create a separate template for posts. + +The "if" solution works for sites that have just a couple of content types. It aligns with the principle of "code for today," too. + +Let's assume, though, that we've made our site so complex that we feel we have to create a new template type. In Hugo-speak, we're going to create a section template. + +Let's restore the default single template before we forget. + +``` +$ mkdir themes/zafta/layouts/post +$ vi themes/zafta/layouts/_default/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq +``` + +Now we'll update the post's version of the single template. If you remember Hugo's rules, the template engine will use this version over the default. + +``` +$ vi themes/zafta/layouts/post/single.html +{{ partial "header.html" . }} + +

{{ .Title }}

+

{{ .Date.Format "Mon, Jan 2, 2006" }}

+ {{ .Content }} + +{{ partial "footer.html" . }} +:wq + +``` + +Note that we removed the date logic from the default template and put it in the post template. Generate the web site and verify the results. Posts have dates and the about page doesn't. + +### Don't Repeat Yourself + +DRY is a good design goal and Hugo does a great job supporting it. Part of the art of a good template is knowing when to add a new template and when to update an existing one. While you're figuring that out, accept that you'll be doing some refactoring. Hugo makes that easy and fast, so it's okay to delay splitting up a template. diff --git a/exampleSite/content/post/goisforlovers.md b/exampleSite/content/post/goisforlovers.md new file mode 100644 index 0000000..5e9f3e1 --- /dev/null +++ b/exampleSite/content/post/goisforlovers.md @@ -0,0 +1,332 @@ +--- +date: "2014-04-02" +tags: ["go", "templates", "hugo"] +title: "(Hu)go Template Primer" +--- + +Hugo uses the excellent [Go][] [html/template][gohtmltemplate] library for +its template engine. It is an extremely lightweight engine that provides a very +small amount of logic. In our experience that it is just the right amount of +logic to be able to create a good static website. If you have used other +template systems from different languages or frameworks you will find a lot of +similarities in Go templates. + +This document is a brief primer on using Go templates. The [Go docs][gohtmltemplate] +provide more details. + +## Introduction to Go Templates + +Go templates provide an extremely simple template language. It adheres to the +belief that only the most basic of logic belongs in the template or view layer. +One consequence of this simplicity is that Go templates parse very quickly. + +A unique characteristic of Go templates is they are content aware. Variables and +content will be sanitized depending on the context of where they are used. More +details can be found in the [Go docs][gohtmltemplate]. + +## Basic Syntax + +Golang templates are HTML files with the addition of variables and +functions. + +**Go variables and functions are accessible within {{ }}** + +Accessing a predefined variable "foo": + + {{ foo }} + +**Parameters are separated using spaces** + +Calling the add function with input of 1, 2: + + {{ add 1 2 }} + +**Methods and fields are accessed via dot notation** + +Accessing the Page Parameter "bar" + + {{ .Params.bar }} + +**Parentheses can be used to group items together** + + {{ if or (isset .Params "alt") (isset .Params "caption") }} Caption {{ end }} + + +## Variables + +Each Go template has a struct (object) made available to it. In hugo each +template is passed either a page or a node struct depending on which type of +page you are rendering. More details are available on the +[variables](/layout/variables) page. + +A variable is accessed by referencing the variable name. + + {{ .Title }} + +Variables can also be defined and referenced. + + {{ $address := "123 Main St."}} + {{ $address }} + + +## Functions + +Go template ship with a few functions which provide basic functionality. The Go +template system also provides a mechanism for applications to extend the +available functions with their own. [Hugo template +functions](/layout/functions) provide some additional functionality we believe +are useful for building websites. Functions are called by using their name +followed by the required parameters separated by spaces. Template +functions cannot be added without recompiling hugo. + +**Example:** + + {{ add 1 2 }} + +## Includes + +When including another template you will pass to it the data it will be +able to access. To pass along the current context please remember to +include a trailing dot. The templates location will always be starting at +the /layout/ directory within Hugo. + +**Example:** + + {{ template "chrome/header.html" . }} + + +## Logic + +Go templates provide the most basic iteration and conditional logic. + +### Iteration + +Just like in Go, the Go templates make heavy use of range to iterate over +a map, array or slice. The following are different examples of how to use +range. + +**Example 1: Using Context** + + {{ range array }} + {{ . }} + {{ end }} + +**Example 2: Declaring value variable name** + + {{range $element := array}} + {{ $element }} + {{ end }} + +**Example 2: Declaring key and value variable name** + + {{range $index, $element := array}} + {{ $index }} + {{ $element }} + {{ end }} + +### Conditionals + +If, else, with, or, & and provide the framework for handling conditional +logic in Go Templates. Like range, each statement is closed with `end`. + + +Go Templates treat the following values as false: + +* false +* 0 +* any array, slice, map, or string of length zero + +**Example 1: If** + + {{ if isset .Params "title" }}

{{ index .Params "title" }}

{{ end }} + +**Example 2: If -> Else** + + {{ if isset .Params "alt" }} + {{ index .Params "alt" }} + {{else}} + {{ index .Params "caption" }} + {{ end }} + +**Example 3: And & Or** + + {{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} + +**Example 4: With** + +An alternative way of writing "if" and then referencing the same value +is to use "with" instead. With rebinds the context `.` within its scope, +and skips the block if the variable is absent. + +The first example above could be simplified as: + + {{ with .Params.title }}

{{ . }}

{{ end }} + +**Example 5: If -> Else If** + + {{ if isset .Params "alt" }} + {{ index .Params "alt" }} + {{ else if isset .Params "caption" }} + {{ index .Params "caption" }} + {{ end }} + +## Pipes + +One of the most powerful components of Go templates is the ability to +stack actions one after another. This is done by using pipes. Borrowed +from unix pipes, the concept is simple, each pipeline's output becomes the +input of the following pipe. + +Because of the very simple syntax of Go templates, the pipe is essential +to being able to chain together function calls. One limitation of the +pipes is that they only can work with a single value and that value +becomes the last parameter of the next pipeline. + +A few simple examples should help convey how to use the pipe. + +**Example 1 :** + + {{ if eq 1 1 }} Same {{ end }} + +is the same as + + {{ eq 1 1 | if }} Same {{ end }} + +It does look odd to place the if at the end, but it does provide a good +illustration of how to use the pipes. + +**Example 2 :** + + {{ index .Params "disqus_url" | html }} + +Access the page parameter called "disqus_url" and escape the HTML. + +**Example 3 :** + + {{ if or (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} + Stuff Here + {{ end }} + +Could be rewritten as + + {{ isset .Params "caption" | or isset .Params "title" | or isset .Params "attr" | if }} + Stuff Here + {{ end }} + + +## Context (aka. the dot) + +The most easily overlooked concept to understand about Go templates is that {{ . }} +always refers to the current context. In the top level of your template this +will be the data set made available to it. Inside of a iteration it will have +the value of the current item. When inside of a loop the context has changed. . +will no longer refer to the data available to the entire page. If you need to +access this from within the loop you will likely want to set it to a variable +instead of depending on the context. + +**Example:** + + {{ $title := .Site.Title }} + {{ range .Params.tags }} +
  • {{ . }} - {{ $title }}
    • + {{ end }} + +Notice how once we have entered the loop the value of {{ . }} has changed. We +have defined a variable outside of the loop so we have access to it from within +the loop. + +# Hugo Parameters + +Hugo provides the option of passing values to the template language +through the site configuration (for sitewide values), or through the meta +data of each specific piece of content. You can define any values of any +type (supported by your front matter/config format) and use them however +you want to inside of your templates. + + +## Using Content (page) Parameters + +In each piece of content you can provide variables to be used by the +templates. This happens in the [front matter](/content/front-matter). + +An example of this is used in this documentation site. Most of the pages +benefit from having the table of contents provided. Sometimes the TOC just +doesn't make a lot of sense. We've defined a variable in our front matter +of some pages to turn off the TOC from being displayed. + +Here is the example front matter: + +``` +--- +title: "Permalinks" +date: "2013-11-18" +aliases: + - "/doc/permalinks/" +groups: ["extras"] +groups_weight: 30 +notoc: true +--- +``` + +Here is the corresponding code inside of the template: + + {{ if not .Params.notoc }} +
    + {{ .TableOfContents }} +
    + {{ end }} + + + +## Using Site (config) Parameters +In your top-level configuration file (eg, `config.yaml`) you can define site +parameters, which are values which will be available to you in chrome. + +For instance, you might declare: + +```yaml +params: + CopyrightHTML: "Copyright © 2013 John Doe. All Rights Reserved." + TwitterUser: "spf13" + SidebarRecentLimit: 5 +``` + +Within a footer layout, you might then declare a `