├── .coverage ├── .coveralls.yml ├── .flake8 ├── .gitignore ├── .travis.yml ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── Screen Shot 2019-05-08 at 23.26.45.png ├── docs ├── archetypes │ └── default.md ├── config.toml ├── content │ └── post │ │ ├── api-reference.md │ │ ├── command-line.md │ │ ├── getting-started.md │ │ ├── roadmap.md │ │ ├── styling.md │ │ ├── templates.md │ │ └── working-with-python.md ├── static │ ├── bacon-style-2.png │ └── bacon-style.png └── themes │ └── minimal │ ├── .gitignore │ ├── LICENSE.md │ ├── README.md │ ├── archetypes │ ├── default.md │ ├── post.md │ └── project.md │ ├── exampleSite │ ├── config.toml │ └── content │ │ ├── post │ │ ├── creating-a-new-theme.md │ │ ├── goisforlovers.md │ │ ├── hugoisforlovers.md │ │ └── migrate-from-jekyll.md │ │ └── project │ │ ├── project1.md │ │ ├── project2.md │ │ ├── project3.md │ │ └── project4.md │ ├── images │ ├── screenshot.png │ └── tn.png │ ├── layouts │ ├── 404.html │ ├── _default │ │ ├── list.html │ │ ├── single.html │ │ └── terms.html │ ├── index.html │ └── partials │ │ ├── body-open.html │ │ ├── css.html │ │ ├── footer.html │ │ ├── head-open.html │ │ ├── header.html │ │ ├── js.html │ │ ├── list-item.html │ │ └── paginator.html │ ├── static │ └── css │ │ └── main.css │ └── theme.toml ├── maildown ├── __init__.py ├── __pycache__ │ ├── __init__.cpython-37.pyc │ ├── application.cpython-37.pyc │ ├── commands.cpython-37.pyc │ ├── renderer.cpython-37.pyc │ └── utilities.cpython-37.pyc ├── application.py ├── backends │ ├── __init__.py │ ├── aws.py │ └── base.py ├── commands.py ├── my-style.css ├── renderer.py ├── style.css ├── template.jinja2 ├── test.html ├── test.md └── utilities.py ├── poetry.lock ├── pyproject.toml └── tests ├── __init__.py ├── test_application.py ├── test_commands.py ├── test_renderer.py └── test_utilities.py /.coverage: -------------------------------------------------------------------------------- 1 | !coverage.py: This is a private format, don't read it directly!{"lines":{"/Users/christopherdavies/maildown/maildown/__init__.py":[1,4,5],"/Users/christopherdavies/maildown/maildown/application.py":[1,2,4,6,7,8],"/Users/christopherdavies/maildown/maildown/commands.py":[1,2,5,8,16,18,36,43,45,67,80,82,19,20,26,27,28,29,30,32,33,21,22,23,46,47,48,53,55,57,58,61,62,49,50,51,83,84,89,91,92,94,95,96,97,99,100,101,105,109,116,117,118,119,120,121,122,124,125,127,128,106,107,102,103,110,111,112,114,85,86,87],"/Users/christopherdavies/maildown/maildown/backends/__init__.py":[1],"/Users/christopherdavies/maildown/maildown/backends/aws.py":[1,2,3,4,5,6,9,10,14,15,16,17,18,54,68,69,80,100,102,103,73,74,75,76,77,90,91,94,95,97,98,114,115,116,117,118,120,121,122,123,124,23,24,25,27,28,29,30,31,32,39,45,46,49,50,51,56,57,58,59,60,61,62,64],"/Users/christopherdavies/maildown/maildown/backends/base.py":[1,2,5,6,9,14,20,28,29,30,32,35,38,42,43,54,55,33,7,15,16,10,11,12,17,18,21,22,23,24,25,57,58,60,64,70,71,61,62,65,67],"/Users/christopherdavies/maildown/maildown/utilities.py":[1,2,3,4,7,19,11,12,13,14,15,16,28,29,30,31,32],"/Users/christopherdavies/maildown/maildown/renderer.py":[1,2,3,4,5,6,7,8,11,14,16,17,26,18,19,20,21,22,39,40,42,43,45,46,48,50,51,52,53,54,55,58,59]}} -------------------------------------------------------------------------------- /.coveralls.yml: -------------------------------------------------------------------------------- 1 | service_name: travis-ci 2 | repo_token: nVBf9o1MhMITdsZr7eMQdqr95bGMxO2bU 3 | -------------------------------------------------------------------------------- /.flake8: -------------------------------------------------------------------------------- 1 | [flake8] 2 | max-line-length = 120 -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | venv 2 | .idea 3 | __pycache__ 4 | maildown.egg-info 5 | .mypy_cache 6 | .pytest_cache 7 | dist 8 | .github -------------------------------------------------------------------------------- /.travis.yml: -------------------------------------------------------------------------------- 1 | language: python 2 | 3 | python: 4 | - "3.6" 5 | 6 | install: 7 | - curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python 8 | - source $HOME/.poetry/env 9 | - poetry install 10 | 11 | script: 12 | - mypy maildown --ignore-missing-imports 13 | - flake8 maildown 14 | - poetry run pytest tests --cov=maildown 15 | - coverage report --fail-under=95 16 | 17 | after_success: 18 | - pip install python-coveralls 19 | - coveralls 20 | 21 | before_deploy: 22 | - poetry config http-basic.pypi chris140957 $PYPI_PASSWORD 23 | 24 | deploy: 25 | - provider: script 26 | script: poetry publish --build 27 | on: 28 | tags: true 29 | branch: master -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at christopherdavies553@gmail.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2019 Christopher Davies 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [![Netlify Status](https://api.netlify.com/api/v1/badges/9d67273a-a51d-417b-bbad-291c237e5d8a/deploy-status)](https://app.netlify.com/sites/adoring-newton-752f36/deploys) 2 | ![MIT license](https://img.shields.io/github/license/chris104957/maildown.svg) 3 | [![Coverage Status](https://coveralls.io/repos/github/chris104957/maildown/badge.svg?branch=master)](https://coveralls.io/github/chris104957/maildown?branch=master) 4 | [![Build Status](https://travis-ci.org/chris104957/maildown.svg?branch=master)](https://travis-ci.org/chris104957/maildown) 5 | [![GitSpo Mentions](https://gitspo.com/badges/mentions/chris104957/maildown?style=flat-square)](https://gitspo.com/mentions/chris104957/maildown) 6 | 7 | # Maildown 8 | 9 | A super simple CLI for sending emails 10 | 11 | ## Introduction 12 | 13 | Maildown is a command line interface that lets you send emails using Amazon AWS SES with a minimum of fuss 14 | 15 | ### Why can't I just use `boto3`? 16 | 17 | Maildown makes it easier to add structure and style to your email content. It supports **Markdown syntax** out of the box, meaning that you can just send Markdown files as emails with no additional effort. 18 | 19 | ### How much does it cost? 20 | 21 | Maildown is open source and therefore completely free. It relies on Amazon SES, which *isn't* completely free, but it does let you send up to 62,000 free emails per month (*when sent from an EC2 instance*). So for the vast majority of people, Maildown costs nothing to run. 22 | 23 | ## Installation and usage 24 | 25 | ### Pre requisites 26 | 27 | In order to use Maildown, you first need to create an AWS free tier account [here](https://aws.amazon.com). Once you've signed up, you'll also realistically need to [take your AWS SES account out of the sandbox](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html) 28 | 29 | ### Install with `pip` 30 | 31 | You can install maildown as follows: 32 | ```bash 33 | pip install maildown 34 | ``` 35 | 36 | ### Authenticating Maildown 37 | 38 | Maildown stores your credentials locally for convenience. Before you can use Maildown's features, you should run the `maildown init` command 39 | 40 | ```bash 41 | maildown init AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY 42 | ``` 43 | 44 | > If you have previously used the `aws cli` and have already run `aws configure`, or if you have set the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` in your environment, you can just use `maildown init` with no arguments to store your credentials 45 | 46 | ### Verify email addresses 47 | 48 | Amazon only lets you send emails from verified email addresses - In other words, you need to verify that you own your email address before you can send mails from it. You can either do this from the [SES console](https://console.aws.amazon.com/ses/home), or by using Maildown: 49 | 50 | ```bash 51 | $ maildown verify christopherdavies553@gmail.com 52 | Email sent to christopherdavies553@gmail.com. You must click the link in this email to verify ownership before you can send any emails 53 | ``` 54 | 55 | When you use the above command, AWS will send an email to the email address you provided. You'll need to click on the link to verify your ownership of the account. Once you've done this, you can repeat the previous command to check the status 56 | 57 | ```bash 58 | $ maildown verify christopherdavies553@gmail.com 59 | This email address has already been verified 60 | ``` 61 | 62 | You are now ready to start sending emails! 63 | 64 | ## Sending emails 65 | 66 | You can now send emails with the following command 67 | ```bash 68 | maildown send christopherdavies553@gmail.com "my email subject" -f "email.md" recipient1@gmail.com recipient2@gmail.com 69 | ``` 70 | The above arguments, in order, are: 71 | - The sending email address (which must have been verified) 72 | - The subject line of your email 73 | - A markdown file containing some content to send. Note that you can also use the `-c` flag to pass string content to be sent directly to the email, e.g. `-c "hello"` 74 | - A list of email addresses to send the content to 75 | 76 | ## Contributing 77 | 78 | If you'd like to contribute to this codebase, the latest dev builds kept in a Private python package repository on [RepoForge.io](https://repoforge.io). Get in touch to request access to these 79 | 80 | ## Styling emails 81 | 82 | By default, Maildown bakes in its own default style sheet when sending emails. This looks something like this (the below email is the content of this readme): 83 | 84 | ![screenshot](https://raw.githubusercontent.com/chris104957/maildown/master/Screen%20Shot%202019-05-08%20at%2023.26.45.png) 85 | 86 | You can apply your own styles by simply using the `--theme` flag when sending mails, like this: 87 | 88 | ```bash 89 | maildown send christopherdavies553@gmail.com "my email subject" -f "email.md" --theme "my-style.css" recipient1@gmail.com recipient2@gmail.com 90 | ``` 91 | 92 | -------------------------------------------------------------------------------- /Screen Shot 2019-05-08 at 23.26.45.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chris104957/maildown/d22f7bf785d1c603fd45a6711518937a71b70b58/Screen Shot 2019-05-08 at 23.26.45.png -------------------------------------------------------------------------------- /docs/archetypes/default.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "{{ replace .Name "-" " " | title }}" 3 | date: {{ .Date }} 4 | draft: true 5 | --- 6 | 7 | -------------------------------------------------------------------------------- /docs/config.toml: -------------------------------------------------------------------------------- 1 | baseURL = "https://www.maildown.app/" 2 | languageCode = "en-us" 3 | title = "Maildown" 4 | theme = "minimal" 5 | googleAnalytics = "UA-108134557-2" 6 | 7 | [params] 8 | author = "Christopher Davies" 9 | description = "The fastest way to implement transactional emails in any project" 10 | githubUsername = "chris104957" 11 | accent = "green" 12 | showBorder = true 13 | backgroundColor = "white" 14 | font = "Raleway" # should match the name on Google Fonts! 15 | highlight = true 16 | highlightStyle = "solarized-dark" 17 | highlightLanguages = ["python", "haskell", "kotlin", "scala", "swift"] 18 | 19 | [[menu.main]] 20 | url = "/" 21 | name = "Home" 22 | weight = 1 23 | 24 | [[menu.main]] 25 | url = "/post/" 26 | name = "Docs" 27 | weight = 2 28 | 29 | # Social icons to be shown on the right-hand side of the navigation bar 30 | # The "name" field should match the name of the icon to be used 31 | # The list of available icons can be found at http://fontawesome.io/icons/ 32 | 33 | [[menu.icon]] 34 | url = "mailto:christopherdavies553@gmail.com" 35 | name = "envelope-o" 36 | weight = 1 37 | 38 | [[menu.icon]] 39 | url = "https://github.com/chris104957/maildown" 40 | name = "github" 41 | weight = 2 42 | 43 | [[menu.icon]] 44 | url = "https://twitter.com/christo22694524/" 45 | name = "twitter" 46 | weight = 3 47 | 48 | [[menu.icon]] 49 | url = "https://stackoverflow.com/users/8767828/christopher-davies" 50 | name = "stack-overflow" 51 | weight = 5 52 | -------------------------------------------------------------------------------- /docs/content/post/api-reference.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "API reference" 3 | description: "Python method documentation" 4 | draft: false 5 | --- 6 | 7 | # maildown.utilities 8 | 9 | ## get_client 10 | ```python 11 | get_client() -> 12 | ``` 13 | 14 | Returns an authenticated boto3.ses client 15 | 16 | ## verify_address 17 | ```python 18 | verify_address(email: str) -> bool 19 | ``` 20 | 21 | Asks Amazon to send an email to a given email address to verify the user's ownership of that address. 22 | 23 | Email addresses must be verified by Amazon before you can send emails from them with SES 24 | 25 | ### Parameters: 26 | 27 | - `email`: The email address to be verified 28 | 29 | ## verify_auth 30 | ```python 31 | verify_auth(access_key: str, secret_key: str, region_name: str = 'us-east-1') -> bool 32 | ``` 33 | 34 | Checks that the given credentials are valid by performing a simple call on the SES API 35 | 36 | ### Parameters: 37 | 38 | - `access_key`: AWS access key 39 | - `secret_key`: AWS secret key 40 | - `region_name`: The AWS region name. Defaults to `us-east-1` 41 | 42 | 43 | ## get_config 44 | ```python 45 | get_config() -> dict 46 | ``` 47 | 48 | Returns the existing configuration from the local environment 49 | 50 | ## write_config 51 | ```python 52 | write_config(**config: Dict[str, Union[str, SupportsFloat, bool]]) -> None 53 | ``` 54 | 55 | Updates the existing local config with the given additional arguments 56 | 57 | ### Parameters: 58 | 59 | - `config`: the new configuration items to add to the configuration 60 | 61 | 62 | ## login 63 | ```python 64 | login(access_key: Union[str, NoneType] = None, secret_key: Union[str, NoneType] = None, region_name: str = 'us-east-1', aws_config_file: str = '/Users/christopherdavies/.aws/credentials') -> None 65 | ``` 66 | 67 | Checks your AWS credentials are valid, and stores them locally if so for future re use. 68 | 69 | If you provide the access key/secret key arguments directly to this function, then these credentials will be taken 70 | in the first instance. 71 | 72 | If these arguments are NOT supplied, then this method will first check to see if the AWS_ACCESS_KEY_ID and 73 | AWS_SECRET_ACCESS_KEY environmental variables have been set. 74 | 75 | If not, this method will attempt to read the file kept at `aws_config_file`, which is the default location of 76 | the Amazon CLI config file. 77 | 78 | If this method cannot find credentials via any one of these methods, or if the credentials it does find are invalid, 79 | then an Exception is raised. 80 | 81 | However, if valid credentials can be found, these are stored locally 82 | 83 | ### Parameters: 84 | 85 | - `access_key`: AWS access key 86 | - `secret_key`: AWS secret key 87 | - `region_name`: The AWS region name. Defaults to `us-east-1` 88 | - `aws_config_file`: The location of the credentials file created by `aws configure` 89 | 90 | 91 | ## send_message 92 | ```python 93 | send_message(sender: str, subject: str, to: list, content: Union[str, NoneType] = None, file_path: Union[str, NoneType] = None, context: Union[dict, NoneType] = None, theme=None) 94 | ``` 95 | 96 | Sends an email to a given list of recipients 97 | 98 | ### Parameters: 99 | 100 | - `sender`: the email address to send the message from. Must have been verified by SES 101 | - `subject`: The subject line of the email 102 | - `to`: A list of email addresses to send the email to 103 | - `content`: The content of the email to send. Either this parameter, or `file_path`, must be supplied 104 | - `file_path`: A local file path to a file to be send as the email body 105 | - `context`: Additional context to be sent to the email - can be inserted using Jinja2 template syntax 106 | - `theme`: A local file path to a css style sheet. If not supplied, the default style is used 107 | 108 | -------------------------------------------------------------------------------- /docs/content/post/command-line.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Command line reference" 3 | description: "A list of commands and parameters" 4 | draft: false 5 | --- 6 | 7 | # Command line reference 8 | 9 | ## `maildown init` 10 | 11 | > Configures Maildown for use 12 | 13 | ```bash 14 | USAGE 15 | console init [] [] [] [] 16 | 17 | ARGUMENTS 18 | Your AWS Access Key ID 19 | Your AWS Secret key 20 | AWS region to use (defaults to "us-east-1") 21 | Path to your AWS config file (defaults to ~/.aws/credentials 22 | 23 | GLOBAL OPTIONS 24 | -h (--help) Display this help message 25 | -q (--quiet) Do not output any message 26 | -v (--verbose) Increase the verbosity of messages: "-v" for normal output, "-vv" for more verbose output and "-vvv" for debug 27 | -V (--version) Display this application version 28 | --ansi Force ANSI output 29 | --no-ansi Disable ANSI output 30 | -n (--no-interaction) Do not ask any interactive question 31 | 32 | ``` 33 | 34 | ## `maildown verify` 35 | 36 | > Verifies your ownership of an email address. Must be done prior to sending any messages 37 | 38 | ```bash 39 | USAGE 40 | console verify 41 | 42 | ARGUMENTS 43 | The email address that you want to verify 44 | 45 | GLOBAL OPTIONS 46 | -h (--help) Display this help message 47 | -q (--quiet) Do not output any message 48 | -v (--verbose) Increase the verbosity of messages: "-v" for normal output, "-vv" for more verbose output and "-vvv" for debug 49 | -V (--version) Display this application version 50 | --ansi Force ANSI output 51 | --no-ansi Disable ANSI output 52 | -n (--no-interaction) Do not ask any interactive question 53 | 54 | ``` 55 | 56 | ## `maildown send` 57 | 58 | > Send an email to a list of recipients 59 | 60 | ```bash 61 | USAGE 62 | console send [-c [<...>]] [-f [<...>]] [-t] [] ... [] 63 | 64 | ARGUMENTS 65 | The source email address (you must have verified ownership) 66 | The subject line of the email 67 | A list of email addresses to send the mail to 68 | 69 | OPTIONS 70 | -c (--content) The content of the email to send 71 | -f (--file-path) A path to a file containing content to send 72 | -t (--theme) A path to a css file to be applied to the email 73 | -e (--variable) Context variables to pass to the email, e.g. `-e name=Chris` (multiple values allowed) 74 | 75 | 76 | GLOBAL OPTIONS 77 | -h (--help) Display this help message 78 | -q (--quiet) Do not output any message 79 | -v (--verbose) Increase the verbosity of messages: "-v" for normal output, "-vv" for more verbose output and "-vvv" for debug 80 | -V (--version) Display this application version 81 | --ansi Force ANSI output 82 | --no-ansi Disable ANSI output 83 | -n (--no-interaction) Do not ask any interactive question 84 | 85 | ``` 86 | 87 | -------------------------------------------------------------------------------- /docs/content/post/getting-started.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Getting started with Maildown" 3 | description: "From installation to sending your first email" 4 | date: 2010-01-01 5 | draft: false 6 | --- 7 | 8 | ## Introduction 9 | 10 | Maildown is a command line interface that lets you send emails using 11 | Amazon AWS SES with a minimum of fuss. 12 | 13 | ### Why can't I just use `boto3`? 14 | 15 | Maildown makes it easier to add structure and style to your email 16 | content. It supports **Markdown syntax** out of the box, meaning that 17 | you can just send Markdown files as emails with no additional effort. 18 | 19 | ### How much does it cost? 20 | 21 | Maildown is open source and therefore completely free. It relies on 22 | Amazon SES, which *isn't* completely free, but it does let you send up 23 | to 62,000 free emails per month (*when sent from an EC2 instance*). So for vast majority of people, 24 | Maildown costs nothing to run. 25 | 26 | ## Installation and usage 27 | 28 | ### Pre requisites 29 | 30 | In order to use Maildown, you first need to create an AWS free tier 31 | account [here](https://aws.amazon.com). Once you've signed up, you'll 32 | also realistically need to [take your AWS SES account out of the sandbox](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html) 33 | 34 | ### Install with `pip` 35 | 36 | You can install maildown as follows: 37 | ```bash 38 | pip install maildown 39 | ``` 40 | 41 | ### Authenticating Maildown 42 | 43 | Maildown stores your credentials locally for convenience. Before you can 44 | use Maildown's features, you should run the `maildown init` command 45 | 46 | ```bash 47 | maildown init AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY 48 | ``` 49 | 50 | > If you have previously used the `aws cli` and have already run 51 | `aws configure`, or if you have set the environment variables 52 | `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` in your environment, 53 | you can just use `maildown init` with no arguments to store your 54 | credentials 55 | 56 | ### Verify email addresses 57 | 58 | Amazon only lets you send emails from verified email addresses - In 59 | other words, you need to verify that you own your email address before 60 | you can send mails from it. You can either do this from the 61 | [SES console](https://console.aws.amazon.com/ses/home), or by using 62 | Maildown: 63 | 64 | ```bash 65 | $ maildown verify christopherdavies553@gmail.com 66 | Email sent to christopherdavies553@gmail.com. You must click the link in this email to verify ownership before you can send any emails 67 | ``` 68 | 69 | When you use the above command, AWS will send an email to the email 70 | address you provided. You'll need to click on the link to verify your 71 | ownership of the account. Once you've done this, you can repeat the 72 | previous command to check the status 73 | 74 | ```bash 75 | $ maildown verify christopherdavies553@gmail.com 76 | This email address has already been verified 77 | ``` 78 | 79 | You are now ready to start sending emails! 80 | 81 | ## Sending emails 82 | 83 | You can now send emails with the following command 84 | ```bash 85 | maildown send christopherdavies553@gmail.com "my email subject" -f "email.md" recipient1@gmail.com recipient2@gmail.com 86 | ``` 87 | The above arguments, in order, are: 88 | 89 | - The sending email address (which must have been verified) 90 | - The subject line of your email 91 | - A markdown file containing some content to send. Note that you can 92 | also use the `-c` flag to pass string content to be sent directly to 93 | the email, e.g. `-c "hello"` 94 | - A list of email addresses to send the content to 95 | 96 | ### Adding context to your emails 97 | 98 | It's also possible to add context to your emails. For example, you can 99 | add syntax like this to your Markdown emails: 100 | ```markdown 101 | # Hello {{ name or "there" }} 102 | ``` 103 | 104 | You can then pass the `name` argument to your emails as follows: 105 | ```bash 106 | maildown send christopherdavies553@gmail.com "my email subject" -e name=Chris -f "email.md" recipient1@gmail.com 107 | ``` 108 | This will be rendered as `Hello Chris` when you send your email. If you 109 | do not provide this context, it will render as `Hello there`, as you 110 | set the default fallback value to `there` in this instance. 111 | 112 | To see the full set of what's possible in your Markdown emails, see 113 | [advanced template syntax](/posts/templates) 114 | 115 | ## Styling emails 116 | 117 | By default, Maildown bakes in its own default style sheet when sending 118 | emails. This looks something like this (the below email is the content 119 | of this project's Github readme): 120 | 121 | ![screenshot](https://raw.githubusercontent.com/chris104957/maildown/master/Screen%20Shot%202019-05-08%20at%2023.26.45.png) 122 | 123 | You can apply your own styles by simply using the `--theme` flag when 124 | sending mails, like this: 125 | 126 | ```bash 127 | maildown send christopherdavies553@gmail.com "my email subject" -f "email.md" --theme "my-style.css" recipient1@gmail.com recipient2@gmail.com 128 | ``` 129 | -------------------------------------------------------------------------------- /docs/content/post/roadmap.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Maildown Roadmap" 3 | description: "Coming to Maildown soon" 4 | draft: false 5 | --- 6 | 7 | # Roadmap 8 | 9 | Maildown is still new and we are adding more functionality all of the 10 | time. If you have anything else that you'd like to see added to this 11 | list, please [raise an issue in Github](https://github.com/chris104957/maildown/issues/new?assignees=&labels=&template=feature_request.md&title=) 12 | 13 | ## More email backends 14 | > [GitHub issue #7](https://github.com/chris104957/maildown/issues/7) 15 | 16 | At the moment, Maildown only works on top of Amazon SES. SES is the most 17 | cost-effective email backend available, allowing you to send 52,000 18 | emails per month while remaining in the AWS free tier. However, it comes 19 | with two primary disadvantages: 20 | 21 | - Even if you never plan on exceeding these limits, you still need to 22 | give Amazon your credit card details 23 | - The onboarding process for SES is somewhat lengthy. After going 24 | through the AWS account creation process and adding your billing 25 | details, you also need to verify your email addresses, then send a 26 | support request to Amazon to take your SES account out of the sandbox. 27 | 28 | There are a number of other email providers out there with less 29 | generous limits, but a slightly lower barrier to entry (i.e. just 30 | simple email ownership verification) and no need to enter any billing 31 | details if you don't plan on exceeding the free limits. Some examples: 32 | 33 | - Mailchimp 34 | - SendGrid 35 | - SendInBlue 36 | 37 | We'll be looking at adding support for these email providers in the near 38 | future -------------------------------------------------------------------------------- /docs/content/post/styling.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Styling emails in Maildown" 3 | description: "Learn how to change the default styles in your emails" 4 | draft: false 5 | --- 6 | 7 | ## Styling emails in Maildown 8 | 9 | By default, Maildown applies its own style sheet to all emails it sends. 10 | These style sheets get baked into the HTML at the moment the email is 11 | rendered. For example, this: 12 | 13 | ```css 14 | h1, h2, h3, h4, h5, h6 { 15 | font-weight: bold; 16 | } 17 | 18 | h1 { 19 | color: #000000; 20 | font-size: 28pt; 21 | } 22 | ``` 23 | 24 | Becomes this in the rendered email: 25 | 26 | ```html 27 |

