While I was doing that, I figured it was high time to drop the subdomain, so now it’s just https://wadetregaskis.com, instead of https://blog.wadetregaskis.com. Blogs are so last year.

Previously I was using Gandi.net (I recall choosing them because they were touted as a particularly privacy-centric host) shared webhosting. I’m now using an unmanaged VPS from IONOS. This is far superior – site performance is much higher, I can finally use modern web technologies like TLS 1.3 and AVIF¹, and frankly it’s just deeply satisfying to have a whole [virtual] machine at my disposal. It might be a gateway to bigger things.

I chose IONOS because they offered the best apparent value amongst hosts that seemed well-reviewed. I’m now paying just a third of what I was at Gandi.net (for what amounts to at least 2x the CPU performance and 4x the RAM!). They also include a full copy of Plesk, which has proven a net win in getting everything set up and configured – notwithstanding some serious initial issues with it, that ended up requiring me to reimage the whole VM and restart from scratch. 😒

The process took over two full days, partly because of the aforementioned Plesk issue which cost me nearly a full day by itself, and otherwise because of just a whole bunch of issues along the way. e.g.:

• File transfers (via HTTPS or SFTP) to & from Gandi are slow. They always have been – it’s one of several things that always bothered me about Gandi.
• TCP connections to Gandi tend to get killed if they hang around for any significant amount of time (such as for large file transfers over HTTPS or SFTP²).
  • This in turn exacerbated a few bugs in Cyberduck whereby automatic retries don’t work and I had to manually relaunch Cyberduck completely between retries (otherwise it locked up).
    
    I partly addressed this by using Transmit instead, which isn’t entirely immune to Gandi’s bugginess but seemed to hit it much less often. And is also a much more elegant application, in any case.
  • Combined with the general slowness, this meant it took most of an entire day to copy out the compressed copy of the old site – which was just a few gigabytes.
• I struggled to find a good way to migrate the site before committing to the actual domain name migration. I had never migrated a WordPress site between hosts – never even restored in-place from an existing backup – so I had no real idea to what degree it would work.
  
  This would have been easier without TLS. I long-ago enabled HSTS for my site, and I technically could have worked around that in various ways, but no matter which approach I took I think it would have been challenging.
  
  Ultimately I just got too frustrated and said “screw it, I’ll switch the domain name and then figure out how to move WordPress”. Thankfully almost nobody visits this site, so breaking it for a day or so was inconsequential.
  • I made this slightly harder on myself by insisting on a “proper” TLS certificate for the new host – and therefore from IONOS since they include one free with each VPS – rather than using Let’s Encrypt (support for which is provided by a pre-installed extension to Plesk). IONOS’s control dashboard didn’t particularly want to issue the certificate while non-IONOS nameservers were used for the domain, although eventually I coaxed it into doing so.
• It took a while to figure out how DNS needed to be configured, between the old host (and registrar), the new host, and Cloudflare. DNS isn’t that complicated in principle, I just wasn’t all that familiar with it. I’ve added TXT records before and done a few other tweaks, but nothing of the complexity of multiple intertwined nameservers and non-trivial subdomain routing.
  
  Although in retrospect having Cloudflare in front of everything perhaps made it easier since ultimately I just had to change settings there, as opposed to having to move nameservers.
  • DNS propagation delays were a significant irritation and cause of substantial delays. After several key changes, I had no choice but to wait an indeterminate number of hours before I could see their effects and move on to subsequent steps.
    • macOS bugs whereby it ignores the last entry in /etc/hosts³ also didn’t help.
• UpdraftPlus kept failing to restore the new site from a backup of the old (ultimately it turned out to be an OOM-killing problem, easily fixed by enabling some swap space).
• Many miscellaneous bugs in Plesk, half of which I’ve already successfully repressed, but as merely a few examples:
  • Plesk’s WP Toolkit extension believes it can set up a crontab entry to poke wp-cron.php periodically, but it can’t (because apparently you can’t invoke that directly via php, you have to actually go through Apache with a real HTTPS request – I never got to the bottom of why).
  • Sendmail / postfix don’t work out of the box with Plesk; WordPress & Plesk just silently fail to send emails. I never found any way to get them to log their failures, but I did ultimately get it working through trial-and-error (and I can’t even say what specific configuration change(s) actually fixed it).
    • It also took a while to figure out how to properly set up DKIM, SPF, and DMARC, although that was relatively straightforward once I found this documentation.
  • After using Plesk and staying logging in just fine for over a day, on multiple computers, it suddenly decided it would log me out instantly almost every time. This is apparently a common issue, and through sheer stubbornness of countless login cycles I was able to get to the “Allow IP address changes during a single session” checkbox, which fixed it for me.

I’m glad it’s done, and there is a solid sense of satisfaction with having conquered the litany of bugs, design flaws, and limitations throughout the whole process.

But I really hope I don’t have to move hosts again anytime soon.

1. …because I can install modern versions of basic tools & libraries, like curl and ImageMagick, that support things like TLS 1.3 and AVIF. ↩︎
2. Made worse by Gandi’s weird SSH server being incompatible with rsync, thus forcing the use of all-or-nothing transfers over SFTP. ↩︎
3. It always ignores the last line of the file, so you have to explicitly add a trailing line return. This is actually not uncommon with Unix tools of a certain pedigree, from before good design, robustness, and user-friendliness were values. ↩︎