A week or so ago, I got some distressing news when I logged on to this website to do some routine maintenance.

Last login: (...blah blah...)
Vanhat PHP versiot poistuvat 15.12.2016, oletukseksi tulee versio 5.6

“Old PHP versions are going to go away in December 15th, 2016. Default version will be 5.6.”

Okay, I should pay more attention, clearly. I now had to basically do what I had intended to do since this summer, but never actually got around to deploying on this site. Was in kind of a hurry to fix this stuff, but I actually managed to do that in time, despite not getting that much heads-up.

Drupal, the content management system I’ve used on this website for a few years now, had been severely creaking at the edges. I believe Drupal is a fantastic CMS, but unfortunately, it’s not an optimal thing to run on this particular webhost and this particular situation. Also, much like many web applications written in PHP, it suffers severely from “for love of God please don’t look under the hood” syndrome, even considering it was written by actually competent software engineers.

The situation at this webhost was a little bit unbearable. Much of it stemmed from the fact that I’m unable to use a “real” RDBMS at this webhost, and I was forced to use SQLite. PDO version of SQLite is only available in PHP 5.2 on this particular webhost, and is disabled in the new versions, because apparently PHP language developers think that a user’s ability to disable features that have been previously accepted as a standard feature of the language (no matter how big and ridiculous) is actually a good thing that makes the famously easy deployment of PHP applications even easier. (You may be detecting a hint of sarcasm here.) PHP 5.2 is So Ancient It’s Not Even Funny, and while Drupal 7 ostensibly supports it, it just might not be feasibly supported by everyone in Drupal 7 ecosystem, especially now that Drupal 8 is out and has officially dropped support for such old versions.

What it boils down is that since the autopath plugin was broken, I was unable to post any new blog entries. I was never able to debug what exactly went wrong. I got an empty page as a response on my web browser, PHP dutifully logged all of its errors to la-la land, and Drupal’s own logging system reported nothing out of ordinary.

Why Drupal was a good choice

I was sceptical about switching out of Drupal.

After all, I had grown a little bit acclimated over time to Drupal. I’ve written before (1, 2, 3) about how I think Drupal is a great content management system because it actually tries to think about what data is and how it should be handled.

In short, Drupal is a content management system, not a content management system. Drupal puts special thought in how content should be stored. For Drupal, the content isn’t an amorphous mass of HTML – every type of data that is being presented to the users should be treated as bits and pieces of information, each of which have to be presented to the users in specific way depending on where the user is looking at it. This allows the site designer to use things like Views to construct automatic indexes based on the contents that the user only needs to enter once.

But it also comes with heavy, heavy drawbacks.

Guts that look like guts

Specifically, Drupal by necessity wants to be more than just a content management system. It also needs to be a content management framework – the bits and pieces of code that juggle that data. Sometimes, you need to add new pieces of code to do what you actually want.

…and Drupal isn’t very good at it.

Why? Because Drupal kind of suffers from an ailment that, for one reason or other, many PHP applications seem to suffer from – in particular, MediaWiki. MediaWiki is kind of like Drupal: It has a content management mental model that makes sense, a wiki markup language that is much more expressive than anything I have had the pleasure to work with, and the user interface is absolutely fantastic. …and once you want to actually extend it at code level, you see that it’s got PHP written all over it. And then you say “well, I don’t really want to do PHP at all, actually, and I like to live particularly dangerously, so I’ll just write a bit of code that talks directly to the database” – well, good luck with that too, because the database schema doesn’t make sense either.

So not only you need to write extensions in PHP and deal with a really unorthodox and over-complicated HTML schema…

SELECT n.title,
       fdb.body_value,
       fdb.body_summary,
       n.created,
       n.status,
       tdata.name AS category,
       n.nid AS nid,
       n.vid AS vid
FROM node AS n,
     field_data_body AS fdb,
     field_data_field_blog AS fblog,
     taxonomy_term_data AS tdata
WHERE n.type = 'blog_entry'
AND n.nid = fdb.entity_id
AND n.vid = fdb.revision_id
AND n.nid = fblog.entity_id
AND n.vid = fblog.revision_id
AND fblog.field_blog_tid = tdata.tid