Hello

28 | ``` 29 | 30 | Styles need to be converted to inline markup like this due to the way 31 | email works. You can see the whole default style sheet that gets 32 | applied by Maildown [here](https://github.com/chris104957/maildown/blob/master/maildown/style.css) 33 | 34 | ## Applying your own style sheets 35 | 36 | It is possible to specify your own style sheets in Maildown. Simply 37 | write your css to a file, like this: 38 | 39 | `my-style.css` 40 | 41 | ```css 42 | h1 { 43 | color: pink 44 | } 45 | ``` 46 | 47 | You can then call it like this: 48 | 49 | ```bash 50 | maildown send me@email.com "subject" -f "email.md" -t my-style.css somebody@email.com 51 | ``` 52 | This would produce a result like this: 53 | 54 | ![pink](/bacon-style.png) 55 | 56 | If you don't like the default style sheet, but don't want to make your 57 | own, then there are plenty of good style sheets designed specifically 58 | for markdown out there - like [this](https://github.com/jasonm23/markdown-css-themes) 59 | 60 | For example, theme 8 from the above repository looks like this when 61 | applied to our email: 62 | 63 | ![pink](/bacon-style-2.png) 64 | 65 | -------------------------------------------------------------------------------- /docs/content/post/templates.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Advanced template syntax" 3 | description: "See the full set of functionality available in your emails" 4 | draft: false 5 | --- 6 | 7 | # Advanced template syntax 8 | 9 | ## Introduction 10 | 11 | When generating your emails, Maildown actually renders the content 12 | twice - First, it inserts your markdown email content into a basic 13 | HTML template along with the selected (or default) css style sheet. 14 | The rendered template then has the css file *baked* into it - that's to 15 | say, the style sheet is removed totally, and instead every single 16 | HTML element is styled individually. This needs to happen as emails do 17 | not support styling in the same way as browser rendered web sites do. 18 | 19 | This rendered content then becomes a template itself - at this stage, 20 | anything passed to the email as the `context` parameter gets inserted 21 | into the template, producing the final email. This allows you to easily 22 | iterate through some data and send emails, like this: 23 | 24 | ```python 25 | from maildown import utilities as md 26 | people = [{'name': 'Chris'}, {'name': 'Steve'}] 27 | content = '# Hello, {{ name }}' 28 | for context in people: 29 | md.send_message(..., content=content, context=context) 30 | 31 | # Hello, Chris 32 | # Hello, Steve 33 | ``` 34 | 35 | Maildown uses `jinja2` to render emails. What this means is that 36 | Maildown supports both Markdown and Jinja2 syntax in emails - you can 37 | use Jinja2 to handle placeholders, conditional sections, and iteration 38 | - there are a few examples of this below 39 | 40 | ## Examples 41 | 42 | ### Conditionally including sections in your emails 43 | 44 | Email template: 45 | ```markdown 46 | # Everyone can see this message 47 | 48 | {% if include %} 49 | This is only visible if the `include` variable has been passed in 50 | the context 51 | {% endif %} 52 | ``` 53 | 54 | ### Simple placeholder insertion with default values 55 | 56 | ```markdown 57 | # Hello {{ name or "there" }} 58 | ``` 59 | 60 | ### Iterating through a list of items 61 | 62 | ```markdown 63 | ## Things 64 | Here are some things: 65 | {% for thing in things %} 66 | 67 | - {{ thing }} 68 | 69 | {% endfor %} 70 | ``` 71 | 72 | ### Applying filters 73 | 74 | ```markdown 75 | {% filter upper %} 76 | Everything here will become very shouty 77 | {% endfilter %} 78 | ``` 79 | 80 | 81 | 82 | 83 | -------------------------------------------------------------------------------- /docs/content/post/working-with-python.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Working with Python" 3 | description: "Implementing Maildown in your Python projects" 4 | date: 2009-01-01 5 | draft: false 6 | --- 7 | 8 | # Working with Python 9 | 10 | Maildown is designed to be used as a CLI tool. However, it is built 11 | entirely in Python, and its possible to easily integrate it with your 12 | Python projects too. 13 | 14 | ## Setting credentials 15 | 16 | When you first install Maildown, as explained in the 17 | [Getting started guide](/post/getting-started/), you'll need to run 18 | the `maildown init` command. This stores your AWS credentials to your 19 | local environment. Assuming you run the command in the same Python 20 | environment as your project, this will also set your configuration 21 | for the Python library too. Alternatively, you can use the Python 22 | library to store your AWS credentials as follows: 23 | 24 | ```python 25 | from maildown import utilities as md 26 | 27 | md.login('aws_access_key','aws_secret_key') 28 | ``` 29 | 30 | ## Verifying email addresses 31 | 32 | You can ask Maildown to send a verification email to a new email 33 | address as follows: 34 | 35 | ```python 36 | from maildown import utilities as md 37 | 38 | md.verify_address("me@email.com") 39 | ``` 40 | 41 | The above command sends an email to `me@email.com`. As with the CLI, 42 | clicking on the email in this link verifies your ownership of that 43 | address, and allows you to send emails from it. 44 | 45 | ## Sending emails 46 | 47 | As in the CLI equivalent, the `send_message` method allows you to supply 48 | either a file path, or string content as the email body 49 | 50 | ```python 51 | from maildown import utilities as md 52 | 53 | md.send_message( 54 | sender='me@email.com', 55 | subject='Hello', 56 | to=['somebody@example.com', 'somebody.else@example.com'], 57 | file_path='my-email.md', 58 | context=dict(name='Chris') 59 | ) 60 | ``` -------------------------------------------------------------------------------- /docs/static/bacon-style-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chris104957/maildown/d22f7bf785d1c603fd45a6711518937a71b70b58/docs/static/bacon-style-2.png -------------------------------------------------------------------------------- /docs/static/bacon-style.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/chris104957/maildown/d22f7bf785d1c603fd45a6711518937a71b70b58/docs/static/bacon-style.png -------------------------------------------------------------------------------- /docs/themes/minimal/.gitignore: -------------------------------------------------------------------------------- 1 | /.vscode 2 | -------------------------------------------------------------------------------- /docs/themes/minimal/LICENSE.md: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2017 Calin Tataru 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 21 | -------------------------------------------------------------------------------- /docs/themes/minimal/README.md: -------------------------------------------------------------------------------- 1 | # Minimal 2 | 3 | Personal blog theme powered by [Hugo](https://gohugo.io). 4 | A live demo is available [here](https://themes.gohugo.io/theme/minimal/). 5 | 6 | ## Installation 7 | 8 | You can install the theme either as a clone or submodule. 9 | 10 | I recommend the latter. From the root of your Hugo site, type the following: 11 | 12 | ``` 13 | $ git submodule add https://github.com/calintat/minimal.git themes/minimal 14 | $ git submodule init 15 | $ git submodule update 16 | ``` 17 | 18 | Now you can get updates to Minimal in the future by updating the submodule: 19 | 20 | ``` 21 | $ git submodule update --remote themes/minimal 22 | ``` 23 | 24 | ## Configuration 25 | 26 | After installation, take a look at the `exampleSite` folder inside `themes/minimal`. 27 | 28 | To get started, copy the `config.toml` file inside `exampleSite` to the root of your Hugo site: 29 | 30 | ``` 31 | $ cp themes/minimal/exampleSite/config.toml . 32 | ``` 33 | 34 | Now edit this file and add your own information. Note that some fields can be omitted. 35 | 36 | I recommend you use the theme's archetypes so now delete your site's `archetypes/default.md`. 37 | 38 | ## Features 39 | 40 | You can tweak the look of the theme to suit your needs in a number of ways: 41 | 42 | - The accent colour can be changed by using the `accent` field in `config.toml`. 43 | 44 | - You can also change the background colour by using `backgroundColor`. 45 | 46 | - Add colored 5px borders at the top and bottom of pages by setting `showBorder` to `true`. 47 | 48 | For best results, I recommend you use a dark accent colour with a light background, for example: 49 | 50 | ```toml 51 | [params] 52 | accent = "red" 53 | showBorder = true 54 | backgroundColor = "white" 55 | ``` 56 | 57 | ### Fonts 58 | 59 | The theme uses [Google Fonts](https://fonts.google.com) to load its font. To change the font: 60 | 61 | ```toml 62 | [params] 63 | font = "Raleway" # should match the name on Google Fonts! 64 | ``` 65 | 66 | ### Syntax highlighting 67 | 68 | The theme supports syntax highlighting thanks to [highlight.js](https://highlightjs.org). 69 | 70 | It's disabled by default, so you have to enable it by setting `highlight` to `true` in your config. 71 | 72 | You can change the style used for the highlighting by using the `highlightStyle` field. 73 | 74 | Only the "common" languages will be loaded by default. To load more, use `highlightLanguages`. 75 | 76 | A list of all the available styles and languages can be found [here](https://highlightjs.org/static/demo/). 77 | 78 | Please note the style and languages should be written in hyphen-separated lowercase, for example: 79 | 80 | ```toml 81 | [params] 82 | highlight = true 83 | highlightStyle = "solarized-dark" 84 | highlightLanguages = ["go", "haskell", "kotlin", "scala", "swift"] 85 | ``` 86 | -------------------------------------------------------------------------------- /docs/themes/minimal/archetypes/default.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "{{ replace .TranslationBaseName "-" " " | title }}" 3 | date: {{ dateFormat "2006-01-02" .Date }} 4 | draft: true 5 | --- 6 | -------------------------------------------------------------------------------- /docs/themes/minimal/archetypes/post.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "{{ replace .TranslationBaseName "-" " " | title }}" 3 | date: {{ dateFormat "2006-01-02" .Date }} 4 | tags: [] 5 | draft: true 6 | --- 7 | -------------------------------------------------------------------------------- /docs/themes/minimal/archetypes/project.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "{{ replace .TranslationBaseName "-" " " | title }}" 3 | description: "" 4 | repo: "" 5 | tags: [] 6 | weight: 0 7 | draft: true 8 | --- 9 | -------------------------------------------------------------------------------- /docs/themes/minimal/exampleSite/config.toml: -------------------------------------------------------------------------------- 1 | baseURL = "http://example.com/" 2 | languageCode = "en-us" 3 | title = "Minimal" 4 | theme = "minimal" 5 | disqusShortname = "username" # delete this to disable disqus comments 6 | googleAnalytics = "" 7 | 8 | [params] 9 | author = "Calin Tataru" 10 | description = "Personal blog theme powered by Hugo" 11 | githubUsername = "#" 12 | accent = "red" 13 | showBorder = true 14 | backgroundColor = "white" 15 | font = "Raleway" # should match the name on Google Fonts! 16 | highlight = true 17 | highlightStyle = "solarized-dark" 18 | highlightLanguages = ["go", "haskell", "kotlin", "scala", "swift"] 19 | 20 | [[menu.main]] 21 | url = "/" 22 | name = "Home" 23 | weight = 1 24 | 25 | [[menu.main]] 26 | url = "/post/" 27 | name = "Posts" 28 | weight = 2 29 | 30 | [[menu.main]] 31 | url = "/project/" 32 | name = "Projects" 33 | weight = 3 34 | 35 | # Social icons to be shown on the right-hand side of the navigation bar 36 | # The "name" field should match the name of the icon to be used 37 | # The list of available icons can be found at http://fontawesome.io/icons/ 38 | 39 | [[menu.icon]] 40 | url = "mailto:me@example.com" 41 | name = "envelope-o" 42 | weight = 1 43 | 44 | [[menu.icon]] 45 | url = "https://github.com/username/" 46 | name = "github" 47 | weight = 2 48 | 49 | [[menu.icon]] 50 | url = "https://twitter.com/username/" 51 | name = "twitter" 52 | weight = 3 53 | 54 | [[menu.icon]] 55 | url = "https://www.linkedin.com/in/username/" 56 | name = "linkedin" 57 | weight = 4 58 | 59 | [[menu.icon]] 60 | url = "https://www.stackoverflow.com/username/" 61 | name = "stack-overflow" 62 | weight = 5 63 | -------------------------------------------------------------------------------- /docs/themes/minimal/exampleSite/content/post/creating-a-new-theme.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "Creating a New Theme" 3 | date: 2014-09-28 4 | tags: ["go", "golang", "hugo", "themes"] 5 | draft: false 6 | --- 7 | 8 | ## Introduction 9 | 10 | 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. 11 | 12 | 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. 13 | 14 | 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. 15 | 16 | Here's an example: 17 | 18 | ``` 19 | ## this is a comment 20 | $ echo this is a command 21 | this is a command 22 | 23 | ## edit the file 24 | $vi foo.md 25 | +++ 26 | date = "2014-09-28" 27 | title = "creating a new theme" 28 | +++ 29 | 30 | bah and humbug 31 | :wq 32 | 33 | ## show it 34 | $ cat foo.md 35 | +++ 36 | date = "2014-09-28" 37 | title = "creating a new theme" 38 | +++ 39 | 40 | bah and humbug 41 | $ 42 | ``` 43 | 44 | 45 | ## Some Definitions 46 | 47 | There are a few concepts that you need to understand before creating a theme. 48 | 49 | ### Skins 50 | 51 | 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. 52 | 53 | 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. 54 | 55 | 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? 56 | 57 | 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. 58 | 59 | The rest of this tutorial will call a skin created in the ```themes/``` directory a theme. 60 | 61 | 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. 62 | 63 | ### The Home Page 64 | 65 | 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. 66 | 67 | ### Site Configuration File 68 | 69 | 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. 70 | 71 | 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. 72 | 73 | ### Content 74 | 75 | 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. 76 | 77 | #### Front Matter 78 | 79 | 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. 80 | 81 | The information in the front matter is passed into the template before the content is rendered into HTML. 82 | 83 | #### Markdown 84 | 85 | 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. 86 | 87 | ### Template Files 88 | 89 | 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. 90 | 91 | 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. 92 | 93 | 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. 94 | 95 | Please note that you can use the front matter to influence Hugo’s choice of templates. 96 | 97 | #### Single Template 98 | 99 | 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. 100 | 101 | #### List Template 102 | 103 | 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. 104 | 105 | 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. 106 | 107 | #### Partial Template 108 | 109 | 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. 110 | 111 | ## Create a New Site 112 | 113 | 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. 114 | 115 | The "new site" command will create a skeleton of a site. It will give you the basic directory structure and a useable configuration file. 116 | 117 | ``` 118 | $ hugo new site ~/Sites/zafta 119 | $ cd ~/Sites/zafta 120 | $ ls -l 121 | total 8 122 | drwxr-xr-x 7 quoha staff 238 Sep 29 16:49 . 123 | drwxr-xr-x 3 quoha staff 102 Sep 29 16:49 .. 124 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes 125 | -rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml 126 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content 127 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts 128 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static 129 | $ 130 | ``` 131 | 132 | Take a look in the content/ directory to confirm that it is empty. 133 | 134 | 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. 135 | 136 | ### Generate the HTML For the New Site 137 | 138 | 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. 139 | 140 | ``` 141 | $ hugo --verbose 142 | INFO: 2014/09/29 Using config file: config.toml 143 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 144 | WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] 145 | WARN: 2014/09/29 Unable to locate layout: [404.html] 146 | 0 draft content 147 | 0 future content 148 | 0 pages created 149 | 0 tags created 150 | 0 categories created 151 | in 2 ms 152 | $ 153 | ``` 154 | 155 | 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. 156 | 157 | We can verify that the command worked by looking at the directory again. 158 | 159 | ``` 160 | $ ls -l 161 | total 8 162 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes 163 | -rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml 164 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content 165 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts 166 | drwxr-xr-x 4 quoha staff 136 Sep 29 17:02 public 167 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static 168 | $ 169 | ``` 170 | 171 | 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. 172 | 173 | ``` 174 | $ ls -l public 175 | total 16 176 | -rw-r--r-- 1 quoha staff 416 Sep 29 17:02 index.xml 177 | -rw-r--r-- 1 quoha staff 262 Sep 29 17:02 sitemap.xml 178 | $ 179 | ``` 180 | 181 | Hugo created two XML files, which is standard, but there are no HTML files. 182 | 183 | 184 | 185 | ### Test the New Site 186 | 187 | 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: 188 | 189 | ``` 190 | $ hugo server --verbose 191 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 192 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 193 | WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] 194 | WARN: 2014/09/29 Unable to locate layout: [404.html] 195 | 0 draft content 196 | 0 future content 197 | 0 pages created 198 | 0 tags created 199 | 0 categories created 200 | in 2 ms 201 | Serving pages from /Users/quoha/Sites/zafta/public 202 | Web Server is available at http://localhost:1313 203 | Press Ctrl+C to stop 204 | ``` 205 | 206 | 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: 207 | 208 | ``` 209 | index.xml 210 | sitemap.xml 211 | ``` 212 | 213 | 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. 214 | 215 | Let’s go back and look at those warnings again. 216 | 217 | ``` 218 | WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] 219 | WARN: 2014/09/29 Unable to locate layout: [404.html] 220 | ``` 221 | 222 | 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. 223 | 224 | 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. 225 | 226 | 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. 227 | 228 | 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. 229 | 230 | ## Create a New Theme 231 | 232 | 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. 233 | 234 | 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. 235 | 236 | 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. 237 | 238 | 239 | ### Create a Skeleton 240 | 241 | 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. 242 | 243 | ``` 244 | $ hugo new theme zafta 245 | 246 | $ ls -l 247 | total 8 248 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 archetypes 249 | -rw-r--r-- 1 quoha staff 82 Sep 29 16:49 config.toml 250 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 content 251 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 layouts 252 | drwxr-xr-x 4 quoha staff 136 Sep 29 17:02 public 253 | drwxr-xr-x 2 quoha staff 68 Sep 29 16:49 static 254 | drwxr-xr-x 3 quoha staff 102 Sep 29 17:31 themes 255 | 256 | $ find themes -type f | xargs ls -l 257 | -rw-r--r-- 1 quoha staff 1081 Sep 29 17:31 themes/zafta/LICENSE.md 258 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/archetypes/default.md 259 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html 260 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/single.html 261 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/index.html 262 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/footer.html 263 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/header.html 264 | -rw-r--r-- 1 quoha staff 93 Sep 29 17:31 themes/zafta/theme.toml 265 | $ 266 | ``` 267 | 268 | The skeleton includes templates (the files ending in .html), license file, a description of your theme (the theme.toml file), and an empty archetype. 269 | 270 | 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. 271 | 272 | ``` 273 | $ vi themes/zafta/theme.toml 274 | author = "michael d henderson" 275 | description = "a minimal working template" 276 | license = "MIT" 277 | name = "zafta" 278 | source_repo = "" 279 | tags = ["tags", "categories"] 280 | :wq 281 | 282 | ## also edit themes/zafta/LICENSE.md and change 283 | ## the bit that says "YOUR_NAME_HERE" 284 | ``` 285 | 286 | Note that the the skeleton's template files are empty. Don't worry, we'll be changing that shortly. 287 | 288 | ``` 289 | $ find themes/zafta -name '*.html' | xargs ls -l 290 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html 291 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/single.html 292 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/index.html 293 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/footer.html 294 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/partials/header.html 295 | $ 296 | ``` 297 | 298 | 299 | 300 | ### Update the Configuration File to Use the Theme 301 | 302 | 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. 303 | 304 | 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. 305 | 306 | ``` 307 | $ vi config.toml 308 | theme = "zafta" 309 | baseurl = "" 310 | languageCode = "en-us" 311 | title = "zafta - totally refreshing" 312 | MetaDataFormat = "toml" 313 | :wq 314 | 315 | $ 316 | ``` 317 | 318 | ### Generate the Site 319 | 320 | Now that we have an empty theme, let's generate the site again. 321 | 322 | ``` 323 | $ hugo --verbose 324 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 325 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 326 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 327 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 328 | 0 draft content 329 | 0 future content 330 | 0 pages created 331 | 0 tags created 332 | 0 categories created 333 | in 2 ms 334 | $ 335 | ``` 336 | 337 | 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. 338 | 339 | Let's check the public/ directory to see what Hugo's created. 340 | 341 | ``` 342 | $ ls -l public 343 | total 16 344 | drwxr-xr-x 2 quoha staff 68 Sep 29 17:56 css 345 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:56 index.html 346 | -rw-r--r-- 1 quoha staff 407 Sep 29 17:56 index.xml 347 | drwxr-xr-x 2 quoha staff 68 Sep 29 17:56 js 348 | -rw-r--r-- 1 quoha staff 243 Sep 29 17:56 sitemap.xml 349 | $ 350 | ``` 351 | 352 | Notice four things: 353 | 354 | 1. Hugo created a home page. This is the file public/index.html. 355 | 2. Hugo created a css/ directory. 356 | 3. Hugo created a js/ directory. 357 | 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. 358 | 359 | #### The Home Page 360 | 361 | 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: 362 | 363 | ``` 364 | WARN: 2014/09/29 Unable to locate layout: [index.html _default/list.html _default/single.html] 365 | ``` 366 | 367 | 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. 368 | 369 | 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. 370 | 371 | ``` 372 | $ find . -name index.html | xargs ls -l 373 | -rw-r--r-- 1 quoha staff 0 Sep 29 20:21 ./public/index.html 374 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 ./themes/zafta/layouts/index.html 375 | $ 376 | ``` 377 | 378 | #### The Magic of Static 379 | 380 | 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. 381 | 382 | 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. 383 | 384 | ``` 385 | $ find themes/zafta -type d | xargs ls -ld 386 | drwxr-xr-x 7 quoha staff 238 Sep 29 17:38 themes/zafta 387 | drwxr-xr-x 3 quoha staff 102 Sep 29 17:31 themes/zafta/archetypes 388 | drwxr-xr-x 5 quoha staff 170 Sep 29 17:31 themes/zafta/layouts 389 | drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/layouts/_default 390 | drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/layouts/partials 391 | drwxr-xr-x 4 quoha staff 136 Sep 29 17:31 themes/zafta/static 392 | drwxr-xr-x 2 quoha staff 68 Sep 29 17:31 themes/zafta/static/css 393 | drwxr-xr-x 2 quoha staff 68 Sep 29 17:31 themes/zafta/static/js 394 | $ 395 | ``` 396 | 397 | ## The Theme Development Cycle 398 | 399 | 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: 400 | 401 | 1. Purge the public/ directory. 402 | 2. Run the built in web server in watch mode. 403 | 3. Open your site in a browser. 404 | 4. Update the theme. 405 | 5. Glance at your browser window to see changes. 406 | 6. Return to step 4. 407 | 408 | 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. 409 | 410 | Check the main Hugo site for information on using Git with Hugo. 411 | 412 | ### Purge the public/ Directory 413 | 414 | 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. 415 | 416 | Note: If you're building on an SSD, you should ignore this. Churning on a SSD can be costly. 417 | 418 | ### Hugo's Watch Option 419 | 420 | Hugo's "`--watch`" option will monitor the content/ and your theme directories for changes and rebuild the site automatically. 421 | 422 | ### Live Reload 423 | 424 | 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." 425 | 426 | ### Development Commands 427 | 428 | Use the following commands as the basis for your workflow. 429 | 430 | ``` 431 | ## purge old files. hugo will recreate the public directory. 432 | ## 433 | $ rm -rf public 434 | ## 435 | ## run hugo in watch mode 436 | ## 437 | $ hugo server --watch --verbose 438 | ``` 439 | 440 | 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. 441 | 442 | 443 | ``` 444 | $ rm -rf public 445 | $ hugo server --watch --verbose 446 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 447 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 448 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 449 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 450 | 0 draft content 451 | 0 future content 452 | 0 pages created 453 | 0 tags created 454 | 0 categories created 455 | in 2 ms 456 | Watching for changes in /Users/quoha/Sites/zafta/content 457 | Serving pages from /Users/quoha/Sites/zafta/public 458 | Web Server is available at http://localhost:1313 459 | Press Ctrl+C to stop 460 | INFO: 2014/09/29 File System Event: ["/Users/quoha/Sites/zafta/themes/zafta/layouts/index.html": MODIFY|ATTRIB] 461 | Change detected, rebuilding site 462 | 463 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 464 | 0 draft content 465 | 0 future content 466 | 0 pages created 467 | 0 tags created 468 | 0 categories created 469 | in 1 ms 470 | ``` 471 | 472 | ## Update the Home Page Template 473 | 474 | 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: 475 | 476 | 1. index.html 477 | 2. _default/list.html 478 | 3. _default/single.html 479 | 480 | 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. 481 | 482 | ### Make a Static Home Page 483 | 484 | 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. 485 | 486 | ``` 487 | $ vi themes/zafta/layouts/index.html 488 | 489 | 490 | 491 |

