Quest for The One Blog, Part 2

Quest for The One Blog, Part 2

Previously, I mentioned that I planned to investigate the Pico and Grav blogging platforms first, since they are both PHP-based, database-less platforms that operate on Markdown flat files, which sounds like the perfect place to start for my mission goals.

Incidentally this is exactly the kind of post I wouldn't normally put on this blog.

First I’d like to mention that it’s really hard to find alternate blogging platforms. Any sort of Googling will get you information on: WordPress, Blogger, possibly SquareSpace, and maybe a mention about Medium. Anything other than those platforms requires a great deal of digging. If you tailor your search to .NET solutions, you’ll invariably end up at DotNetNuke (gag), BlogEngine.NET, or Orchard (Microsoft’s thing).

Next I’d like to mention that if you’re lucky enough to find an article listing “15 open-source blogging platforms,” you will probably find that it is a verbatim cut-and-paste copy of some other article about open-source blogging platforms. This is definitely not a subject that is very popular.

I’m treading new ground here. Forging a new path. It is exactly the same as an explorer going to the North Pole for the first time, or climbing Mount Everest. Exactly the same! The risk is exactly the same and that is not the slightest bit hyperbolic!

Ubuntu Server

I started with Pico. (Mainly because I didn’t remember Grav until later, although I had heard of it years ago and made a mental note of it, I completely forgot about it.) You may notice if you go to that Pico site that installation is a bit obscure (despite the claim that it’s “dead simple”). It involves downloading a .tar.gz file and/or running some Linux commands that the Pico makers assume you’ll understand. If you’ve run a self-hosted WordPress installation you may have some inkling of where to start. Otherwise, this is pure backend web development territory.

To make a long story short, I needed to setup a Linux environment for testing and development. If you purchase a shared Linux web hosting plan, you are basically buying a Linux environment pre-setup for web hosting. Since I’m still in the brainstorming and prototyping phase of this project, I didn’t want to spend any money, nor did I want to tinker with my existing web hosting environment in case everything fell apart and all my sites exploded.

I have some familiarity with Linux but I would never claim to be an expert. I’ve occasionally installed Linux distros for one reason or another in the last twenty years. I immediately turned to Ubuntu, because that’s just what you do these days, since it’s the most “user-friendly” of the Linux distros that I’m aware of. [Cue: Hordes of Linux devotees yelling at me that there are at least six better options.]

But where to put it? Where do I install Ubuntu? We live in a “virtual machine” age so I immediately thought I would install it on a virtual machine. But which one? There are about a thousand different virtual hosts to choose from now. I’ve used Oracle’s VirtualBox before with great success. I’ve also used Microsoft’s Virtual Servers with success.

That thought reminded me that I bought a cheapo “server” many years ago expressly for the purpose of running virtual machines. It had been in a box since I last moved. I got it out. I booted it up. It runs Windows Server 2008 2012 R2. It has all the virtual machine stuff already setup on it, and a virtual machine appeared on the network as soon as I turned on the server. I tried to login to the server. That’s when I discovered that I had no idea what the password was.

I looked everywhere for the password, but I remembered that I had only written it down an a sticky note in the other house, and it could be anywhere by now or most likely thrown away. Smash cut to abandoning the virtual server plan and simply installing Ubuntu Server over top of Windows Server 2008 2012 and starting from scratch. (I’m aware there are ways to recover the password but sometimes starting over is just easier.)

This is the point when I learned that Ubuntu Server is not the same as Ubuntu Desktop. I just picked the “server” edition because it seemed to match what I was trying to do: Setup a web server environment. It did not occur to me that there would be exactly zero GUI in the server edition (though in retrospect it should have been obvious).

I did a lot of Googling during this time.

I was able to use PuTTY to connect to my new Ubuntu Server, which is exactly how I have connected to my web host in the past. I installed Apache. I installed PHP. I installed all the other stuff I needed to install. (I am compressing a lot into a couple sentences there.) Thankfully one thing that is cool about Linux is that apt-get “just works” to install stuff. I was able to connect to my Ubuntu Server with a web browser and see the default Apache page.

I don't know why I feel the need to prove that I successfully installed Apache.

Installing Pico

I was finally able to try to install Pico on my Ubuntu Server.

First I tried using the “Composer” method. Composer is a product that is new to me. Apparently it’s a system that allows downloading “packages” of PHP software, in a manner similar to all the other “package” systems in all the other development environments, like apt-get or nuget. Essentially it’s a way to get software updates without the hassle of unzipping files and copying them to the right places.

It’s a great idea. Unfortunately I ran into file permission problems immediately. The Pico and Composer instructions didn’t say much about dealing with that. The instructions just seemed to assume that everybody and everything has the right permissions, which I definitely didn’t under the default Ubuntu installation. You’d think the instructions might say a word or two about installation on a default Ubuntu distro, since it’s probalby the most popular Linux distro, but you’d be wrong. I imagine they assumed people would be installing in a shared web hosting environment, where the permissions are setup for them.

In any case, I abandoned Composer and went with the “just unzip the files into the right directory” method.

This led to another adventure, because it’s super easy to download Pico from my Windows laptop by simply clicking on the link, but not quite as easy to do so from a Linux shell, where there is no such thing as a web browser. [Cue: Hordes of Linux devotees telling me about all the console-based web browers I could have gotten and used.]

[I am probably stereotyping Linux devotees. But yeah, they’re a stereotype.]

Anyway, a lot of Googling and curl experimentation later, I got the Pico files in the right directory. And I was actually able to open a web browser on my laptop and connect to my Ubuntu Server and bring up the default Pico page. I had successfully installed Pico. That all took about half of my Saturday.

A lovely, clean Pico page generated from a Markdown file.

Installing Grav

That was when I remembered Grav, and installing that took the other half of my Saturday.

Grav is a platform that also works on Markdown flat files, but it seems to be a more mature product, and it even has a fairly robust administration panel to go with it.

I brought forward a lot of the lessons I learned from installing Pico. But there was a lot more fiddling with user and file permissions. I had to put the “www-data” user (the user under which Apache runs) into the same group with my login so that Grav could write files.

I had to install a whole bunch of PHP modules. I had to enable mod_rewrite in Apache. I had to restart the Apache server a hundred times. Things didn’t work. I had to find a delete a cache directory. Then things magically started working. I didn’t think I’d ever get it working, but finally, I got the default Grav administration page up and running.

Another web page generated from a Markdown flat file.

Grav has the added advantage of a nice administration panel where you can maintain the blog. But does that mean it's on the road to bloat-town just like WordPress?

Whew. A starting point.

By that point I was exhausted and sick of the whole thing. What was I even thinking? Why even try to challenge the WordPress Industrial Complex? Why not just submit to the will of the majority and be done with it?

A good question, one that offhand I can’t quite answer.

P. S. If you were looking for the precise technical steps that I went through to do this stuff, with exact shell commands and so forth, that would have taken a lot longer to write, and I didn’t make notes of half of it. Everything I did was readily available from Googling the obvious search terms though.

This post is part of The Quest for The One Blog. Next up: Part 3.

This page is a static archival copy of what was originally a WordPress post. It was generated from Markdown files with Hugo, a static web site generator. There may be formatting problems that I haven't addressed yet. There may be problems with missing or mangled images that I haven't fixed yet. There may have been comments on the original post, which I have archived, but I haven't quite worked out how to add them to the new site.

Note: Comments are disabled on older posts.