last updated: 15 October 2018 (approximate reading time: 9 minutes; 1709 words)
When looking at tools to help build websites, in a comparison between static site generators and content management systems, I come down on the side of the static generator. While static generators offer significant advantages, there are benefits to content management systems that make them attractive.
However, for under $100 you can add functionality to a static site workflow and remove many of the last few reasons to consider a content management system.
Static Site Generators: the Pain Points
Running a static HTML website brings huge advantages. The key benefits being:
- security—the site is, effectively, hack free since there isn’t a login/database
- speed—the site is rocket fast since the HTML is already generated
- ease—all you need to do is write a text document
However, there are some pain points. And there are other aspects which may not cause pain, but do constitute one of a bunch of tasks that are just plain boring so I’ll also file these under “pain points”.
Those pain points:
- The need to use the command line always feels archaic—even with batch files, even knowing the benefits the command line can offer.
- With every update to the site, two manual processes must be run. The first process to regenerate the site, the second to upload the regenerated site.
- Posting from mobile is—in practical terms—impossible (since you can’t regenerate the site/upload the regenerated files from a phone).
- Timed posts—so a post that needs to go live at midday on Tuesday and it’s currently the previous Saturday—are impossible since, in effect, it is the time of upload that determines when a timed post goes live, hence one needs control over that process to make timed posting work.
However, there is a way to get past these pain points. The solution is straightforward, cheap, and minimally technical.
A Word of Caution
I’m setting out a process here. I’ve tried certain elements, however, I haven’t set this process to run over the longer-term.
I’m offering this up more as a suggestion…something for people to think about and contemplate if they are experiencing the pain points this approach is intended to address.
This article is also primarily about using Hugo since that is my static generator of choice.
The tools necessary for this process are:
- a computer (I’ll talk more about this in a moment)
- a sync service (such as Dropbox, Google Drive, or OneDrive) which works on both mobile and your chosen computer
- an FTP (or preferably secure FTP) client that works from the command line and which can run on your choice of computer
Having gathered the tools, the setup goes like this:
- Turn on the computer 😁
- Attach the computer to the internet.
- Install the sync service, Hugo, and the FTP client on the computer.
- Put all of your websites into the sync service, so all of the files are copied to the computer. You want to be in the position so whenever you save a document—whether on your desktop or from a mobile device—that document is then copied to the computer. Equally, for ease of management, you want your other website files on the computer so that any changes (for instance, a theme tweak) can be included in the upload.
- Set Hugo to regenerate the site every X hours or minutes—this regeneration will include any newly transferred files (transferred to the computer by the sync service).
- Set the FTP client to run every X hours or minutes—this will then upload the regenerated site to your web host.
- Leave the computer running 24/7.
Hugo and the FTP client will need to be set to run once in every time period for each site that you run.
Setting up what is, in effect, a server to handle the generating and publishing of a static HTML website provides a fairly blunt tool. It may work for you as set out above or you may want to finesse the process.
There are several areas you may wish to finesse, but here are three aspects to think about first.
You can be fairly blunt with your approach to the date on documents. If you put the instruction to include future-dated documents when your run the build command (so:
hugo --buildFuture) then all documents will be published when the next generate/upload cycle runs.
However, if you want to get more accuracy around the timing of posts, for instance, if a post must show up at an exact time, then:
- You can include a time into the date of a document and by excluding the
--buildFutureswitch, you can ensure the page is only generated after the specified time.
- You would also need to reduce the interval between cycles so the generate/upload process runs with greater frequency.
Conventionally, an entire Hugo site lives in a single folder with the elements (such as the content, the output folder, and the theme) in separate subfolders. However, it is not necessary for the subfolders to be subfolders—these folders can be located anywhere convenient.
The /content subfolder is one of the folders you may want to locate outside of the main site folder. By locating it outside the main folder, you may find accessing content easier from a mobile device and you can exclude the other site elements from syncing to your mobile device.
You can then point Hugo to a location for your content files which is outside of your site’s directory by using the
contentDir setting in the Hugo configuration file.
Conventionally, when a site is generated, the files to be uploaded to the web host are placed in the /public subfolder.
The files in this subfolder have one purpose—to be uploaded. There is no need to synchronize these files to other locations or to include them as part of a backup process. And indeed, if your site is being regularly regenerated, it may be positively desirable to exclude these files from your synchronization and backup processes.
As with the /content folder, you can set a different output folder by a tweak to Hugo’s configuration file (this time setting the
publishDir to be a location outside the sync and backup folder).
I’ve been very unspecific in talking about a computer because you can choose anything that works for you.
Since the box is only required for one function—and that function doesn’t require huge amounts of computing grunt—you can choose anything you understand how to work and which feels comfortable to use. Of course, whatever you do choose must be able to run the sync service, have an FTP client available, and you must know how to set a scheduler to run the generation/upload tasks.
For what is needed, a cheap Windows box seems ideal. The great thing about Windows boxes is you can get them really cheaply. A refurbished name brand box can be acquired for under $100 (you can check prices on Amazon) and at this price, the options are plentiful—the machines are easy to acquire and easy to replace.
You don’t need huge power. You only require “good enough” performance, so a cheap machine should be ideal.
Further, scripting is straightforward in Widows (batch files are text files with a series command line commands). Running tasks on a timer is equally straightforward—the scheduler is built-in to Windows.
The most straightforward approach is to employ an FTP client that can be run from the command line. However, depending on your setup, you could adopt a different workflow.
For instance, instead of a conventional FTP client, you could use a client that mounts your website as a drive, so it looks like just another drive on your computer (in the same way that a thumb drive or other USB drive looks like just another drive). In this instance, the web connection is effectively permanent and the upload process is simply a matter of copying files from one folder (the local folder where your site is generated) to another folder (the folder representing your site on your web host).
There are, of course, other options and other approaches. For instance, instead of running the cheap computer 24/7, you could simply use it as a backup while you’re away from home or if you want to make timed posts.
If you understand these things and have the smarts to do it, then you could run this setup on an online service.
These timed processes could also be set to run on a regular computer—there’s no requirement to acquire a dedicated box, and using your regular machine is even cheaper than a refurbished Windows machine. The only difference would be that you would need to leave your machine running if you wanted to have the facility to post while you were away from your desk.
Also, if you’re prepared to limit your choice of web hosts, some will work in conjunction with services such as Github and will generate a site from your most recently committed files. Provided you can remotely post to Github (or wherever) and you’re happy with one of the limited choices of webhosts, then this option could work well. It’s not for me, but it might work for you.
One other advantage that content management systems have over static site generators is the facility to have multiple users—several individuals working on content and publishing simultaneously.
Having a shared sync folder and a separate server goes a long way to addressing that issue. It may not be as pretty as a full-blown content management system, but functionally, it allows several people to simultaneously publish content.
The sync service handles the sharing of files—and gets the files onto the computer—and then the regeneration/upload would happen with the computer.
So is this the answer? Is this the way to achieve parity between static site generators and content management systems?
But whether this solution could be right for you is mostly a matter of how much you need remote access. If you can live with only generating a static site from a desktop or laptop machine and then manually clicking the upload button, then I’d ignore this process. But if you want to run a static site when you’re away from your usual base, think about this option.