Back in early August the new owners of my long-term hosting service, Webfaction, told me they were “unable” to migrate my account to their new environment. I suspect the real reason was more like “we can’t make enough money off guys like you”, but they’re free to come to that conclusion and I don’t fault them for it.
But it did require me to find a new home for my six blogs, quickly. Not so much because I didn’t want to disappoint my audience1 but because I didn’t want to lose all the stuff I’d written over the years. Whatever else they may do those blogs serve as a storehouse for things I’ve learned-but-since-forgotten2.
The hosting world has evolved a lot since I last picked a provider. On the one hand the cost of basic, reliable Linux-based shared hosting — the simplest type, and what I’d been using for many years — has plummeted. On the other hand so has the cost of admittedly more complex but potentially more interesting choices, like virtual private servers (VPS for short).
Since “interesting” to me is like catnip to Moose3 I naturally thought it might be “fun” to go the VPS route. While the responsibility is greater — you are signing up to be the system administrator for your system — so is the power and responsiveness, because you’re not competing with all the other sites running on your assigned hardware.
Besides, I know (Debian) Linux fairly well and have installed and used it on quite a few Raspberry Pis over the years. How hard could it be?
You’d think, by age 66+, I’d have learned to be wary of that particular conclusion. But color me slow in that regard.
In the end it was an enjoyable experience and I’m happy with the new setup. Plus, I now have access to a much faster and more powerful implementation of Debian Linux for whenever I get the urge to try something on hardware more powerful than what can fit in a system the size of a deck of playing cards4.
But I learned some things along the way I’ll share here to maybe help the next crazy person who decides to indulge his or her curiosity bump.
What follows refers to Debian 10, aka Debian Buster, installed on a 2 core/2GB RAM Hostwinds virtual private server5. While that’s (currently) their entry-level VPS it appears to be sufficient for my half dozen sites, with some room to grow.
Look for the Easiest Way…Which Keeps Evolving
There are a lot of things you need to install in a Debian system for it to serve as a host for WordPress. First and foremost you must finish installing the rest of LAMP: Linux (that’s the Debian part; installed by Hostwinds when they created the VPS), Apache (the webserver), MySQL (a database) and PHP (the software language WordPress depends on).
There are a number of ways to do that. The most straightforward is to use Debian’s apt-get system and simply issue a bunch of “install this package” calls at the command line through sudo. That’s what I ended up doing for Apache and PHP.
Unfortunately, Oracle and/or Debian, in their collective wisdom, do not offer a Debian installer package for MySQL. You can install an alternative to MySQL…but I’m not sure which ones work with WordPress and all my (limited) experience with databases under WordPress has been with MySQL. So I wanted to stick with it.
I found some instructions (here’s an example) that I used to work around the lack of an “official” installer package. But be prepared for to commit some time to come down yet another learning curve.
It’s also worth spending time hunting for the latest and greatest easiest way. For example, at a later point in the process I wanted to install the software to create, automatically, the SSL certificates needed to have my webserver only “talk” to people via SSL-encrypted (i.e., https://) connections. I’d done that for years “by hand” using some tools I’d found.
But it turns out enough people were frustrated with all the steps you had to go through to use those tools for someone to get motivated to develop a simpler way: certbot. Which not only did the basics of retrieving the SSL certificates but also was smart enough to know how to modify the apache configuration files to incorporate them. At least after you remember to install the apache2 module for certbot.
Always look to see if there’s a simpler way. Whatever you’ve learned and know, there are a lot of bright people out there who may have made what you want to do easier to accomplish.
Duplicator Pro: Don’t Leave Home Without It
Fundamentally, migrating a WordPress site involves copying over the configuration settings, domain name and content files from one computer system to another6. Oh, and the plugins, too. Don’t forget the plugins! And all their settings! And…
You can attempt to do this manually (e.g., via SFTP)…but the odds are very high you’ll forget something, or misname something, or otherwise make a minor mistake eighteen levels down in the directory tree and wind up with a non-functional site. And that’s only if you’re lucky enough to only make one mistake. Otherwise, you’ll likely end up in Debug Hell, with multiple competing problems giving you conflicting error messages that will take a long time to unravel and fix.
There is an alternative. Which I will now always use going forward. Duplicator Pro. Yes, there’s a free version. But this product is so powerful and well-written I believe it’s worth compensating the authors, if for no other reason to encourage them to stay in business so their software will be around the next time you need to migrate something. Plus, I believe it does backups as well, obviating the need to get or purchase a plugin to do that.
Duplicator Pro saved me hours. Plus, it let me keep what’s left of my hair, which I had begun to rip out by the roots attempting the first migration “manually”. Highly recommended.
Am I Permitted to Do That?
One of the more subtle problems I ran into manifested as problems with the caching plugin I use7 and the security monitoring plugin I use8. The sites worked but the logs were filled with lots of obscure complaints from the caching plugin, and the security plugin kept crashing any attempt to log out of a site.
It turns out this was a self-inflicted wound caused by me taking ownership of all the files apache was serving and processing (i.e., everything under /var/www). To save myself the trouble of having to sudo every time I wanted to edit one of those files I changed their ownership to my login username. Hey, who doesn’t love saving a few keystrokes!
Bad move. Because now the apache processes, which run under a different username, didn’t have all the access rights necessary for those plugins to work properly.
It took hours to figure this out. Fortunately the fix was simple: transfer ownership of those files back to the apache user (www-data, in Debian 10 at least). Problem solved, and no more obscure error messages.
When All Else Fails…Clear the Browser Cache
There are certain instructions from tech support people I’ve learned to ignore over the years. “Have you rebooted your computer?” is one of them. Hey, Sherlock, do you actually think I would’ve gone through the trouble of contacting tech support, and waiting in line for someone to talk to, without first trying to do something as simple as that? Gee, you must think I’m a complete moron!
In the browser world the analogous phrase is “clear the browser cache”. Which is definitely not something you should do casually, ever, because it means you’ll have to re-enter every one of those passwords and what-not your browser helpfully remembers for you9.
Unfortunately…sometimes you really have to. Particularly when migrating a WordPress site. Apparently, browsers store critical information about how to navigate to, and assemble the pieces of10, a website so they don’t have to do all that every time you visit that site you check dozens of times a day.
Before resorting to clearing the cache I tried everything I could think of. Clearing the cookies related to the site I was migrating. Clearing all the cookies. Trying a different browser. Nope, nope, nope (and more nopes for things I won’t bother to list here).
What prompted me to finally Take the Plunge was being able to access the site I had migrated via Chrome’s incognito mode. That worked…which meant something stored somewhere in the browser was at fault. And the only way to reset it was to pay the price and clear the cache.
Problem solved. But I do wish browser writers would make it possible to clear just whatever was causing the problem without having to do a Vulcan Death Grip11.
like Isaac Asimov once asked, he always wondered, as an author, if anyone actually ever read his stuff ↩
which happens a lot if you play with tech as much as I do ↩
the cat who deigns to live with us ↩
i.e., a Raspberry Pi; which are awesome little machines, but still little machines ↩
I recommend you consider Hostwinds — they’re a well-run outfit ↩
which has to know how to be a WordPress server, of course ↩
WP SuperCache; recommended ↩
WP Cerber; also recommended ↩
technically, the sites “remember” those things, via cookies ↩
most websites are a plethora of bits and pieces of content and code from many different places ↩
I know, they aren’t real; but then, neither is gasp Star Trek ↩