(Fig. 1: Don’t ask me what the hell this SQL query means, I just copypasted it from the Jekyll importer thing I was working on in December 2015 and by summer 2016 I had absolutely no idea what the hell it meant. It’s got a fucking four-table join in it. That’s all you need to know.)

…but Drupal even introduces some interesting conventions of its own. PHP code for extension needs to be formatted interestingly, because Drupal has its own very separate coding conventions and code deployment formats, which means that PHP code resides in weird places.

If you are just an user who cares about how the application stores your data from user point of view, Drupal and MediaWiki are extremely beautiful. Just that when you need to stab your way to the guts, you’ll get the slimy, toxic, acidic guts. Sure, you feel like a badass taking care of it… but sometimes, you hope that instead of a monster you would have a well-organised factory and instead of stabbing the big evil monster’s evil guts with weapons of evil you’d handle material and your tools in an organised, clean fashion.

When it squeaks, it squeaks

Drupal really doesn’t like shared hosting.

What a shocker.

You see, Drupal embodies these modern-time, easy-to-deploy open-source software packages. You drop files in your webhost’s directory, run the installer and tell it where the database is, and boom! Instant website.

This is pretty much the whole selling point of PHP and MySQL. Or at least that was the whole selling point of the LAMP stack. 15 years ago.

The problem is that I don’t think LAMP stack fixed the problem it tried to solve. At the time, I felt like the whole problem was completely unstated and LAMP just happened to solve the problem.

The problem? Web application deployment sucks.
The LAMP solution? Some very basic research into standardised set of components that are expected to be there. And not much else. It may fit some criteria, but you’re in a world of hurt when the criteria are not met.

For example, I’ve been on the same webhost since 2001, and I’m using one of their plans that date from that era which states that I can have normal shell access and no database access. At the time, MySQL access cost extra. And if I wanted MySQL access, that would still cost extra – nowadays, the webhost just sell that as their basic plan.

Oh, but with PHP, you can at least use SQLite, right? One of the big selling points for me was that SQLite is now a mandatory part of PHP. …except the only available version of PHP that actually has SQLite on this webhost is PHP 5.2, and I get really funny looks when I tell people that their Drupal extension fails to work on PHP 5.2 (because, of course, why would PHP developers keep their syntax consistent in 5.x series, duh, that would involve actual concerted programming language syntax design). And, of course, this brings us to the real reason why I switched away from Drupal for beastwithin.org: Drupal 7 is the last major version to support PHP 5.2, which means is a happy occasion because PHP 5.2 is really old and crusty, and a sad occasion because I need to stay on Drupal 7. Which wouldn’t be a problem until Drupal 7’s EOL, but it was better to start thinking of this stuff now rather than face the doom then.

And another reason was that even on Drupal 7, the site just didn’t work too well. Or it did, but when things went wrong, they went wrong hard. For example, at some point, Drupal’s pathauto module seemingly broke for some reason. I have no idea why it completely fails to automatically create the post permalinks I desire.

The eternal wanderer has arrived

How many content management systems have I tried for these blogs so far? Let’s see: Blosxom, Typo, Hobix, Movable Type Open Source and finally Drupal.

And now? Jekyll.

As said in the beginning: Jekyll was a weird choice and I was very sceptical about it. Not just because I was acclimated to Drupal, but because I had had a little bit less stellar experience before with another Ruby-based static web site generator, Webgen – but I guess in retrospect that was just the whole deal with certain incomprehensibility of the thing and the fact that when it broke, at the time I actually had no idea what was the whole deal, but I guess that was just the whole thing about the switch from Ruby 1.8 to 1.9 – Webgen wasn’t quite ready, as I recall, and developers weren’t around, and I wasn’t sure how to fix the gem dependency mess at the time myself, so I was a bit disappointed. My bad, my bad. But Webgen isn’t actually blog-aware and does a little less than Jekyll, so I have hope. It’s also good to know that Webgen seems to see at least some development nowadays.

So I did it. Here I am.

I have high hopes that Jekyll won’t blow up on me, because it’s actually widely used in the open source world. It’s actually very nice to be able to control the content here once again, and post stuff on my home page.

I really need to start organising the stuff on my homepage better, and write more of all of the awesome projects I’ve been trying to do.