Static websites are getting more and more popular. While some might denigrate this “back to the roots” approach, these systems have numerous advantages. They’re often faster because they’re limited to serving simple web pages, with barely any workload on the serve. The logic is left to be handled by the client, mostly via the usage of APIs, and it’s much easier to put resources in cache and use a CDN during deployment. Besides, these are considered atomic as they allow instantaneous cache invalidation. The website deliverability is therefore 100% assured. Static websites are also often much more secure, as they don’t allow information to be directly sent to the server.

That being said, the update and deployment of a static website has to be made from a machine equipped with the suitable development environment. A terminal, and tools such as Git, Node, NPM, Ruby and others are often necessary. Indeed, the website has to be compiled beforehand or thanks to an automated process such as GitHub Pages or Netlify.

On the need for a static CMS

The need for a static CMS therefore makes sense for multiple reasons. First it allows to overcome the need for a development environment. In the case of a blog, the creation of articles becomes much more fluid, and being able to get away from this technical environment allows for a better workflow for the content creation process. Secondly, it allows non-technical users to manage their website and let them be more free in creating and managing editorial content.

Today I’m trying out Forestry, a hosted service which makes use of the GitHub API in order to allow a static website to be remotely managed.

Installation

The installation of the CMS is extremely simple: I just had to create an account on Forestry, link it with my GitHub account and select the repository for the website in question. I then had to specify if the website is generated by Hugo (which is my case) or Jekyll. Quick note: I had to specify the version of Hugo I’m using, and the ones given by Forestry will not necessarily correspond to yours. It wasn’t a problem for me as I’ve configured Forestry not to generate my website, but it’s something to consider.

Configuration

Forestry’s configuration is just as simple. Its system will browse through your repository and generate content types depending on what it finds. All in all, it took me five minutes to have a working back-office and I was able to be productive right away.

It’s even possible to inject the CMS inside your own site and go through a URL you specify (for instance www.example.com/admin), which allows you not to leave your own website.

Usage

Forestry works by using GitHub, Gitlab or Bitbucket’s API. It’s a fairly simple CMS to use with a clean interface. On the left, a panel listing all the content types allows access for the different categories of the site, and on the right a Wordpress-like panel displays to the Front Matter fields and the main text editor.

In my case, Forestry did an incredible job finding all my blog posts and projects, but was a bit limited when it comes to pages content. Thus, for an unknown reason, the system thought my home page and the “About” page were different, and it put them in two different sections.

I was surprised to see that even though Forestry uses GitHub’s API, it’s not possible yet to access a content history.

It’s however possible to rename the file (automatically generated by the CMS) in order to benefit from Hugo’s multilingual support. Thus, by only adding the extension .fr to an existing slug, I was able to let Hugo automatically link two blog posts and suggest the translated version to the visitors.

In my case, a “project” is exclusively configured thanks to the Front Matter. By changing a couple of lines from the config file, I was able to get rid of the text editor and simply have the configuration fields for a project. For Wordpress users, it’s equivalent to having a page constructed thanks to the Advanced Custom Fields plugin, but generated thanks to a YAML file.

Pros and cons of the CMS

The first obvious con of using this type of CMS is the “technical” aspect that remains very strong even in the presence of a graphical interface. Knowing how to name files is a must in order to allow Hugo to handle them, and some aspects of the interface might scare some users.

It would have been smart to allow for a hidden, automatic way of naming content files, thanks to a slug system inside the configuration file, and change the language thanks to a select input.

Adding “users” with restricted permissions is reserved to the “Business” plan which starts at $9 per user per month. In its free version, it’s possible to add “guests” who have almost all rights on the site, which can become pretty problematic.

For instance, you should note that when it comes to Hugo sites, Forestry enforces the TOML format for the Front Matter and config files. In my case, Forestry detected “menus” for my projects, which are not used anywhere. In trying to test this feature and changing the order of this menu, Forestry decided to rewrite 47 files, including Hugo’s config (writing TOML syntax inside a YAML file), which completely broke my build system. I had to use Git to undo these modifications and come back to a previous working version.

On another side note, it is to be considered that Forestry lives in Git, and therefore is going to generate a multitude of commits, that won’t certainly respect your commit convention. It’s small point, but it’s something to think about.

Wrapping up

After writing all this, one might seem that I did not enjoy my time with Forestry, but it’s far from the truth. While it has some flaws, the team behind it is constantly working on improving it. That being said, and when considering how easy it is to install and use this system, I’d say it’s a really solid choice as a static CMS. It allows to find a certain flexibility when administrating a website while still benefit from the advantages of speed, security and optimizations of a static website generator.