hugo says hello!

492 | 493 | 494 | :wq 495 | 496 | $ 497 | ``` 498 | 499 | Build the web site and then verify the results. 500 | 501 | ``` 502 | $ hugo --verbose 503 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 504 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 505 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 506 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 507 | 0 draft content 508 | 0 future content 509 | 0 pages created 510 | 0 tags created 511 | 0 categories created 512 | in 2 ms 513 | 514 | $ find public -type f -name '*.html' | xargs ls -l 515 | -rw-r--r-- 1 quoha staff 78 Sep 29 21:26 public/index.html 516 | 517 | $ cat public/index.html 518 | 519 | 520 | 521 |

hugo says hello!

522 | 523 | ``` 524 | 525 | #### Live Reload 526 | 527 | Note: If you're running the server with the `--watch` option, you'll see different content in the file: 528 | 529 | ``` 530 | $ cat public/index.html 531 | 532 | 533 | 534 |

hugo says hello!

535 | 539 | 540 | ``` 541 | 542 | 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. 543 | 544 | ### Build a "Dynamic" Home Page 545 | 546 | "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. 547 | 548 | #### Create New Posts 549 | 550 | 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. 551 | 552 | Hugo has a command to generate a skeleton post, just like it does for sites and themes. 553 | 554 | ``` 555 | $ hugo --verbose new post/first.md 556 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 557 | INFO: 2014/09/29 attempting to create post/first.md of post 558 | INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/default.md 559 | ERROR: 2014/09/29 Unable to Cast to map[string]interface{} 560 | 561 | $ 562 | ``` 563 | 564 | That wasn't very nice, was it? 565 | 566 | 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. 567 | 568 | ``` 569 | $ vi themes/zafta/archetypes/post.md 570 | +++ 571 | Description = "" 572 | Tags = [] 573 | Categories = [] 574 | +++ 575 | :wq 576 | 577 | $ find themes/zafta/archetypes -type f | xargs ls -l 578 | -rw-r--r-- 1 quoha staff 0 Sep 29 21:53 themes/zafta/archetypes/default.md 579 | -rw-r--r-- 1 quoha staff 51 Sep 29 21:54 themes/zafta/archetypes/post.md 580 | 581 | $ hugo --verbose new post/first.md 582 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 583 | INFO: 2014/09/29 attempting to create post/first.md of post 584 | INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/post.md 585 | INFO: 2014/09/29 creating /Users/quoha/Sites/zafta/content/post/first.md 586 | /Users/quoha/Sites/zafta/content/post/first.md created 587 | 588 | $ hugo --verbose new post/second.md 589 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 590 | INFO: 2014/09/29 attempting to create post/second.md of post 591 | INFO: 2014/09/29 curpath: /Users/quoha/Sites/zafta/themes/zafta/archetypes/post.md 592 | INFO: 2014/09/29 creating /Users/quoha/Sites/zafta/content/post/second.md 593 | /Users/quoha/Sites/zafta/content/post/second.md created 594 | 595 | $ ls -l content/post 596 | total 16 597 | -rw-r--r-- 1 quoha staff 104 Sep 29 21:54 first.md 598 | -rw-r--r-- 1 quoha staff 105 Sep 29 21:57 second.md 599 | 600 | $ cat content/post/first.md 601 | +++ 602 | Categories = [] 603 | Description = "" 604 | Tags = [] 605 | date = "2014-09-29T21:54:53-05:00" 606 | title = "first" 607 | 608 | +++ 609 | my first post 610 | 611 | $ cat content/post/second.md 612 | +++ 613 | Categories = [] 614 | Description = "" 615 | Tags = [] 616 | date = "2014-09-29T21:57:09-05:00" 617 | title = "second" 618 | 619 | +++ 620 | my second post 621 | 622 | $ 623 | ``` 624 | 625 | Build the web site and then verify the results. 626 | 627 | ``` 628 | $ rm -rf public 629 | $ hugo --verbose 630 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 631 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 632 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 633 | INFO: 2014/09/29 found taxonomies: map[string]string{"category":"categories", "tag":"tags"} 634 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 635 | 0 draft content 636 | 0 future content 637 | 2 pages created 638 | 0 tags created 639 | 0 categories created 640 | in 4 ms 641 | $ 642 | ``` 643 | 644 | The output says that it created 2 pages. Those are our new posts: 645 | 646 | ``` 647 | $ find public -type f -name '*.html' | xargs ls -l 648 | -rw-r--r-- 1 quoha staff 78 Sep 29 22:13 public/index.html 649 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/first/index.html 650 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/index.html 651 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:13 public/post/second/index.html 652 | $ 653 | ``` 654 | 655 | 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. 656 | 657 | ### List and Single Templates 658 | 659 | 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. 660 | 661 | Generally speaking, list templates are named "list.html" and single templates are named "single.html." 662 | 663 | There are three other types of templates: partials, content views, and terms. We will not go into much detail on these. 664 | 665 | ### Add Content to the Homepage 666 | 667 | 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. 668 | 669 | ``` 670 | $ vi themes/zafta/layouts/index.html 671 | 672 | 673 | 674 | {{ range first 10 .Data.Pages }} 675 |

