Skip to main content

Hugo - On layouts and content organization

Layouts in Hugo allow you to define the how the posts in the content directory would be displayed. In addition to defining layouts for the content posts, you can define the layout for the home page, define partials and include it in different layout templates, also define the default layout to be used in case the matching content type layout is not found.

The directory structure followed in Layouts imitates the directory structure of the content directory:

--layouts
  --_default
    --single.html
    --summary.html

  --pages
    --single.html
    --summary.html

  --partials
    --header.html
    --aside.html
  --index.html

The site's home page is defined in layout's index.html file. If you're building a blog, this page would list the recent posts. Hugo provides several Site level variables that you use it in this template file:


Notice that several template variables are used to create the home page. The one that will display recent posts is mentioned inside the body tag of the template:

{{ range .Data.Pages }}
  {{ if or (eq .Type "posts") (eq .Type "posts-series") }}
    <h3>
       <a href={{ .Permalink }}>{{ .Title }}</a>
     </h3>
     {{ .Render "summary" }}
  {{ end }}
{{ end }}

The range operator is used to iterate over an array; here the template variable .Data.Pages contain all the posts listed in the content directory. Inside the range loop, a condition is specified to see if the page if of a particular Type. The Type information is determined by the location of the post in the content directory. If the post is defined in the 'posts' directory then the type would be 'posts', similarly, if you have top level pages defined in 'pages' directory, then the type would be 'pages'. Alternatively, you can override the default Type by mentioning 'type' field in the front matter of the post(see the content organisation section below).

When listing posts, you would want to list only the summary information instead of the entire content of the post. The template {{ .Render "summary" }} is used when you have a separate template - summary.html defined to display the summary information. This template could display additional information such as published date, tags etc. If you would like to display only the summary without including any additional template then use the template variable {{ .Summary }}. Hugo will pick up the first 70 words from the content and display it as the summary of the post. Alternatively, you can insert a jump break by including <!--more-->  tag. Hugo will pick up all the content before this tag and display it as the summary of the post.

Let's take a look at summary.html defined in _default directory:

Published date: {{ .Date.Format "2 Jan, 2006" }}
{{ .Summary }}
{{ if .Truncated }}
  <a href="{{ .Permalink }}">Read more >> </a>
{{ end}}


Here we are using the template variable {{ .Summary }} to display the summary of the post. Also, we are displaying the published date and providing a link to the post if the content is truncated. The flag Truncated would be true if there are more than 70 words in the post or a <!--more--> tag is inserted. Any template defined in 'layouts/_default' will be used as a default template to render the content. You can always define a different layout by creating a directory with its name matching the directory name in the content directory.

On content organisation:

Hugo organises the generated content in the same way as it's defined. However, you can override it by updating some of the fields in the front matter of the post. You can specify additional fields - 'slug', 'type', 'path' and 'url' to override the default.

For example, if you have written a couple of posts at 'posts/blog-post-1.md' and 'posts/blog-post-2.md', Hugo will generate the content in public directory at  'posts/blog-post-1/index.html' and 'posts/blog-post-2/index.html'. If you would like to rename 'blog-post-1' and 'blog-post-2' to something else specify the 'slug' field in the front matter:

+++
date = "2016-12-05T20:08:38+05:30"
draft = true
title = "blog post 2"
slug = "first-post"

+++

This post now can be accessed at '<site>/posts/first-post'.

You can also specify the 'url' field in the front matter and this will render the page at the given 'url'. For example, if you have top level pages defined under pages directory - 'pages/about-us' and 'pages/contact-us' and want to render them at the top level i.e. at '/about-us' and '/contact-us':

+++
date = "2016-12-05T20:08:38+05:30"
draft = true
title = "about us"
url = "/about-us"

+++

If both slug and url are specified then, url would take precedence. The url field in the front matter would take precedence over any other field.

As mentioned earlier, you can specify the type field in the front matter to override the default type assigned to the post. Consider you are writing a series of post on a particular topic and you have created a directory 'series-topic' under 'posts'. Here you can add the field 'type' in the front matter and provide a value say 'posts-series'. Using this type information you can easily get to the set of posts and display content as necessary.

Example source code can be found here - https://github.com/sagar-ganatra/hugo_example

Comments

Popular posts from this blog

Adding beforeRender and afterRender functions to a Backbone View

I was working on a Backbone application that updated the DOM when a response was received from the server. In a Backbone View, the initialize method would perform some operations and then call the render method to update the view. This worked fine, however there was scenario where in I wanted to perform some tasks before and after rendering the view. This can be considered as firing an event before and after the function had completed its execution. I found a very simple way to do this with Underscore's wrap method.

De-obfuscating javascript code in Chrome Developer Tools

I had blogged about JavaScript debugging with Chrome Developer Tools  some time back, wherein I have explained how these developer tools can help in debugging javascript code. Today Google Chrome 12 was released and my Chrome browser was updated to this version. As with every release, there have been some improvements made on performance, usability etc,. One feature that stood out for me is the ability to De-obfuscate the javascript code. What is Minification? Minification is the process of removing unnecessary characters such as white spaces, comments, new lines from the source code. These otherwise would be added to make the code more readable. Minifying the source code helps in reducing the file size and thereby reducing the time taken to download the file. This is the reason why most of the popular javascript libraries such as jQuery are minified. A minified jQuery file is of 31 KB in size where as an uncompressed one is about 229 KB. Unfortunately, debugging minified javascript f

On GraphQL and building an application using React Apollo

When I visualize building an application, I would think of using React and Redux on the front-end which talks to a set of RESTful services built with Node and Hapi (or Express). However, over a period of time, I've realized that this approach does not scale well when you add new features to the front-end. For example, consider a page that displays user information along with courses that a user has enrolled in. At a later point, you decide to add a section that displays popular book titles that one can view and purchase. If every entity is considered as a microservice then to get data from three different microservices would require three http  requests to be sent by the front-end app. The performance of the app would degrade with the increase in the number of http requests. I read about GraphQL and knew that it is an ideal way of building an app and I need not look forward to anything else. The GraphQL layer can be viewed as a facade which sits on top of your RESTful services o