So in the end I migrated this blog of mine (which ended up being mostly about travelogues) from GitHub Pages to WordPress. If this doesn’t mean anything to you, you can probably skip this post safely.
Why? I mean, GitHub Pages are so hip and WordPress is literally one of the words pieces of software imaginable, right? Well, simply put, GitHub Pages are not really a good fit for travelogues. GitHub Pages, if you didn’t know, is a very simple hosting option available at GitHub (which is mostly about hosting software project code). It is free but all it can show is static HTML pages, or Jekyll templates. Jekyll is the most popular of static site generators these days. These generators take templates written in their own specific languages, and convert them to HTML pages. This is all done locally (or in case of GitHub Pages, on GitHub servers), and all that is ever actually served to website visitors is static HTML.
This is actually quite an appealing concept. It naturally limits interactivity, but most websites arguably don’t really need any interactivity at all. And these days, if you want comments, for example, you can just slap a Disqus widget onto your website — this way you’ll have someone else take care of your comments, and won’t need anything to run on your server. So you can just write your pages/posts in plain HTML or Markdown, and have header/footer/menu/index pages generated by Jekyll. Well not necessarily Jekyll, these days there are hundreds of static site generator projects. But Jekyll’s the most popular, and the only one natively supported by GitHub Pages. An additional advantage is that you can use your favorite text editor, and edit your posts offline, just pushing them onto GitHub whenever you like.
Well, it turns out, this workflow is fine for a basic website with a few pages, possibly about some software project or whatnot, or for a simple blog which doesn’t have many pictures. In fact I believe both of these use cases are precisely what GitHub Pages were designed with in mind. But when you write travelogues, it is mostly about pictures. And when you need pictures, static site generators begin to suck ass.
What do I usually do with pictures? Whenever I travel (or possibly just take a walk or whatever) I take a lot of pictures. Over a hundred usually, for a vacation trip this can easily break into thousands. I then dump all of them into Adobe Lightroom, throw out the ones I don’t need, and retouch the rest (only very basic stuff, usually only white balance, exposure, straightening, and crop). Usually I only delete duplicates and obviously worthless photos (significantly smudged etc.), and keep the rest, even if there’s apparently nothing of artistic or historic value on them. I just like to keep these photos.
So whenever I write a post, it generally has around 25-50 pictures, which I need pick from about 50-250. These pictures also need to be actually hosted somewhere; git and GitHub isn’t meant for picture hosting. I ended up just dumping all of the pictures into a private album on Flickr. Then, I used http://www.photo2blog.ru/ tool to pick photos from that album and generate a skeleton of the new post, which I then opened in a text editor (VS Code, SublimeEdit) to actually fill in text. I try to keep a bilingual blog, and wrote an English version first; then I copied it and translated into Russian. Finally I needed to link the new post into index pages (I had two, with a chronological post list, and a list of travels), and possibly into older posts.
This wasn’t a completely horrible experience, and I actually managed to publish two long series (Sweden 2015 and Lappi 2015 this way. Still it was by no means pleasant.
- Picking photos through photo2blog wasn’t very nice. It worked alright on small albums but when you had over a few hundred photos, the UI was just not up to the task. It loaded only a few dozen thumbnails at a time, and there wasn’t any way to zoom the to make sure you pick what you think you pick. And if you picked wrong, or decided you need some more pictures, you had to repeat the process from scratch.
- Manually linking up everything together is of course boring as hell.
- Markdown has only very primitive support for images (for example it can’t render a Retina-aware
imgtag), so I ended up writing HTML directly. - Lack of WYSIWYG editing. Unclosed tags, description written for wrong images, etc.
- I’ve actually also been having concerns about using Flickr for photo hosting. I mean, I upload there thousands of photos in private albums and hotlink them on my website and I do it all for free. This is allowed but I’m pretty sure that goes against the spirit of the service, and I wouldn’t be surprised if they end up charging for that kind of use, or outright disabling it. After all they hardly can make any money on me!
- Finally, who can tell if Flickr will actually outlast my website? Flickr is a division of Yahoo, and these days it appears Yahoo hardly has anything else of any value apart from Flickr (and Tumblr maybe). Yahoo itself was bought in early 2017, and it’s not unlikely that their new owner will want some changes, possibly not altering Flickr terms of use but shutting it completely.
For a long time I’ve been planning to write my own static site generator or offline CMS, which is of course a perfectly noble goal. As a software developer my default urge in a similar situation is to start code up something of my own (although as I’m getting older and less excited by my field of work this has diminished somewhat). I even started working on that project… like three times or so. But in the end I simply don’t really have enough spare time and motivation to work on the side project of such a scope, even if I do everything as quick and dirty and possible, without using any fancy new tech in process. Well I do have a lot of spare time (which I really suck at managing) but I’d rather work on the blog itself than on the tools for working on the blog.
Then I told myself that blogging is a solved problem, well, like thousand times over, and if I really want to have a nice blog, I should just do what every reasonable person in that situation does, i. e. install WordPress.
WordPress is probably one of the most despised pieces of software in the world. It’s notoriously poorly coded, lacking many modern practices, and is infamous for its security bugs. At the same time it literally runs ¼ of all websites in the world, and if experience has taught me anything, it’s that if boring and outright shitty technology works and solves problems for a huge number of people, then it’s not that shitty after all*.
* Except Electron Javascript-based desktop apps of course. They are an abomination and must burn in hell.
I’m still strongly attracted to the idea of static sites however. I don’t really need any sort of backend for a bunch of pages and photos, and I don’t like the idea of exposing WordPress to the web, what with the common security issues and the like. But the huge advantage of WordPress is that its ecosystem has plugins for pretty much anything imaginable. Sure, the plugins are usually even shittier than WordPress itself. Still beats coding that stuff yourself! And sure enough, there are at least two relatively popular for "turn-WordPress-installation-into-a-static-site" scenario: WP Static HTML Output and Simply Static.
Two other things that worried me were image hosting and offline editing. Flickr provided nearly unlimited space for images, but a typical cheap VPS today will have only 5 to 20 GB of disk space. I explored plugins which allowed using Flickr as image storage backend for WordPress, and other options such as storing them on Amazon S3 (there was a plugin for that, too).
In the end however it turned out that all images from all pages of my blog (in three sizes each: the original, 800px for posts, and 1600px which are Retina versions of 800px) took only slightly over 5 GB which meant I didn’t really need to use anything but basic WordPress media library feature with VPS own storage. If I ever need more, I can just upgrade to a more expensive plan.
It turns out WordPress media library is actually quite well designed (I mean, from the point of view of the user) and makes it dead easy to upload photos and to compile posts from series of these photos. It also helps with the next problem, offline scenario.
I kinda always wished I could just go somewhere without an Internet connection and write something without distractions. Of course for basic "working on a park bench" scenario 3G tethering would work alright but what if I’m on a long flight or train trip or even some cottage away from the civilization (but with a power outlet nonetheless). With my GitHub Pages-based blog this wasn’t really possible, unless I was going to write text-only posts. Images were stored on Flickr, and uploading them, picking them for a post, or even displaying them in a post preview is impossible offline.
WordPress is a web application and is naturally not really meant for any sort of offline use (unless you use a desktop blog writing software which actually sounds a very nice option but I haven’t explored this option yet; I doubt they can accurately work with whatever WordPress can do with its plugins). It is, however, relatively trivial to write some scripts which would sync the "master" online installation to my laptop, allowing me to run WordPress locally and do anything I could do offline. Then another script would sync all these changes back online. Using such scripts would require some care (so as to not sync anything in wrong direction; also I couldn’t be writing both online and offline simultaneously) but still seems like an easy solution for the "offline question".
So the basic plan looked like that:
- Get a cheap VPS
- Set up a WordPress installation which I would use for writing and editing posts on a private subdomain
- Protect this installation with HTTP auth (and HTTPS) so that no one but me could ever touch it
- Migrate content from GitHub pages
- Set up theme etc.
- Set up static site generation for the main domain
- Switch DNS to point to the new server
The whole project took me perhaps a week of spare time in evenings, and below I’ll explain how I did that in some more details. This is not a step by step guide; didn’t write down all the steps when I actually did that, and I sure as hell don’t want to repeat all of that now. And my case was a rather specific one, so it’s very unlikely that you could use any of the instructions verbatim.
Hosting
I used to work for a web hosting company, FastVPS, and I still have a soft spot for them. These days however the go-to option for VPS hosting seems to be DigitalOcean (unless you want fancy AWS stuff but why would you want it for a basic blog?). Their cheapest offer is $5/mo, and you get a single core, 512 MB RAM, 20 GB SSD, and 1 TB bandwidth for these money. 20 GB would be enough for my photos for quite some time, and they additionally offer "Volumes" which is a way to add arbitrary (from 1 GB to 16 TB) amount of disk space for $0.1/GB/mo*, which sounds perfect as a way to expand later. Oh, and their hosting control panel is very nice, much better than the one I worked at back in FastVPS.
* I actually accidentally ended up creating my VPS (they dub them "droplets") in a region which doesn’t include this feature (as of now, at least), but it’s possible to migrate VPS to another region (with some downtime).
1 core/512 MB RAM also seems reasonable for a single-user WordPress installation + fully static HTTP server. 1 TB might not be all that much but with the kind of visits I get this should always be fine for the foreseeable future. I really only get about 50 visits/day, and it seems most of them are accidental. I’m really writing all of this stuff for my own enjoyment.
So this step was quite easy. Buy a VPS at DigitalOcean, set it up with Ubuntu Linux, and do the basic apt-get update, apt-get upgrade etc. on the newborn server instance.
Set up WordPress
These days bringing up a PHP/MySQL-ready web server is pretty easy. Most of the config files are already provided by default, and you only have to install the relevant packages and uncomment the relevant sections.
These days of course we’re going to use nginx+php-fpm rather than Apache. Although this hardly makes any difference for a private installation. I’m used to PHP 7.1 at work and it isn’t provided yet even in latest Ubuntu (zesty), so I got that from a PPA, http://ppa.launchpad.net/ondrej/php/ubuntu. For WordPress this, again, is not really any better that using PHP 7.0, possibly apart from marginal performance improvements.
I did apt install nginx/php7.1-cli/php7.1-fpm/mysql-server. I left the default vhost configuration alone for a while, and set up a vhost for the private sub. Then verified with phpinfo(); that things were working correctly.
Running MySQL with default settings took a bigger chunk of my VPS’s RAM than I would have liked, so I tinkered around in /etc/mysql/mysql.conf.d/mysqld.cnf. I lowered key_buffer_size and query_cache_limit/size and possibly other things, but the biggest difference came from performance_schema = OFF. I wish there was a way to run WordPress with SQLite.
Then I downloaded the current WordPress release from wordpress.org/latest.zip and unzipped it into the root directory of the new vhost. I prepared an empty database and a MySQL user, set them in wp-config.php, and the short installation wizard worked fine and I was presented with the default blog page.
For a while, I chown’ed the vhost root dir to www-data user so that it would be easier to download plugins and themes. This additionally required setting define('FS_METHOD', 'direct'); in wp-config.php. Eventually I chown’ed everything but wp-content/uploads/ back to root.
Getting nice URLs, as usual, requires configuring URL rewriting on the web server. WordPress comes with .htaccess file for Apache, but with nginx you of course have to do this yourself. Fortunately this is as easy as adding location / { try_files $uri $uri/ /index.php?$args } to the vhost configuration.
Edit (2020): apparently I never finished writing about the rest of the steps. Oh well. By now the blog is back to a static site generator (although now a self-written one).