{{ .Title }}

676 | {{ end }} 677 | 678 | 679 | :wq 680 | 681 | $ 682 | ``` 683 | 684 | 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: 685 | 686 | 1. range 687 | 2. .Title 688 | 3. end 689 | 690 | 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. 691 | 692 | The ".Title" command prints the value of the "title" variable. Hugo pulls it from the front matter in the Markdown file. 693 | 694 | 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. 695 | 696 | 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. 697 | 698 | Build the web site and then verify the results. 699 | 700 | ``` 701 | $ rm -rf public 702 | $ hugo --verbose 703 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 704 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 705 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 706 | INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} 707 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 708 | 0 draft content 709 | 0 future content 710 | 2 pages created 711 | 0 tags created 712 | 0 categories created 713 | in 4 ms 714 | $ find public -type f -name '*.html' | xargs ls -l 715 | -rw-r--r-- 1 quoha staff 94 Sep 29 22:23 public/index.html 716 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/first/index.html 717 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/index.html 718 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:23 public/post/second/index.html 719 | $ cat public/index.html 720 | 721 | 722 | 723 | 724 |

second

725 | 726 |

first

727 | 728 | 729 | 730 | $ 731 | ``` 732 | 733 | 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. 734 | 735 | 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. 736 | 737 | ### Add Content to the Posts 738 | 739 | 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"). 740 | 741 | 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. 742 | 743 | Now that we know the search rule, let's see what we actually have available: 744 | 745 | ``` 746 | $ find themes/zafta -name single.html | xargs ls -l 747 | -rw-r--r-- 1 quoha staff 132 Sep 29 17:31 themes/zafta/layouts/_default/single.html 748 | ``` 749 | 750 | 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. 751 | 752 | 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. 753 | 754 | 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. 755 | 756 | #### Update the Template File 757 | 758 | ``` 759 | $ vi themes/zafta/layouts/_default/single.html 760 | 761 | 762 | 763 | {{ .Title }} 764 | 765 | 766 |

