How this site is built and managed

By Oliver Granlund · Published 23.12.2020

As I've worked so many years with WordPress, I wanted to try out something else. I had heard fuzz about Jamstack and its benefits but never had any project where I could give it a shot. Late 2020Q4 I decided that I finally need my own website and what better way to build it than with something new!

I have wanted to try out Jamstack already for a while but I didn’t know what to do. After seeing my friend’s site built on Hugo, I decided that I want to try it out as it’s based on Go, the new programming language created by Google. I still had to have some sort of CMS to handle the content and I wanted to do something else than WordPress, Forestry CMS seemed to be the obvious choice according to several sources on the web.

I had certain requirements that I wanted for the setup:

Easy handle separately posts and pages
Support for custom blocks which can be put in any order
Posts/pages built on custom blocks
Querying only certain content/filtering content depending on variables

Prerequisite

Out of the box, I didn't see any Hugo solution for the custom blocks, but once I read onto Forestry's Front Matter of reusable front matter elements, I knew I had to give it a shot. At this point, I started building my own Hugo theme by emptying a readymade theme to barebones.

I brought in many of the SCSS-mixins and variables which we are using in Evermades open-source Everblox theme. These tidy up things and make it faster to develop elements.

Post listing issue

Listings turned out to be a little tricky. Hugo uses several different archive pages for automatic content generation. This was neat but not really what I was looking for, so I had to figure out how to custom query content with Hugo to create a post listing. After debugging post-fetching for many hours I realized that I need to change the way I'm thinking. I was stuck in the PHP-MySQL mentality where you only fetch what you need, but with Hugo, it doesn't matter as much how optimized your post-fetching query is as the final result is anyways a static site. I ended up for a less-optimized solution to be able to move on. I'll maybe revisit this again sometime in the future

Some code showing the complexity of working with a low-level language like Go

/content/ folder

One thing which I fell in love with was that all the content (excluding images) are saved in the git-repo itself! This made it super easy to sync up to where I last stopped, as I've worked on this from a few different computers. In WordPress, you always had the issues with transferring databases and renaming URLs, but not with Hugo!

Working with Forestry CMS

The text editing experience is a slight downgrade from WordPress TinyMCE as the Forestry CMS editor does Markdown. This makes the content cleaner, but you lack any specialities eg. adding custom elements/tables to content. The markdown still supports raw HTML so you can still do whatever you like, it just won't look as tidy in the CMS.

Example of a block edited with Forestry CMS

Image hosting

As all the content is saved in the git repo, I had to figure out how to host the images. In WordPress, you have nifty shortcuts to get the right size of an image but Forestry lacks anything similar. I first thought about AWS but found out that Netlify offers Git LFS (Large File Storage) with additional parameters for the compression. With this, I was able to set maximum-resolutions for all my content. This way I don't have to worry about uploading too large images and can focus on making great content.

Git LFS (Large File Storage) logo

Workflow

During the development of this site, I’ve changed deployments and even tried Hugo modules. Finally, I settled on Git submodules as those were simpler to work with. Now my workflow works like this:

Want to edit content?

Go to Forestry.io and edit the content, Netlify build and deployment happen automatically after a save.

Need to edit features/blocks?

My Hugo-theme is in its own repo so it doesn’t trigger automatic deployments. I can develop it further, and when ready, commit the Hugo-site repo with a new submodule hash which triggers the Netlify build and deployment.

Debugging or further development?

I just need to have the Hugo-site repo with the Hugo-theme submodule fetched, and I’m ready to debug things with the command hugo server.

Final verdict

Overall Hugo + Forestry has surprised with some features, some again have been a little letdown. If you want to build a static site with a CMS, this works for more simple cases really well. If you need some more robust content editing tools, I suggest looking at some other CMS:s which can deliver on that.