I've decided to make an upgrade to Drupal 8. This gave me the opportunity to rebuild the site theme again; I think it's an improvement. You can check out the old version on Archive.org if you're curious. It's not 100% complete yet, but this is a personal site nobody ever visits, so I have no reservations with making changes to a production site like this.
Unfortunately, this also means I've moved off of NearlyFreeSpeech for my primary hosting needs. Simply put, they don't offer a database configuration compatible with Drupal 8. Every time a database update ran, the website would die a horrible death as Drupal exceeded MySQL's redolog size; and then it would continue dying trying to commit the same transaction until I reinstalled or did some database surgery. Not a production-ready experience.
This is currently being hosted on Amazon Web Services for the time being; I chose them over DigitalOcean (which I've used previously for hosting game servers for friends) due to the sheer scale of their offerings. They both do VPS, but AWS also has a far wider spread of ancillary services such as hosted MySQL, DNS, and CDN options that put it far closer to the suite of full-fledged web hosting tools that NFS provided.
I am, however, sad to leave NFS. Despite AWS's larger scale, NFS had better pricing and service for a site of this size. It's one of the few shared hosts I could recommend. Their business model is great; the service works well; and their willingness to share their engineering frustrations earn brownie points with me. However, I also want working, up-to-date websites; so I had to move over. Sorry about that. :/
On the other hand, the move to Drupal 8 was ridiculously pain-free.
During the run-up to Drupal 8 there was a surprisingly large panic about complexity and how "getting off our island" meant "leaving people behind". There's literally a Drupal 7 fork now which removed features like the database abstraction layer in the name of a simplified design. It's almost as if they've never seen a truely incomprehensible PHP application like, say, Magento. I can safely say that said fork is unnecessary: Drupal 8 is the easiest-to-build, easiest-to-theme, and easiest-to-maintain Drupal ever.
The thing is: all of that "overbuilding" caused by Drupal 8 adopting an enterprise Java level of object-oriented code also means that the theme layer got drastically redesigned to remove common theme developer pain points. Drupal 7's theme layer was dominated by unstructured arrays of poorly-documented contents; poking a new theme hook meant seeking out default templates and pouring through source code in order to figure out how to get the bit of data you actually needed.
Nodes, taxonomy terms, views, and so on had to be accessed through a process a co-worker describes as "dumpster diving". You'd call var_dump() or dpm() on a particular set of values you were interested in. Then you would page through massive yet somehow still incomplete representations of data that somehow was still missing the one bit you actually needed. Almost none of this was searchable and inevitably became a frustrating slog through multiple source code files to trace down the flow of data from DB or input to entities and theme hooks.
A good example of this is element attributes; Drupal 7 had them as an array structure to be filled in by preprocess hooks. If you wanted to add or remove a class, it meant defining another theme hook, adjusting $variables to match what you wanted, etc. Naively replacing those attributes in the template, while feeling right, would amount to breaking the functionality of any contrib module that used those hooks for it's own purposes. But in Drupal 8 it's a simple matter of:
{{attributes.addClass("MySpecialClassName").removeClass("drupal-default")}}Everything in Drupal theming just feels like that now: a few little changes here and there to get the exact markup I need to make the CSS work. It's a far more accessible experience.
A lot of this is aided by the surprisingly full-fat Drupal 8 core. Views, custom display modes, Internationalization, automatic translation installs, WYSIWYG, responsive images, fieldable blocks, configuration management (aka half of Features), and many more functions were added or moved to core now. The result is a core Drupal 8 that I actually feel comfortable building a site in without additional extensions.
The cherry on the top is a fully supported Composer workflow. In fact, I'm fairly sure you need Composer now, at least if you plan to use contributed modules with dependencies. There's little reason not to - installing it is easy, it helps you keep vendored code out of Git, and it makes Drupal core updates far easier to perform. Just composer update, commit your lockfile, and composer install said lockfile on your production server. Aside from making the Libraries module potentially obsolete, composer also means keeping a client's website updated is no longer a chore. I wish all the PHP technologies I worked with had this.
So, if you are currently maintaining a Drupal 7 site, you should be considering the D8 upgrade. If you are building a website now, and chose Drupal, strongly consider D8 unless you depend on, say, the Panels or Composer ecosystem.