{{ .Title }}

767 | {{ .Content }} 768 | 769 | 770 | :wq 771 | 772 | $ 773 | ``` 774 | 775 | Build the web site and verify the results. 776 | 777 | ``` 778 | $ rm -rf public 779 | $ hugo --verbose 780 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 781 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 782 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 783 | INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} 784 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 785 | 0 draft content 786 | 0 future content 787 | 2 pages created 788 | 0 tags created 789 | 0 categories created 790 | in 4 ms 791 | 792 | $ find public -type f -name '*.html' | xargs ls -l 793 | -rw-r--r-- 1 quoha staff 94 Sep 29 22:40 public/index.html 794 | -rw-r--r-- 1 quoha staff 125 Sep 29 22:40 public/post/first/index.html 795 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:40 public/post/index.html 796 | -rw-r--r-- 1 quoha staff 128 Sep 29 22:40 public/post/second/index.html 797 | 798 | $ cat public/post/first/index.html 799 | 800 | 801 | 802 | first 803 | 804 | 805 |

first

806 |

my first post

807 | 808 | 809 | 810 | 811 | $ cat public/post/second/index.html 812 | 813 | 814 | 815 | second 816 | 817 | 818 |

second

819 |

my second post

820 | 821 | 822 | 823 | $ 824 | ``` 825 | 826 | Notice that the posts now have content. You can go to localhost:1313/post/first to verify. 827 | 828 | ### Linking to Content 829 | 830 | 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. 831 | 832 | ``` 833 | $ vi themes/zafta/layouts/index.html 834 | 835 | 836 | 837 | {{ range first 10 .Data.Pages }} 838 |

