Scoot Safely Has Completely Changed — It's the Same

Take a look at the blog. Notice anything different? I bet not. Yet, I have spent the last month or so working feverishly to completely alter the way Scoot Safely is produced.

This is going to be a short departure from scooter-related material, and it’s going to be just slightly technical. However, I thought my readers may like to take a look into the world of producing blogs, and some of the technical issues involved.

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.

Plugins

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 sure are! Read on…

Speed

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 themsevles 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 whiich serve up plain old HTML.

However, it gets worse…

Maintenance and Hacker Hell

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—including this site. 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 home 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.

Not so fast, sport…

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 good 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.

There Must be a Better Way

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…

Enter HUGO

For those with a slightly more “techy” 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 Scoot Safely blog, for instance, takes precisely 267 milliseconds on my five-year-old Macbook Pro.

Of course, for me, there was much more work involved. I had six years’ worth of blog posts and their associated comments to convert to the new format. Also, with a static site, you lose all the dynamic funcitonality that comes with a CMS, such as post subscription funcitonality, contact functonality and comments.

For these elements, being the self-confessed geek that I am, I wrote my own software to handle post comments and post subscription.

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, for a programmer, learning a new language is very much like learning a third spoken language. It gets easier the more languages you learn.

The End Result

So, there you have it! Scoot Safely has 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 you didn’t even notice…

I hope you find these posts useful. If you do, please consider supporting, while gaining access to all this information, and more, by purchasing: Proficient Scootering - The comprehensive guide to safe, efficient and enjoyable scooter riding. It's available for all e-readers and in print.