Among my other ventures, I run a couple of blogs (Motorcycle Mastery and Scoot Safely). These blogs have been up and running since about 2014. Like most people, I used the software that has become the de-facto standard for blog production: WordPress.
I have, however, spent the last couple of months converting those blogs to an alternate system. Here, I’m going to outline the reasons behind that change, and will discuss some of the pros and cons for such a decision.
But first, let’s have a quick look at how blogs are produced:
The first name to come up when talking about blogs is WordPress. In fact, it is being used currently by 30% of web sites worldwide — even if they’re not actually blogs.
WordPress belongs to the family of technologies called CMS (Content Management Systems). It is open-source, and so is contributed to, freely, by many developers over the world. It is fast becoming the de-facto web site production tool.
In its most basic form, a web page is just text (and images) surrounded by HTML markup to tell your browser how to make it look pretty. An example of the markup for this page, for instance, looks like this (click the image for a larger version):
When you visit a web site, your browser gets sent the funny looking text shown here, and it translates it into what you see.
Now, not everybody is able to, or interested to, understand the HTML markup syntax. Platforms such as WordPress allow anybody to simply enter the text just as you would in, say, a word processor. WordPress then translates that into HTML, and stores it in a database. That HTML then gets re-translated once it is sent back to your browser.
Unlike with a static site, in which every page is simply a document containing the HTML, WordPress stores the markup in a database. When the page is requested, it goes to the database, retrieves the HTML, assembles it—along with any other information created by plugins (more about these later)—and finally sends the assembled document to the browser. The image below outlines the basic processes.
With WordPress, when a blogger wants some extra functionality, such as the ability for users to subscribe to posts, or rearrange the elements on the page, they install plugins. These plugins are written independently, and vary in their quality. However, they give the user the ability to quickly add functionality.
All of this is very useful as it allows anybody to produce blogs and web sites with little-to-no technical know-how. Are there any down-sides? There are. Read on…
While all this magic which goes on behind the scenes is great for blog creators, nothing comes for free. The cost is speed. If you ask a server for a static web page, it simply returns the document. Further, because the document is always the same, it can do what is called caching, which means it can keep the page in memory to serve it to multiple readers even faster.
Conversely, every single request to a WordPress site has to run software on the server which gets the page request, goes to the database multiple times to get the page content, assembles that content along with the plugins—which themselves make multiple request to the database—and finally assembles the page and returns it to your browser.
Clearly, this takes time and resources. For every request for a page on the site, this process has to take place. Consequently, sites which are created with a CMS are an order of magnitude slower than those which serve up plain old HTML.
However, it gets worse…
Two years ago, unbeknown to my readers, I spent a frustrating month fighting hackers. I was running about ten sites at the time. Five of them had been produced with CMSs. The first thing I knew was that my hosting company wrote to tell me that every one of my sites had been taken offline. The reason given was that malicious code had been found on one of the sites.
Frustratingly, the hosting company gives very little information about where exactly that malicious code is. They did not even tell me which site, or sites, had been affected.
Obviously, not wanting to risk my readers’ computers, I immediately set about cleansing my sites. Re-assembling a WordPress web site is not for the faint-of-heart. Without going into technical details, it basically means wiping the site, installing a fresh version, re-configuring, re-connecting to the database and re-installing every plugin that you use. This, of course, takes many hours—assuming you can remember how you set it up in the first place.
Unfortunately, this coincided with my office Internet connection going down. However, many hours later—spent at Starbucks and sitting outside premises where I could borrow some Internet—I had found the affected site and completely recreated it from scratch. I called my hosting company to ask them to reconsider their banning of my sites. This they did, and all was well with the world again.
The very next day, I awoke to the same e-mail. All my sites had been taken offline again. This time, it was a different site that had been infected. I’ll spare you the blow-by-blow details, but this hell went on for over a month. No sooner had I recreated one site, another one was hacked. Each time cost me the best part of a day to fix—even given that I was now getting quite adept at WordPress reassembly!
This all comes about because of the complexity and disparate sources of the component parts of your site. Every extra element—every extra plugin—is a potential vector to attack by the Internet underworld. Most often, these attacks aren’t even done by humans. They’re done by “bots”, which relentlessly crawl the Internet looking for vulnerable sites. It only takes one plugin creator to not patch the latest vulnerability, and your site is open to attack.
Consequently, the role of a CMS site owner is to daily monitor the site, make sure you’re using the latest versions of your plugins, replace plugins which aren’t being properly maintained, back-up your data, and hope for the best. Every day, I get a summary of who has been attacking the site and how. Just reading one of those reports is quite an eye-opener. This can be such a headache that I have clients who pay me to maintain the security aspect of their blogs for them.
For the geek (guilty as charged), there is. Plain old-fashioned HTML pages are quite immune to attack. It’s just a text document, after all. Even if a hacker gets through your security and alters or removes your page, you simply upload it again. If my sites had been plain HTML, each site that was taking me a day to replace—during my month of hacker hell—could have been replaced in thirty seconds. Now, if only there was a way to produce a blog without a CMS; to produce a blog which simply ends up as plain old HTML pages…
For those with a slightly more technical nature, there is a way. Hugo is what is called a static site generator which is blog-aware.
You create your site on your own computer, and when you’re ready, hit the virtual “Go” button. Hugo then creates your site as plain HTML pages with all the links, cross-references, and other blog magic automatically created for you.
Posts in HUGO are written in Markdown, a simple text formatting method which looks almost identical to the plain text with a few simple codes thrown in. It makes writing new content a joy, because everything gets out of the way, and you can concentrate simply on the written word.
Hugo creates the entire site with incredible speed. To create the Motorcycle Mastery blog, for instance, takes precisely 57 milliseconds on my five-year-old MacBook Pro.
Of course, for me, there was much more work involved. I had four years’ worth of blog posts and their associated comments to convert to the new format.
I also set myself the challenge of making the change completely transparent to my readers. I didn’t want the site to look any different. Because of this, I couldn’t use any of the available templates, so had to learn the language used by Hugo to create my own. Fortunately, learning a new programming language is very much like learning a third spoken language. It gets easier the more languages you learn. It is my job, after all.
Nothing comes for free, right? Because static web sites are plain HTML, you lose all the dynamic functionality such as comments and post subscription. Post subscription was relatively easy to write, but I could not find anything ready-built to handle adding comments to the blog posts.
There are some options, however. Services such as Disqus allow you to embed their free comments section into your web site. I was not happy with this solution for a couple of reasons. Firstly, the data is out of my control. Apart from the usual data-mining activities that outside services take part in, these services can effectively do what they like with your comments—including inserting their own adverts into the content. Secondly, there was a maintenance aspect which involves working with an external web site.
I wanted something which was simple to maintain, was easy to implement, and meant that I kept control of the data in-house, as it were.
Hence, In-House Comments was born. It is a system which can be integrated into a web site by embedding just a couple of lines of code into your pages. The data is maintained locally, and there is no database to be maintained or set up.
So, there you have it! My blogs sites have completely changed. It has been a lot of work. There were some nights of working through to 5.30 AM. I’m free of WordPress. I’m so much safer from hackers, and the site loads so much faster for my readers.
And I bet they didn’t even notice…
Menu