{{ .Title }}

839 | {{ end }} 840 | 841 | 842 | ``` 843 | 844 | Build the web site and verify the results. 845 | 846 | ``` 847 | $ rm -rf public 848 | $ hugo --verbose 849 | INFO: 2014/09/29 Using config file: /Users/quoha/Sites/zafta/config.toml 850 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/themes/zafta/static/ to /Users/quoha/Sites/zafta/public/ 851 | INFO: 2014/09/29 syncing from /Users/quoha/Sites/zafta/static/ to /Users/quoha/Sites/zafta/public/ 852 | INFO: 2014/09/29 found taxonomies: map[string]string{"tag":"tags", "category":"categories"} 853 | WARN: 2014/09/29 Unable to locate layout: [404.html theme/404.html] 854 | 0 draft content 855 | 0 future content 856 | 2 pages created 857 | 0 tags created 858 | 0 categories created 859 | in 4 ms 860 | 861 | $ find public -type f -name '*.html' | xargs ls -l 862 | -rw-r--r-- 1 quoha staff 149 Sep 29 22:44 public/index.html 863 | -rw-r--r-- 1 quoha staff 125 Sep 29 22:44 public/post/first/index.html 864 | -rw-r--r-- 1 quoha staff 0 Sep 29 22:44 public/post/index.html 865 | -rw-r--r-- 1 quoha staff 128 Sep 29 22:44 public/post/second/index.html 866 | 867 | $ cat public/index.html 868 | 869 | 870 | 871 | 872 |

