Gant Software Systems

No More Hack Attempts

There are a lot of upsides to wordpress. It’s not terribly difficult to set up, relatively straightforward to administrate, and makes a lot of website use cases pretty simple. This is why I initially used the tool, as I just wanted to get started without too much ceremony. However, after a few years of using the tool, I started having a lot of issues. For one, Wordpress has got some significant security issues, as well as a large number of automated attacks on the platform. Nearly every day, I got at least half a dozen messages where particular IP addresses were being blocked for repeated unsuccessful login attempts. In addition, I had to spend a fair bit of time trying to tune my website to sort out performance issues, a number of which were actually the result of interaction with the MySql database server. Finally, I had frequently wanted to experiment with different ways to lay out the website, but it wasn’t as straightforward as I liked due to the complexity of the tool.

So, I started looking into alternative solutions to wordpress. My criteria were as follows:

  1. The toolchain must allow me to easily switch out my post editor and allow me to use clean desktop tools for text editing. Whatever editor I use should be specialized for editing text, not for editing text for a platform.
  2. The toolchain must generate a static version of the website both to reduce the attack surface and to reduce the risk of database problems slowing the site down.
  3. I must be able to do theming and skinning of the site using basic tools like css and javascript.
  4. The toolchain must be capable of being deployed from git to azure. I want to be able to edit files on my file system, issue a command and have them in the cloud. I’m still not entirely sure that I’m going to use azure, but I want the option to be easy if I choose to do so.
  5. Be entirely file system based so that they can be backed up into source control. One thing I found particularly obnoxious with wordpress was the amount of difficulty involved in simply getting a development environment set up to test things out in, and the corresponding difficulty of getting development changes out into production.
  6. Whatever templating library and other tools I need to use to make this happen should be written in a language with which I have some comfort and experience, because publishing a blog should be a writing exercise, not a coding one.

After watching a bunch of tutorial videos on the internet, along with reading a lot of blogs, I finally reached the conclusion that one of two NodeJS-based static site generators would be my choice. I was pretty evenly split between DocPad and Hexo for generating the site. I ultimately decided on Hexo because a number of people indicated that it was a little easier to get started with. After a very short bit of effort, my workflow for adding blog posts looks like the following:

  1. Create a new blog post

    1
    hexo new "My New Post"

  2. Write and edit the blog post in whatever text editor I want. I use Visual Studio Code, which is awesome, clean, free, and available on multiple platforms. The autosave is particularly nice.

  3. Once it passes muster, I commit the hexo site to git.

    1
    2
    3
    git add .
    git commit -am "Another post done."
    git push origin master

  4. Next, I regenerate the site.

    1
    hexo generate

  5. And then I deploy the site using FTP

    1
    hexo deploy

Ultimately, it’s a lot less painful than using wordpress. There is very little attack surface here, and it scales very well. In addition, it’s very platform independent, so I’m not required to use apache or IIS for the webserver unless I want to do so. Finally, the editing experience is far better, as I don’t have to have a working internet connection to be able to work on the site. I can essentially write blog posts pretty much anywhere, from whatever device. In practice, this means having the entire site in dropbox as well as in git, using the dropbox to synchronize across devices and using git for source control. The git repository lives on a small server at the house and is backed up offsite, as are the other machines in the house.

share