second

873 | 874 |

first

875 | 876 | 877 | 878 | 879 | $ 880 | ``` 881 | 882 | ### Create a Post Listing 883 | 884 | 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). 885 | 886 | 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. 887 | 888 | ``` 889 | $ find themes/zafta -name list.html | xargs ls -l 890 | -rw-r--r-- 1 quoha staff 0 Sep 29 17:31 themes/zafta/layouts/_default/list.html 891 | ``` 892 | 893 | 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. 894 | 895 | ## Creating Top Level Pages 896 | 897 | Let's add an "about" page and display it at the top level (as opposed to a sub-level like we did with posts). 898 | 899 | 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: 900 | 901 | ``` 902 | $ vi content/about.md 903 | +++ 904 | title = "about" 905 | description = "about this site" 906 | date = "2014-09-27" 907 | slug = "about time" 908 | +++ 909 | 910 | ## about us 911 | 912 | i'm speechless 913 | :wq 914 | ``` 915 | 916 | Generate the web site and verify the results. 917 | 918 | ``` 919 | $ find public -name '*.html' | xargs ls -l 920 | -rw-rw-r-- 1 mdhender staff 334 Sep 27 15:08 public/about-time/index.html 921 | -rw-rw-r-- 1 mdhender staff 527 Sep 27 15:08 public/index.html 922 | -rw-rw-r-- 1 mdhender staff 358 Sep 27 15:08 public/post/first-post/index.html 923 | -rw-rw-r-- 1 mdhender staff 0 Sep 27 15:08 public/post/index.html 924 | -rw-rw-r-- 1 mdhender staff 342 Sep 27 15:08 public/post/second-post/index.html 925 | ``` 926 | 927 | 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. 928 | 929 | One other thing. Take a look at the home page. 930 | 931 | ``` 932 | $ cat public/index.html 933 | 934 | 935 | 936 |

creating a new theme

937 |

about

938 |

second

939 |

first

940 | 944 | 945 | ``` 946 | 947 | Notice that the "about" link is listed with the posts? That's not desirable, so let's change that first. 948 | 949 | ``` 950 | $ vi themes/zafta/layouts/index.html 951 | 952 | 953 | 954 |

posts

955 | {{ range first 10 .Data.Pages }} 956 | {{ if eq .Type "post"}} 957 |

{{ .Title }}

958 | {{ end }} 959 | {{ end }} 960 | 961 |

pages

962 | {{ range .Data.Pages }} 963 | {{ if eq .Type "page" }} 964 |

{{ .Title }}

965 | {{ end }} 966 | {{ end }} 967 | 968 | 969 | :wq 970 | ``` 971 | 972 | 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. 973 | 974 | But, that about page still renders to about-time/index.html. 975 | 976 | ``` 977 | $ find public -name '*.html' | xargs ls -l 978 | -rw-rw-r-- 1 mdhender staff 334 Sep 27 15:33 public/about-time/index.html 979 | -rw-rw-r-- 1 mdhender staff 645 Sep 27 15:33 public/index.html 980 | -rw-rw-r-- 1 mdhender staff 358 Sep 27 15:33 public/post/first-post/index.html 981 | -rw-rw-r-- 1 mdhender staff 0 Sep 27 15:33 public/post/index.html 982 | -rw-rw-r-- 1 mdhender staff 342 Sep 27 15:33 public/post/second-post/index.html 983 | ``` 984 | 985 | 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. 986 | 987 | ``` 988 | $ vi config.toml 989 | [permalinks] 990 | page = "/:title/" 991 | about = "/:filename/" 992 | ``` 993 | 994 | 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. 995 | 996 | ## Sharing Templates 997 | 998 | 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. 999 | 1000 | We can put the common bits into a shared template that's stored in the themes/zafta/layouts/partials/ directory. 1001 | 1002 | ### Create the Header and Footer Partials 1003 | 1004 | 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. 1005 | 1006 | ``` 1007 | $ vi themes/zafta/layouts/partials/header.html 1008 | 1009 | 1010 | 1011 | {{ .Title }} 1012 | 1013 | 1014 | :wq 1015 | 1016 | $ vi themes/zafta/layouts/partials/footer.html 1017 | 1018 | 1019 | :wq 1020 | ``` 1021 | 1022 | ### Update the Home Page Template to Use the Partials 1023 | 1024 | The most noticeable difference between a template call and a partials call is the lack of path: 1025 | 1026 | ``` 1027 | {{ template "theme/partials/header.html" . }} 1028 | ``` 1029 | versus 1030 | ``` 1031 | {{ partial "header.html" . }} 1032 | ``` 1033 | Both pass in the context. 1034 | 1035 | Let's change the home page template to use these new partials. 1036 | 1037 | ``` 1038 | $ vi themes/zafta/layouts/index.html 1039 | {{ partial "header.html" . }} 1040 | 1041 |

posts

1042 | {{ range first 10 .Data.Pages }} 1043 | {{ if eq .Type "post"}} 1044 |

{{ .Title }}

1045 | {{ end }} 1046 | {{ end }} 1047 | 1048 |

pages

1049 | {{ range .Data.Pages }} 1050 | {{ if or (eq .Type "page") (eq .Type "about") }} 1051 |

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

1052 | {{ end }} 1053 | {{ end }} 1054 | 1055 | {{ partial "footer.html" . }} 1056 | :wq 1057 | ``` 1058 | 1059 | 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. 1060 | 1061 | ### Update the Default Single Template to Use the Partials 1062 | 1063 | ``` 1064 | $ vi themes/zafta/layouts/_default/single.html 1065 | {{ partial "header.html" . }} 1066 | 1067 |

{{ .Title }}

1068 | {{ .Content }} 1069 | 1070 | {{ partial "footer.html" . }} 1071 | :wq 1072 | ``` 1073 | 1074 | 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. 1075 | 1076 | ## Add “Date Published” to Posts 1077 | 1078 | 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. 1079 | 1080 | ### Add “Date Published” to the Template 1081 | 1082 | We'll start by updating the template used to render the posts. The template code will look like: 1083 | 1084 | ``` 1085 | {{ .Date.Format "Mon, Jan 2, 2006" }} 1086 | ``` 1087 | 1088 | Posts use the default single template, so we'll change that file. 1089 | 1090 | ``` 1091 | $ vi themes/zafta/layouts/_default/single.html 1092 | {{ partial "header.html" . }} 1093 | 1094 |

{{ .Title }}

1095 |

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

1096 | {{ .Content }} 1097 | 1098 | {{ partial "footer.html" . }} 1099 | :wq 1100 | ``` 1101 | 1102 | 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. 1103 | 1104 | 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. 1105 | 1106 | The "if" solution works for sites that have just a couple of content types. It aligns with the principle of "code for today," too. 1107 | 1108 | 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. 1109 | 1110 | Let's restore the default single template before we forget. 1111 | 1112 | ``` 1113 | $ mkdir themes/zafta/layouts/post 1114 | $ vi themes/zafta/layouts/_default/single.html 1115 | {{ partial "header.html" . }} 1116 | 1117 |

{{ .Title }}

1118 | {{ .Content }} 1119 | 1120 | {{ partial "footer.html" . }} 1121 | :wq 1122 | ``` 1123 | 1124 | 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. 1125 | 1126 | ``` 1127 | $ vi themes/zafta/layouts/post/single.html 1128 | {{ partial "header.html" . }} 1129 | 1130 |

{{ .Title }}

1131 |

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

1132 | {{ .Content }} 1133 | 1134 | {{ partial "footer.html" . }} 1135 | :wq 1136 | 1137 | ``` 1138 | 1139 | 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. 1140 | 1141 | ### Don't Repeat Yourself 1142 | 1143 | 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. 1144 | -------------------------------------------------------------------------------- /docs/themes/minimal/exampleSite/content/post/goisforlovers.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: "(Hu)go Template Primer" 3 | date: 2014-04-02 4 | tags: [ "go", "golang", "template", "themes", "development"] 5 | draft: false 6 | --- 7 | 8 | Hugo uses the excellent [go][] [html/template][gohtmltemplate] library for 9 | its template engine. It is an extremely lightweight engine that provides a very 10 | small amount of logic. In our experience that it is just the right amount of 11 | logic to be able to create a good static website. If you have used other 12 | template systems from different languages or frameworks you will find a lot of 13 | similarities in go templates. 14 | 15 | This document is a brief primer on using go templates. The [go docs][gohtmltemplate] 16 | provide more details. 17 | 18 | ## Introduction to Go Templates 19 | 20 | Go templates provide an extremely simple template language. It adheres to the 21 | belief that only the most basic of logic belongs in the template or view layer. 22 | One consequence of this simplicity is that go templates parse very quickly. 23 | 24 | A unique characteristic of go templates is they are content aware. Variables and 25 | content will be sanitized depending on the context of where they are used. More 26 | details can be found in the [go docs][gohtmltemplate]. 27 | 28 | ## Basic Syntax 29 | 30 | Go lang templates are html files with the addition of variables and 31 | functions. 32 | 33 | **Go variables and functions are accessible within {{ }}** 34 | 35 | Accessing a predefined variable "foo": 36 | 37 | {{ foo }} 38 | 39 | **Parameters are separated using spaces** 40 | 41 | Calling the add function with input of 1, 2: 42 | 43 | {{ add 1 2 }} 44 | 45 | **Methods and fields are accessed via dot notation** 46 | 47 | Accessing the Page Parameter "bar" 48 | 49 | {{ .Params.bar }} 50 | 51 | **Parentheses can be used to group items together** 52 | 53 | {{ if or (isset .Params "alt") (isset .Params "caption") }} Caption {{ end }} 54 | 55 | 56 | ## Variables 57 | 58 | Each go template has a struct (object) made available to it. In hugo each 59 | template is passed either a page or a node struct depending on which type of 60 | page you are rendering. More details are available on the 61 | [variables](/layout/variables) page. 62 | 63 | A variable is accessed by referencing the variable name. 64 | 65 | {{ .Title }} 66 | 67 | Variables can also be defined and referenced. 68 | 69 | {{ $address := "123 Main St."}} 70 | {{ $address }} 71 | 72 | 73 | ## Functions 74 | 75 | Go template ship with a few functions which provide basic functionality. The go 76 | template system also provides a mechanism for applications to extend the 77 | available functions with their own. [Hugo template 78 | functions](/layout/functions) provide some additional functionality we believe 79 | are useful for building websites. Functions are called by using their name 80 | followed by the required parameters separated by spaces. Template 81 | functions cannot be added without recompiling hugo. 82 | 83 | **Example:** 84 | 85 | {{ add 1 2 }} 86 | 87 | ## Includes 88 | 89 | When including another template you will pass to it the data it will be 90 | able to access. To pass along the current context please remember to 91 | include a trailing dot. The templates location will always be starting at 92 | the /layout/ directory within Hugo. 93 | 94 | **Example:** 95 | 96 | {{ template "chrome/header.html" . }} 97 | 98 | 99 | ## Logic 100 | 101 | Go templates provide the most basic iteration and conditional logic. 102 | 103 | ### Iteration 104 | 105 | Just like in go, the go templates make heavy use of range to iterate over 106 | a map, array or slice. The following are different examples of how to use 107 | range. 108 | 109 | **Example 1: Using Context** 110 | 111 | {{ range array }} 112 | {{ . }} 113 | {{ end }} 114 | 115 | **Example 2: Declaring value variable name** 116 | 117 | {{range $element := array}} 118 | {{ $element }} 119 | {{ end }} 120 | 121 | **Example 2: Declaring key and value variable name** 122 | 123 | {{range $index, $element := array}} 124 | {{ $index }} 125 | {{ $element }} 126 | {{ end }} 127 | 128 | ### Conditionals 129 | 130 | If, else, with, or, & and provide the framework for handling conditional 131 | logic in Go Templates. Like range, each statement is closed with `end`. 132 | 133 | 134 | Go Templates treat the following values as false: 135 | 136 | * false 137 | * 0 138 | * any array, slice, map, or string of length zero 139 | 140 | **Example 1: If** 141 | 142 | {{ if isset .Params "title" }}

{{ index .Params "title" }}

{{ end }} 143 | 144 | **Example 2: If -> Else** 145 | 146 | {{ if isset .Params "alt" }} 147 | {{ index .Params "alt" }} 148 | {{else}} 149 | {{ index .Params "caption" }} 150 | {{ end }} 151 | 152 | **Example 3: And & Or** 153 | 154 | {{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} 155 | 156 | **Example 4: With** 157 | 158 | An alternative way of writing "if" and then referencing the same value 159 | is to use "with" instead. With rebinds the context `.` within its scope, 160 | and skips the block if the variable is absent. 161 | 162 | The first example above could be simplified as: 163 | 164 | {{ with .Params.title }}

{{ . }}

{{ end }} 165 | 166 | **Example 5: If -> Else If** 167 | 168 | {{ if isset .Params "alt" }} 169 | {{ index .Params "alt" }} 170 | {{ else if isset .Params "caption" }} 171 | {{ index .Params "caption" }} 172 | {{ end }} 173 | 174 | ## Pipes 175 | 176 | One of the most powerful components of go templates is the ability to 177 | stack actions one after another. This is done by using pipes. Borrowed 178 | from unix pipes, the concept is simple, each pipeline's output becomes the 179 | input of the following pipe. 180 | 181 | Because of the very simple syntax of go templates, the pipe is essential 182 | to being able to chain together function calls. One limitation of the 183 | pipes is that they only can work with a single value and that value 184 | becomes the last parameter of the next pipeline. 185 | 186 | A few simple examples should help convey how to use the pipe. 187 | 188 | **Example 1 :** 189 | 190 | {{ if eq 1 1 }} Same {{ end }} 191 | 192 | is the same as 193 | 194 | {{ eq 1 1 | if }} Same {{ end }} 195 | 196 | It does look odd to place the if at the end, but it does provide a good 197 | illustration of how to use the pipes. 198 | 199 | **Example 2 :** 200 | 201 | {{ index .Params "disqus_url" | html }} 202 | 203 | Access the page parameter called "disqus_url" and escape the HTML. 204 | 205 | **Example 3 :** 206 | 207 | {{ if or (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} 208 | Stuff Here 209 | {{ end }} 210 | 211 | Could be rewritten as 212 | 213 | {{ isset .Params "caption" | or isset .Params "title" | or isset .Params "attr" | if }} 214 | Stuff Here 215 | {{ end }} 216 | 217 | 218 | ## Context (aka. the dot) 219 | 220 | The most easily overlooked concept to understand about go templates is that {{ . }} 221 | always refers to the current context. In the top level of your template this 222 | will be the data set made available to it. Inside of a iteration it will have 223 | the value of the current item. When inside of a loop the context has changed. . 224 | will no longer refer to the data available to the entire page. If you need to 225 | access this from within the loop you will likely want to set it to a variable 226 | instead of depending on the context. 227 | 228 | **Example:** 229 | 230 | {{ $title := .Site.Title }} 231 | {{ range .Params.tags }} 232 |
  • {{ . }} - {{ $title }}
    • 233 | {{ end }} 234 | 235 | Notice how once we have entered the loop the value of {{ . }} has changed. We 236 | have defined a variable outside of the loop so we have access to it from within 237 | the loop. 238 | 239 | # Hugo Parameters 240 | 241 | Hugo provides the option of passing values to the template language 242 | through the site configuration (for sitewide values), or through the meta 243 | data of each specific piece of content. You can define any values of any 244 | type (supported by your front matter/config format) and use them however 245 | you want to inside of your templates. 246 | 247 | 248 | ## Using Content (page) Parameters 249 | 250 | In each piece of content you can provide variables to be used by the 251 | templates. This happens in the [front matter](/content/front-matter). 252 | 253 | An example of this is used in this documentation site. Most of the pages 254 | benefit from having the table of contents provided. Sometimes the TOC just 255 | doesn't make a lot of sense. We've defined a variable in our front matter 256 | of some pages to turn off the TOC from being displayed. 257 | 258 | Here is the example front matter: 259 | 260 | ``` 261 | --- 262 | title: "Permalinks" 263 | date: "2013-11-18" 264 | aliases: 265 | - "/doc/permalinks/" 266 | groups: ["extras"] 267 | groups_weight: 30 268 | notoc: true 269 | --- 270 | ``` 271 | 272 | Here is the corresponding code inside of the template: 273 | 274 | {{ if not .Params.notoc }} 275 |
    276 | {{ .TableOfContents }} 277 |
    278 | {{ end }} 279 | 280 | 281 | 282 | ## Using Site (config) Parameters 283 | In your top-level configuration file (eg, `config.yaml`) you can define site 284 | parameters, which are values which will be available to you in chrome. 285 | 286 | For instance, you might declare: 287 | 288 | ```yaml 289 | params: 290 | CopyrightHTML: "Copyright © 2013 John Doe. All Rights Reserved." 291 | TwitterUser: "spf13" 292 | SidebarRecentLimit: 5 293 | ``` 294 | 295 | Within a footer layout, you might then declare a `